Come migrare il server di un sito web senza tempi di inattività

Pubblicato il 15 luglio 2026

Avvia la migrazione con un backup completo e ripristinabile e un piano di cutover scritto. Questa è la risposta più sicura alla domanda su come migrare l'infrastruttura del server di un sito web senza trasformare uno spostamento di routine in un'interruzione. Il nuovo server dovrebbe essere configurato, protetto e testato prima che il DNS indirizzi i visitatori verso di esso. Il vecchio server resta online finché il nuovo ambiente non ha superato verifiche reali.

Una migrazione del server è più che copiare i file del sito web. Il sito web, il database, le attività pianificate, l'instradamento della posta, i certificati SSL, il runtime dell'applicazione, il comportamento della cache, i record DNS e le regole del firewall possono tutti far parte del servizio. Trascurare anche una piccola dipendenza può fare sì che un sito sembri funzionare bene nella homepage mentre email di checkout, moduli o processi in background falliscono silenziosamente. Non è un guasto molto spettacolare, ma resta comunque costoso.

Mappa il server attuale prima di spostarlo

Inizia con un inventario di ciò che è effettivamente in esecuzione. Non fare affidamento solo su ciò che mostra il pannello di controllo dell'hosting. Controlla la document root, la versione dell'applicazione, il motore e la versione del database, le impostazioni di PHP o Node.js, i cron job, i queue worker, i percorsi di archiviazione, i reindirizzamenti, le variabili d'ambiente e la configurazione della posta in uscita.

Per un sito web aziendale, identifica anche tutto ciò che si trova al di fuori del dominio principale. Questo può includere sottodomini, siti di staging, endpoint API, callback di pagamento, object storage, provider email di terze parti, script di analisi e record DNS usati per la verifica. Se il server invia posta direttamente, registra il suo IP di invio, la configurazione del reverse DNS e i record SPF, DKIM e DMARC. L'email è spesso l'ultimo elemento di cui ci si accorge e il primo di cui i clienti si lamentano.

Documenta anche l'uso delle risorse del server attuale. Esamina il carico della CPU, il consumo di memoria, lo spazio su disco, la dimensione del database, i modelli di traffico e i log degli errori. Questo ti dice se il nuovo VPS o il server dedicato ha dimensioni corrette. Una migrazione è un momento utile per lasciarsi alle spalle un disco sottodimensionato, una versione di PHP obsoleta o un server che è andato avanti soprattutto grazie all'ottimismo.

Prepara prima il nuovo ambiente

Effettua il provisioning del server di destinazione prima di copiare i dati di produzione. Applica gli aggiornamenti del sistema operativo, crea un accesso amministrativo con restrizioni, configura il firewall e installa solo i servizi di cui il sito ha bisogno. Usa chiavi SSH invece dell'accesso con sola password, dove possibile. Disabilita i servizi non necessari e assicurati che gli aggiornamenti automatici di sicurezza siano in linea con la tua policy operativa.

Abbina con attenzione i requisiti dell'applicazione. Un sito che passa da PHP 7.4 a PHP 8.3, o da MySQL a una versione più recente di MariaDB, potrebbe richiedere modifiche al codice prima di comportarsi correttamente. Lo stesso vale per la configurazione del server web. Le regole di rewrite di Apache, le location di Nginx, i permessi dei file e le estensioni PHP non sempre si traducono in modo uno a uno.

Configura il monitoraggio prima del cutover, non dopo un incidente. Monitora disponibilità, tempo di risposta, CPU, memoria, utilizzo del disco, scadenza SSL e porte dei servizi chiave. Per le applicazioni con elaborazione in background, monitora anche la profondità della coda e i job non riusciti. Con infrastruttura gestita e monitoraggio già attivi, i log raccontano la stessa storia sin da subito, invece di lasciarti tirare a indovinare dopo che i visitatori hanno segnalato un problema.

Esegui il backup per il ripristino, non solo per stare tranquillo

Crea un backup aggiornato immediatamente prima della finestra di migrazione. Dovrebbe includere i file del sito web, i database, i file di configurazione, i caricamenti generati dagli utenti e qualsiasi segreto dell'applicazione archiviato fuori dalla web root. Verifica che il backup possa essere ripristinato in una posizione separata. Un backup che non è mai stato testato è un archivio pieno di speranza, non un piano di ripristino.

Per i database, usa un'esportazione coerente. I database grandi o attivi possono richiedere una gestione speciale per evitare di copiare dati mentre stanno cambiando. A seconda del database e dell'applicazione, puoi usare una finestra di manutenzione, una modalità di sola lettura, la replica o una sincronizzazione incrementale finale. I negozi e-commerce, i sistemi di prenotazione, i prodotti SaaS e i siti con membership richiedono particolare attenzione perché ordini e modifiche agli account possono arrivare ogni minuto.

Mantieni invariato il server originale durante lo spostamento. Non cancellarlo né eliminare i dati non appena i file compaiono nella destinazione. Conservare il vecchio ambiente ti offre un percorso di rollback pulito se compare una dipendenza nascosta dopo il passaggio.

Trasferisci file e database in fasi

Copia il set di dati iniziale mentre il sito esistente resta online. Strumenti di trasferimento file sicuri come rsync su SSH sono utili perché possono sincronizzare solo i file modificati durante un successivo passaggio finale. Per i database, importa il dump iniziale nel nuovo server, quindi testa l'applicazione su di esso usando un hostname temporaneo o una sostituzione locale del file hosts.

