Come migrare i siti web in sicurezza
Pubblicato il 21 giugno 2026
Una migrazione sicura del sito web inizia prima che qualsiasi file venga spostato. Se vuoi sapere come migrare i siti web in sicurezza, il primo compito non è copiare dati - è ridurre le incognite. Controlliamo lo stack attuale, blocchiamo le modifiche non necessarie, confermiamo che i backup possano davvero essere ripristinati e costruiamo un percorso di rollback prima di toccare il DNS. Questa è la parte che molti team saltano, e più tardi i log raccontano sempre la stessa storia.
Le migrazioni falliscono per motivi banali. Un cron job dimenticato continua a scrivere nel vecchio database. Il DNS viene spostato prima che l'SSL sia pronto. Le regole di reindirizzamento vengono copiate a metà. La cache fa sembrare il nuovo sito a posto per una persona e rotto per tutti gli altri. Niente di tutto questo è drammatico, ma è costoso. Una migrazione sicura è soprattutto sequenza disciplinata.
Come migrare i siti web in sicurezza senza sorprese di downtime
Le migrazioni più pulite iniziano con un inventario. Devi sapere esattamente cosa viene spostato, cosa può cambiare durante lo spostamento e quali dipendenze si trovano fuori dal server. Questo significa file del sito web, database, archiviazione dei media, certificati SSL, zone DNS, attività pianificate, routing email, integrazioni API, callback di pagamento e regole firewall. Se il sito usa una CDN, archiviazione esterna delle immagini, object cache o ricerca di terze parti, includi anche questi elementi.
È qui che i team trovano le piccole trappole. Un negozio WooCommerce potrebbe dipendere da un webhook di pagamento che punta al vecchio IP. Un'app SaaS può avere worker in background su una seconda macchina. Un sito marketing potrebbe essere semplice, ma il modulo di contatto invia tramite un servizio SMTP limitato dall'hostname del server. Le migrazioni sicure raramente riguardano la homepage. Riguardano i margini.
Prima di spostare qualsiasi cosa, decidi che tipo di migrazione stai facendo. Uno spostamento equivalente da una VPS a un'altra è un livello di rischio. Passare da hosting condiviso a VPS gestita, cambiare pannelli di controllo, aggiornare PHP e cambiare il web server da Apache a Nginx nello stesso momento è tutta un'altra storia. Puoi fare più cambiamenti insieme, ma ogni variabile in più rallenta la risoluzione dei problemi. Se possibile, separa le modifiche all'infrastruttura da quelle all'applicazione.
Parti da backup che hai già testato
Ogni provider dice che i backup esistono. Bene, ma un backup è utile solo se si ripristina in modo pulito e abbastanza rapido per il tuo obiettivo di recupero. Crea un backup fresco di file e database immediatamente prima della migrazione. Conserva anche una copia esterna all'ambiente di origine, così non dipendi da una sola piattaforma che deve avere una buona giornata.
Se il sito è importante per i ricavi, esegui un ripristino di test in un ambiente di staging. Apri il sito ripristinato, verifica la connettività al database, controlla i permessi dei file e assicurati che i media vengano caricati. Se non puoi testare l'intera applicazione, conferma almeno che l'archivio di backup sia completo e che il dump del database sia leggibile. Non è un lavoro affascinante, ma non lo è nemmeno spiegare alla contabilità perché gli ordini di ieri sera sono spariti nel bosco.
Blocca le modifiche durante la finestra di migrazione
Modifiche ai contenuti, installazioni di plugin e deploy di codice durante la migrazione creano problemi di split-brain. Un sistema viene aggiornato, l'altro no, e ora nessuno è sicuro di quale versione sia quella reale. Imposta un breve blocco delle modifiche. Per siti ricchi di contenuti o transazionali, usa la modalità manutenzione o metti le parti critiche in stato di sola lettura durante la sincronizzazione finale.
Per e-commerce, prenotazioni o contenuti generati dagli utenti, pianifica una sincronizzazione delta. Copia in anticipo la maggior parte dei file e dei dati, poi esegui una sincronizzazione finale durante la finestra di cutover per acquisire le modifiche dell'ultimo minuto. Questo mantiene basso il downtime senza rischiare divergenze nei dati.
Prepara l'ambiente di destinazione prima del cutover
Un errore comune è trattare il server di destinazione come una scatola vuota che può essere configurata più tardi. Una migrazione sicura funziona al contrario. L'ambiente di destinazione dovrebbe essere pronto prima dello switch: OS aggiornato con patch, stack web installato, versione PHP confermata, database ottimizzato, SSL preparato, backup pianificati e monitoraggio abilitato.
Allinea prima i requisiti dell'applicazione, poi migliora con attenzione. Se il vecchio sito gira su PHP 7.4 e l'app non è certificata per PHP 8.2, il giorno della migrazione non è il momento del coraggio. Puoi modernizzare dopo aver confermato la stabilità. Prima la calma, poi l'ottimizzazione.
Permessi e proprietà meritano attenzione extra. Molti incidenti del tipo “il sito è migrato ma gli upload falliscono” sono solo proprietà utente/gruppo errate o percorsi scrivibili mancanti. Rivedi anche cron job, queue worker e attività pianificate. Un sito può caricarsi correttamente mentre un'elaborazione in background importante si è fermata silenziosamente un'ora prima.
Testa usando un file hosts o un URL temporaneo
Non puntare il DNS live finché il sito non è stato controllato sul nuovo server. Usa un override del file hosts o un dominio di anteprima temporaneo per testare l'applicazione privatamente. Naviga le pagine chiave, invia moduli, accedi come amministratore, effettua un ordine di test se pertinente e verifica l'invio delle email. Controlla immagini, ricerca, API, azioni amministrative e qualsiasi cosa legata a sessioni o caching.
Guarda oltre i controlli visivi. Esamina log degli errori, log del web server, stato di PHP-FPM, query lente del database e utilizzo del disco. Conferma che i reindirizzamenti funzionino come previsto. Assicurati che URL canonici, regole robots e variabili d'ambiente siano corretti. È sorprendentemente facile migrare un sito di produzione con un header noindex di staging ancora attaccato. I motori di ricerca sono obbedienti nei momenti peggiori possibili.
DNS, TTL e pianificazione del cutover
Se stai imparando come migrare i siti web in sicurezza, il DNS è dove la preparazione ripaga. Abbassa il TTL sui record DNS rilevanti con largo anticipo rispetto alla finestra di migrazione, idealmente 24-48 ore prima. Questo aiuta i resolver ad aggiornarsi più rapidamente quando sposti il sito sul nuovo server. Non garantisce una propagazione globale istantanea, ma riduce il tempo in cui gli utenti possono arrivare alla vecchia posizione.
Al cutover, aggiorna solo ciò che è necessario. Di solito significa il record A, magari AAAA, e a volte i record legati alla posta se anche l'email viene spostata. Fai attenzione a non mescolare la migrazione del sito web con la migrazione email, a meno che non ci sia un motivo chiaro. Combinarle aumenta il raggio d'impatto. La migrazione più bella è spesso quella che ha cambiato meno cose.
Mantieni attivo il vecchio server per un periodo di sovrapposizione sicuro. Anche dopo il cambio DNS, alcuni utenti e bot raggiungeranno ancora il vecchio host per un po'. Durante questo periodo, monitora i log di accesso su entrambi i sistemi. Se il vecchio server riceve ancora traffico significativo, tienilo disponibile e, se possibile, indirizza con attenzione l'attività di scrittura in modo da non perdere dati.
Tieni d'occhio problemi di caching e SSL
Le cache CDN, le cache applicative e la cache locale del browser possono nascondere problemi dopo la migrazione. Esegui il purge dove necessario. Se è in uso una full-page cache, svuotala dopo la sincronizzazione finale e dopo il cutover DNS. Conferma che l'origine CDN sia aggiornata, se esiste.
L'SSL dovrebbe essere pronto prima dello switch, non dopo. Installa i certificati sul nuovo ambiente, verifica la catena completa e testa il comportamento da HTTP a HTTPS. Gli avvisi di contenuto misto possono comparire se URL di asset hardcoded puntano ancora al vecchio dominio o protocollo. Sono piccoli dettagli, ma gli utenti notano l'icona del lucchetto più velocemente di quanto notino la tua attenta pianificazione.
Reindirizzamenti, SEO e integrità dell'applicazione
Se il dominio rimane lo stesso, il rischio SEO è più basso, ma i controlli tecnici contano comunque. Assicurati che i reindirizzamenti da HTTP a HTTPS, da www a non-www o viceversa, e qualsiasi vecchia mappatura dei percorsi si comportino esattamente come previsto. Se il dominio cambia, usa reindirizzamenti 301 in modo completo e aggiorna tag canonical, sitemap e riferimenti interni.
Non andare live con catene di reindirizzamento se puoi evitarle. Rallentano le cose e creano confusione nell'indicizzazione. Controlla anche pagine di errore personalizzate, robots.txt, generazione della sitemap XML e dati strutturati se il sito vi fa affidamento. La migrazione non è solo “il sito si carica”. È “il sito si comporta correttamente in condizioni normali e al limite”.
Per applicazioni dinamiche, testa autenticazione, sessioni e permessi con ruoli utente reali. L'admin può funzionare mentre il login cliente fallisce a causa dell'ambito dei cookie, dell'archiviazione delle sessioni o degli header proxy. Questo è particolarmente comune dietro load balancer o reverse proxy.
Il piano di rollback fa parte della migrazione
Una migrazione è sicura solo se è possibile tornare indietro. Definisci in anticipo le condizioni di rollback. Ad esempio: errori 5xx persistenti, errore nel checkout, login non funzionante, grave regressione delle prestazioni o mancata corrispondenza dei dati. Definisci anche chi prende la decisione di rollback e quanto dura la finestra di osservazione dopo il cutover.
Il rollback dovrebbe essere abbastanza semplice da eseguire sotto stress. Di solito significa mantenere intatto il vecchio ambiente, preservare se possibile lo stato del vecchio database e ripristinare rapidamente DNS o routing del traffico. Se si sono verificate scritture sul nuovo ambiente, ti serve una policy per la riconciliazione dei dati. Ecco perché i siti web transazionali richiedono attenzione extra durante lo switch finale.
Monitora intensamente per le prime 24 ore
Dopo il cutover, tieni d'occhio uptime, tempo di risposta, CPU, memoria, I/O del disco, carico del database, validità SSL, profondità della coda e job di backup. Monitora anche i segnali visibili agli utenti: flusso degli ordini, moduli di contatto, successo del login e segnalazioni di errore. Una migrazione può sembrare buona al decimo minuto e fallire alla terza ora quando partono i job pianificati o la cache scade.
È qui che il supporto gestito guadagna il suo posto. Un buon monitoraggio intercetta picchi di risorse, servizi non riusciti e problemi di certificato prima che i clienti diventino il tuo sistema di alerting. Per i team senza una profonda competenza operativa interna, quello strato operativo tranquillo conta più di un'altra casella di spunta in un piano hosting.
Una regola pratica per migrazioni più sicure
Non cambiare tutto solo perché finalmente ne hai l'occasione. Prima sposta, poi stabilizza, poi migliora. Quest'ordine fa risparmiare tempo, anche se sulla carta sembra più lento. Se hai bisogno di aiuto su come migrare i siti web in sicurezza, il partner hosting giusto dovrebbe essere in grado di assisterti non solo con il server stesso, ma anche con backup, monitoraggio, pianificazione del rollback e quei piccoli casi limite scomodi che compaiono solo dopo mezzanotte.
Una buona migrazione sembra quasi priva di eventi. Questo è l'obiettivo. Log silenziosi, traffico stabile, moduli funzionanti, nessun misterioso disastro cron e un team che può dormire dopo lo switch DNS. In kodu.cloud, di solito è questo lo standard a cui puntiamo - niente effetti speciali, solo tutto sotto controllo.
Andres Saar Ingegnere Customer Care