Quando un preventivo di migrazione contiene la frase "prevediamo qualche ora di disservizio", quella frase non descrive un limite tecnico. Descrive un metodo: si spegne di qua, si accende di là, e si spera che la propagazione sia clemente.
Il disservizio non è inevitabile. È il risultato di due scelte — cambiare il DNS prima di aver collaudato, e spegnere il vecchio server troppo presto — e si evita preparando il trasloco invece di eseguirlo.
Il principio: due ambienti vivi contemporaneamente
L'idea che rende tutto il resto possibile è semplice. Per un certo periodo il sito esiste in due posti, entrambi funzionanti, e il DNS decide gradualmente quanti visitatori vede l'uno e quanti l'altro.
Non c'è un momento in cui il servizio è spento. C'è un periodo in cui è servito da due macchine, e chi arriva su quella vecchia trova comunque un sito che risponde. Da qui discende tutto: i TTL, l'ordine delle operazioni, la doppia sincronizzazione della posta.
Fase 1: l'inventario, che è la parte che si salta
Prima di copiare qualsiasi cosa, serve sapere cosa esiste davvero. In quasi ogni migrazione andata male c'è un elemento che nessuno aveva censito:
- i cron, che non stanno nel sito: girano sul server e nessuno se li ricorda finché un report mensile non parte più;
- i certificati, e da chi vengono emessi e rinnovati;
- i sottodomini usati da servizi esterni — la webmail, un gestionale, il tracciamento delle spedizioni;
- le caselle di posta, tutte, comprese quelle di alias e di persone che non ci sono più;
- le integrazioni che chiamano il server dall'esterno: il gestionale, il corriere, il gateway di pagamento, che spesso hanno un elenco di indirizzi IP autorizzati da aggiornare;
- chi è il Registrante del dominio, perché è quello che decide se la migrazione la puoi fare o devi chiederla.
Questa fase produce un foglio. Il foglio è metà del lavoro.
Fase 2: la copia su un ambiente di prova
Sito, database e file vengono copiati sul nuovo hosting e collaudati su un indirizzo temporaneo, mentre il dominio continua tranquillamente a puntare al vecchio server.
Cosa si prova, concretamente: le pagine, i moduli di contatto, il carrello se c'è, il pannello di amministrazione, il caricamento delle immagini, i job programmati e — separatamente — l'invio di posta dal nuovo ambiente.
È qui che si scopre la versione di PHP diversa, l'estensione mancante, il percorso assoluto scritto a mano nel codice cinque anni fa. Scoprirlo adesso costa un'ora. Scoprirlo dopo il cambio DNS costa il tempo in cui il sito è rotto per tutti.
Fase 3: i TTL, il giorno prima
Il TTL è il tempo per cui i server di tutto il mondo hanno il permesso di ricordarsi la vecchia risposta. Se è di ventiquattro ore, il tuo cambio impiegherà fino a ventiquattro ore a essere visto ovunque — e, cosa più importante, un eventuale rollback impiegherà altrettanto.
Quindi: almeno ventiquattro ore prima del trasloco, i TTL dei record che cambieranno si abbassano a pochi minuti. Non è un'ottimizzazione, è ciò che rende l'operazione reversibile.
Dopo qualche giorno di calma si rialzano.
Fase 4: la posta, che è la parte delicata
Il sito è statico rispetto alla posta: puoi copiarlo e resta uguale. Le caselle no — continuano a ricevere mentre le stai copiando.
Per questo la posta si migra in due passate:
- Prima sincronizzazione, completa, mentre tutto ancora arriva sul vecchio server. Può durare ore e non disturba nessuno.
- Cambio dei record MX.
- Seconda sincronizzazione, subito dopo, che recupera i messaggi arrivati tra la prima copia e il cambio.
- Il vecchio server di posta resta acceso qualche giorno, perché ci sono mittenti e server che continueranno a bussare al vecchio indirizzo finché il loro TTL non scade.
Con questo schema non si perde niente. Saltando il punto 3, si perde esattamente la posta di quella giornata — cioè quella che le persone ricordano.
Fase 5: il cambio, e cosa si guarda subito dopo
Il cambio DNS si fa fuori orario, ma non di notte fonda: si fa quando c'è ancora qualcuno sveglio in grado di guardare i risultati.
Nei primi minuti si verificano, in questo ordine: il sito sul nuovo indirizzo, HTTPS e il certificato, un modulo di contatto reale, l'invio e la ricezione di un'email vera, le integrazioni esterne, i job programmati.
Il vecchio ambiente resta acceso finché il nuovo non ha passato tutti questi controlli e qualche giorno di traffico normale. Spegnerlo è l'ultima operazione della migrazione, non la prima.
E il posizionamento su Google?
Se il dominio non cambia, non cambia niente per la ricerca: gli indirizzi restano identici e i motori vedono solo un server diverso che risponde. Le cose che invece fanno male sono altre due, ed entrambe si evitano:
- cambiare gli URL insieme all'hosting. Se serve anche una ristrutturazione degli indirizzi, si fa in un secondo momento e con i redirect, non nello stesso weekend;
- lasciare il sito irraggiungibile a lungo. Un'ora non fa danni; un giorno intero, sì.
Il metodo descritto qui evita entrambe per costruzione.
Quanto dura, in pratica
Un sito aziendale con qualche casella di posta si prepara in un paio di giorni di lavoro non consecutivi, e il cambio vero e proprio richiede un'ora. Un e-commerce con integrazioni richiede più preparazione, non più tempo di switch.
Il numero che conta non è quanto dura il trasloco, ma quanti minuti di disservizio contiene: preparato così, zero.
Se il tuo fornitore attuale ti ha proposto una finestra di disservizio — o non collabora al passaggio — è precisamente quello di cui si occupa la migrazione di hosting e posta.