Evita di testare solo la pagina iniziale. Accedi come amministratore e come utente normale. Invia un modulo di contatto, reimposta una password, carica un file, effettua un acquisto di prova se opportuno, controlla le email delle transazioni e conferma che le attività pianificate siano operative. Controlla i log dell'applicazione e i log degli errori del server web durante i test. Una risposta HTTP 200 riuscita non dimostra che il servizio sia in salute.

Se stai cambiando anche l'architettura del server, isola le modifiche dove possibile. Per esempio, passare a un nuovo VPS è già abbastanza lavoro senza anche riprogettare il database, sostituire il livello di caching e aggiornare il framework dell'applicazione in una sola sera. Separare i progetti rende i guasti più facili da diagnosticare e da riportare indietro con rollback.

Riduci il TTL del DNS prima del cutover

Il DNS è il punto in cui una migrazione tecnicamente riuscita può diventare confusa per i visitatori. Riduci il TTL per i record A, AAAA, CNAME e quelli relativi alla posta da 24 a 48 ore prima del passaggio pianificato. Un TTL più basso incoraggia i resolver ad aggiornare i record più rapidamente una volta che punti il dominio al nuovo server.

Questo non garantisce che ogni resolver si aggiorni istantaneamente. Alcune reti mantengono la cache più a lungo di quanto richiesto e gli utenti possono avere cache DNS locali. Prevedi un periodo di transizione in cui una piccola parte del traffico può ancora raggiungere il vecchio server. Se il sito accetta dati variabili, hai bisogno di una strategia per questa sovrapposizione. Una modalità di manutenzione durante la sincronizzazione finale è spesso più sicura che accettare nuovi ordini su due server separati.

Non modificare i nameserver a meno che non ci sia anche un motivo per spostare l'hosting DNS. Cambiare i nameserver autorevoli aggiunge un ulteriore livello di propagazione e più record da convalidare. Mantieni la migrazione noiosa, dove puoi. Un'infrastruttura noiosa è di solito un'infrastruttura sana.

Esegui la sincronizzazione finale e sposta il traffico

All'orario di cutover concordato, metti l'applicazione in modalità di manutenzione se scrive dati dei clienti. Arresta i queue worker e le attività pianificate sul vecchio server in modo che non possano elaborare due volte la stessa attività. Esegui la sincronizzazione finale dei file e l'esportazione/importazione del database, quindi aggiorna la configurazione di destinazione con le credenziali del database di produzione, le chiavi dell'applicazione e gli URL corretti.

Abilita l'applicazione sul nuovo server e aggiorna il DNS con il suo indirizzo IP. Conferma che il certificato SSL sia installato e che HTTP reindirizzi a HTTPS correttamente. Se davanti al sito c'è un load balancer, una CDN o un proxy, aggiorna la sua configurazione di origine e verifica che riconosca i controlli di integrità del nuovo server.

Monitora entrambi i server durante la propagazione. Il nuovo server dovrebbe mostrare richieste in arrivo, mentre il vecchio server dovrebbe ricevere progressivamente meno traffico. Controlla gli errori 404, 500 e di permessi, oltre agli avvisi specifici dell'applicazione. Tieni d'occhio l'uso delle risorse perché un nuovo server può comportarsi diversamente sotto traffico reale rispetto a quanto faceva durante i test.

Convalida il servizio dopo la migrazione

Una volta che il traffico arriva al nuovo ambiente, esegui un controllo mirato in produzione. Conferma che le pagine principali si carichino, che gli utenti possano autenticarsi, che i moduli vengano inviati, che i flussi di pagamento o prenotazione funzionino, che i dashboard mostrino dati aggiornati e che i file caricati siano accessibili. Se possibile, testa da più di una rete, poiché il tuo computer potrebbe avere ancora il DNS in cache.

Controlla le attività pianificate nelle ore successive. Cron job, backup, rinnovi, report, queue worker e ricevitori di webhook spesso mettono in evidenza problemi di migrazione dopo che la convalida iniziale è stata superata. Controlla anche i log della posta e i report di consegna. Se il sito usa un servizio SMTP remoto, conferma che l'IP o l'hostname del nuovo server sia autorizzato.

Lascia il vecchio server disponibile per almeno 48-72 ore, o più a lungo per applicazioni complesse o ambienti DNS lenti. Durante questo periodo, conserva i backup di entrambe le parti e non apportare modifiche di configurazione non correlate. Quando il monitoraggio è pulito, il traffico è stabile e la finestra di rollback è trascorsa, dismetti in sicurezza il vecchio server.

Sapere quando usare supporto gestito

Un semplice sito vetrina può di solito essere spostato con una preparazione accurata e una breve finestra di manutenzione. Un negozio ad alto traffico, un portfolio di agenzia con molti siti cliente, una piattaforma SaaS o un server con servizi personalizzati meritano un piano più controllato. Replica del database, rilasci graduali, drenaggio del traffico e monitoraggio attivo riducono il rischio, ma richiedono anche mani esperte.

kodu.cloud può aiutare con il lato operativo di una migrazione, dalla preparazione del server di destinazione e dai backup fino al monitoraggio e alla convalida. L'obiettivo non è rendere il processo misterioso. È garantire che qualcuno stia sorvegliando l'infrastruttura mentre tu continui a mandare avanti l'attività.

Una buona migrazione si conclude in silenzio: i visitatori usano il sito, i job pianificati vengono eseguiti, i backup si completano e nessuno deve inviare un messaggio generale pieno di nervosismo. Conserva il piano, il backup e il vecchio server finché le evidenze non dicono che il servizio è di nuovo stabile.

Andres Saar Customer Care Engineer