Pubblicato il
Un esempio di migrazione sito senza interruzioni non comincia dal trasferimento dei file, ma da una domanda molto concreta: cosa può cambiare sul sito mentre il nuovo ambiente viene preparato? Per un sito vetrina la risposta può essere “quasi nulla”. Per un e-commerce, un portale con login o un gestionale collegato al database, ogni nuovo ordine, utente o richiesta inviata durante la migrazione è un dato che non può andare perso.
Spostare un progetto da un hosting a un altro, oppure da un piano condiviso a un server cloud o dedicato, richiede quindi una procedura ordinata. L’obiettivo non è solo evitare che il sito risulti irraggiungibile: è mantenere coerenti file, database, posta e configurazioni fino al momento del passaggio definitivo.
Esempio di migrazione sito senza interruzioni: il caso reale
Immaginiamo un negozio PrestaShop con catalogo, clienti registrati, pagamenti online e una media di ordini distribuiti nell’arco della giornata. Il vecchio hosting ha risorse ormai limitate e il sito viene trasferito su un ambiente più performante, con storage NVMe, PHP aggiornato e configurazione ottimizzata per il carico dell’applicazione.
Il dominio resta lo stesso, ad esempio `negozio.it`. Il nuovo server riceve una copia del sito, ma non viene ancora indicato dai DNS pubblici. In questa fase i visitatori continuano a raggiungere il vecchio ambiente e il team può configurare il nuovo senza impatto sul fatturato.
La migrazione procede in quattro blocchi operativi: inventario e preparazione, copia iniziale, test riservati, sincronizzazione finale con cambio DNS. La distinzione è utile perché ogni blocco ha rischi diversi e controlli specifici.
1. Inventario prima di copiare
La prima attività è identificare tutto ciò che compone il servizio, non solo la cartella del sito. Occorre verificare versione di PHP, estensioni richieste, cron job, cache, certificati SSL, redirect, record DNS, caselle e-mail, configurazioni SMTP, database e integrazioni esterne come gateway di pagamento, ERP o sistemi di spedizione.
In molti trasferimenti il problema non è il CMS, ma un dettaglio periferico: un cron che non parte, un record SPF modificato male, una password SMTP non aggiornata o una directory di upload esclusa dal backup. Per questo conviene creare una checklist con responsabile e stato di avanzamento per ogni elemento.
Prima del cambio, il TTL dei record DNS principali può essere abbassato. Un valore più basso riduce il tempo necessario perché la nuova destinazione si propaghi dopo l’aggiornamento. Non elimina ogni variabile, perché cache locali e resolver possono comportarsi in modo diverso, ma rende il passaggio più controllabile. Questa modifica va fatta con anticipo, idealmente almeno 24-48 ore prima della finestra prevista.
2. Copia iniziale di file e database
Si esportano file e database dal vecchio ambiente e si importano sul nuovo. Per siti di grandi dimensioni è preferibile usare procedure che consentano di riprendere il trasferimento e verificare l’integrità dei dati, invece di affidarsi a un singolo archivio compresso senza controlli.
Sul nuovo hosting vanno ricreate le credenziali del database, adattati i file di configurazione e impostati correttamente permessi e proprietari delle directory. Se il progetto usa cache applicativa o opcode cache, è opportuno svuotarle prima dei test per evitare risultati falsati da contenuti precedenti.
In questa prima copia il database è inevitabilmente già “vecchio” rispetto alla produzione. Non è un problema: serve a costruire un ambiente funzionante e testabile. La sincronizzazione dei dati recenti avverrà più avanti, poco prima dell’attivazione pubblica.
3. Testare il nuovo server senza modificare il DNS
Il test non deve dipendere dal dominio pubblico. Per verificare il sito sul nuovo server mantenendo invariato l’accesso dei visitatori al vecchio, si può usare un hostname tecnico temporaneo oppure una risoluzione locale del dominio sul computer di chi esegue i controlli.
La seconda opzione è spesso la più fedele, perché consente di testare il sito con l’URL finale e con il certificato associato al dominio. Bisogna però ricordare che il test locale riguarda soltanto il computer configurato: non dimostra che il nuovo IP sia già visibile a tutti gli utenti.
I controlli devono simulare i percorsi che generano valore o assistenza. Per un e-commerce significa navigare categorie e schede prodotto, cercare articoli, aggiungere prodotti al carrello, completare un ordine di prova, controllare e-mail transazionali e pannello amministrativo. Per un sito WordPress con area riservata, invece, contano login, caricamento media, moduli, cache, aggiornamenti e integrazioni con plugin esterni.
Non basta verificare che la home page si carichi. Occorre controllare i codici HTTP, eventuali redirect in loop, pagine 404, risorse statiche, immagini, tempi di risposta e log degli errori. Se il nuovo ambiente usa LiteSpeed Enterprise, è utile validare anche il comportamento della cache: una cache ben impostata migliora le prestazioni, ma una regola errata può servire contenuti non aggiornati nel carrello o nelle aree personali.
La sincronizzazione finale: dove si decide il downtime
Dopo i test, il nuovo ambiente è pronto ma non ancora allineato agli ultimi dati. Per ridurre al minimo il rischio, si pianifica una breve finestra a basso traffico. Nel caso del negozio, si può attivare temporaneamente la modalità manutenzione o disabilitare il checkout per pochi minuti, lasciando una pagina chiara che informi i clienti.
Durante questa finestra si esegue un export finale del database dal vecchio server e si importa nel nuovo. Se ci sono file che cambiano frequentemente, come upload, documenti o immagini caricate dagli utenti, vanno sincronizzati anche quelli. Solo dopo aver confermato che l’ultima copia è completa si modifica il record DNS A o AAAA, oppure si aggiorna il puntamento del dominio secondo l’architettura utilizzata.
Questa è la differenza tra “nessuna interruzione” in senso stretto e una migrazione professionale con impatto minimo. Un sito completamente statico può passare senza finestra di blocco. Un’applicazione con scritture continue, invece, richiede quasi sempre una brevissima sospensione delle operazioni che modificano dati, salvo adottare meccanismi più complessi di replica del database e deployment progressivo.
Per molte PMI, cinque o dieci minuti di checkout sospeso in orario programmato sono una scelta più sicura ed economica rispetto a un’infrastruttura di replica progettata per zero downtime assoluto. La soluzione corretta dipende dal volume di transazioni, dal costo di un ordine perso e dalla complessità tecnica che l’azienda è pronta a gestire.
Controlli subito dopo il cambio DNS
Appena aggiornato il DNS, bisogna monitorare entrambi gli ambienti. Alcuni utenti potrebbero continuare a raggiungere il vecchio server finché la loro cache DNS non si aggiorna. Per questo il vecchio hosting non va disdetto subito: deve rimanere disponibile per un periodo di osservazione, preferibilmente con un accesso amministrativo protetto e senza modifiche parallele.
Sul nuovo server si controllano gli access log, gli error log, il consumo di risorse, la consegna delle e-mail e il corretto rinnovo o caricamento del certificato SSL. È utile eseguire nuovamente un ordine di prova o un invio modulo, verificando che dati e notifiche arrivino ai destinatari previsti.
Il monitoraggio esterno dell’URL principale e delle pagine critiche aiuta a intercettare problemi che un test interno non vede. Se il sito riceve traffico da più paesi europei, il controllo da reti diverse è ancora più utile: la propagazione DNS e i percorsi di rete non sono sempre identici.
Errori che trasformano un trasferimento in un’emergenza
L’errore più frequente è cambiare i DNS prima di aver provato davvero il sito sul nuovo ambiente. Il secondo è considerare il database una copia statica e dimenticare gli ordini o le registrazioni avvenute dopo l’export iniziale. Seguono la disdetta anticipata del vecchio servizio, l’assenza di backup verificati e il mancato controllo della posta.
Un backup disponibile non equivale automaticamente a un backup utilizzabile. Prima della migrazione è prudente verificare che l’archivio sia completo e che il ripristino sia possibile. Soluzioni gestite come R1Soft Backup sono particolarmente utili quando il progetto contiene dati operativi e serve un punto di recupero affidabile, ma anche in questo caso la procedura di restore va conosciuta prima di un problema reale.
Un altro errore è scegliere il nuovo piano guardando soltanto lo spazio disco. Un sito lento per limiti di CPU, RAM, I/O o processi contemporanei non migliora semplicemente spostando gli stessi file. La migrazione è il momento giusto per valutare se il progetto ha bisogno di hosting professionale, di risorse cloud scalabili o di un server dedicato gestito.
Preparare il prossimo passaggio prima che serva
Una migrazione ben eseguita lascia un ambiente più semplice da gestire anche dopo il go-live: credenziali documentate, backup attivi, DNS ordinato, monitoraggio configurato e una procedura ripetibile per gli aggiornamenti futuri. CoolNetwork può affiancare questa crescita con hosting, cloud, server dedicati e backup nello stesso ecosistema, evitando di frammentare dominio e infrastruttura tra fornitori diversi.
Prima di fissare la data, definisci un responsabile tecnico, una finestra di intervento e un piano di rollback. È il modo più concreto per trasformare il trasferimento del sito da un’operazione rischiosa a un passaggio controllato, misurabile e adatto alla continuità del tuo business.