Cambia hoster: il tuo sito lo migriamo noi, gratis

La migrazione, nell'ordine in cui si fa

Una migrazione raramente fallisce sulla tecnica: fallisce sull'ordine. Il TTL abbassato dopo il passaggio, il MX modificato prima di aver creato le caselle, il vecchio contratto disdetto prima di aver riletto i registri — ognuna di queste inversioni costa mezza giornata. Ecco la sequenza completa, dal primo inventario alla disdetta.

I riferimenti in giorni valgono per un sito o un server ordinario. Un negozio in piena stagione, o un parco di diverse decine di caselle di posta, richiede di allungare queste tappe, non di saltarne qualcuna.

1. G-7 — Fare l'inventario di quello che gira davvero. I siti e i loro domini, la versione di PHP in servizio, le basi di dati e il loro motore, le caselle e il loro volume, le attività pianificate, i certificati e la loro data di scadenza, e i servizi di terzi che conoscono il tuo indirizzo IP attuale (gateway di pagamento, relay SMTP, webhook). È questa lista, non la tua memoria, che servirà da controllo finale.
2. G-7 — Dimensionare la destinazione sull'uso reale, non sull'offerta che paghi oggi. Rileva lo spazio disco occupato, la dimensione delle basi, la memoria effettivamente consumata. Un sito che sta in 6 GB non ha bisogno di un'offerta da 200 GB solo perché la vecchia la annunciava.
3. G-5 — Aprire il nuovo hosting e allestire la copia. File e basi vengono trasferiti una prima volta, per intero, senza che nulla cambi sul lato pubblico. Questa copia non deve essere aggiornata al secondo: serve a verificare che l'applicazione parta.
4. G-3 — Congelare le modifiche sul vecchio server. Nessuna pubblicazione di articoli, nessun aggiornamento di estensioni, nessuna ritocco al tema fino al passaggio. Tutto ciò che viene scritto dopo questo punto dovrà essere risincronizzato a mano.
5. G-2 — Abbassare il TTL dei record che cambieranno, a 300 secondi. Questa tappa si fa almeno 48 ore prima del passaggio, per il motivo spiegato nella sezione DNS più sotto. È la tappa che più spesso si fa troppo tardi, e l'unica che non si recupera.
6. G-1 — Provare la copia sotto il suo vero nome di dominio, senza toccare il DNS pubblico: modifica il file hosts della tua postazione per far puntare il dominio al nuovo indirizzo IP. Vedi allora esattamente quello che vedranno i tuoi visitatori, link assoluti e reindirizzamenti compresi.
7. G-1 — Preparare la zona DNS di destinazione senza pubblicarla. Annota i valori esatti dei record A, AAAA, MX, SPF, DKIM, DMARC e CAA che andrai a impostare. Scriverli in anticipo evita di improvvisarli il giorno stesso, quando il sito è già a metà del passaggio.
8. Giorno G — Risincronizzare il delta. Una seconda passata di copia trasferisce solo quello che si è mosso da G-5, poi un export fresco della base sostituisce il precedente. È questa seconda passata, breve, che definisce la vera finestra di indisponibilità.
9. Giorno G — Pubblicare i nuovi record DNS. Con un TTL a 300 secondi impostato due giorni prima, il passaggio diventa effettivo in pochi minuti per la maggior parte dei visitatori, non in ventiquattro ore.
10. Giorno G — Svolgere le verifiche nell'ordine indicato più sotto. Non spuntare nulla a memoria: apri la lista e prova davvero.
11. G+1 — Rialzare il TTL al suo valore abituale; 3600 secondi vanno bene nella maggior parte dei casi. Un TTL costantemente corto moltiplica senza motivo le interrogazioni ai tuoi server dei nomi.
12. G+7 — Disdire il vecchio contratto, non prima. Aspetta di aver ricevuto posta sulle nuove caselle, ripristinato un backup presso il nuovo hoster e riletto i registri degli errori. Una disdetta cancella spesso i dati il giorno stesso.

Che cosa si trasferisce, e con quale strumento

Un hosting non è un blocco unico: è una pila di elementi che si spostano ciascuno con il proprio strumento. Trattarli separatamente evita l'errore più comune, che consiste nel copiare i file e sperare che il resto segua.

• I file. rsync via SSH quando entrambi i lati lo permettono, SFTP altrimenti. Due passate valgono più di una: una prima completa mentre il sito gira, una seconda appena prima del passaggio che riprende solo le differenze. Verifica poi che permessi, proprietari e collegamenti simbolici siano sopravvissuti — un FTP mal configurato li appiattisce senza avvisare.
• Le basi di dati. mysqldump --single-transaction --quick per MySQL e MariaDB, pg_dump -Fc per PostgreSQL. Rileva il set di caratteri e la collation della base di origine, e ricrea la base di destinazione con gli stessi: è questo dettaglio che trasforma le lettere accentate in caratteri illeggibili dopo l'import.
• Il backup del pannello. Se il tuo hosting attuale è amministrato da un pannello, la sua esportazione integrata — file, basi, caselle e impostazioni in un solo archivio — è spesso la via più sicura. Le nostre offerte di hosting web sono consegnate con il pannello Plesk, che dispone dei propri strumenti di backup e ripristino.
• L'immagine del disco, per un server intero. Su un VPS o un server dedicato ci sono due strade: ricopiare il disco così com'è (immagine raw o qcow2, oppure copia blocco per blocco da un sistema di soccorso), o ripartire da un sistema pulito e ridistribuire l'applicazione sopra. Se il tuo hoster attuale non dà accesso all'immagine del disco, la seconda strada è l'unica possibile — ed è comunque quella che consigliamo per un sistema di diversi anni.
• I certificati. Non spostarli: un certificato Let's Encrypt si riemette in pochi secondi sul nuovo server, una volta puntato il dominio. Se paghi un certificato a validazione estesa, esporta la chiave privata prima di disdire, altrimenti bisognerà ricomprarlo.
• Le caselle di posta. Una sincronizzazione IMAP ricopia i messaggi, l'albero delle cartelle e gli stati letto o non letto da un server all'altro. Passala due volte, come per i file: una prima del passaggio, una dopo, per recuperare i messaggi arrivati nel frattempo.
• Le attività pianificate e i servizi. I cron, i timer systemd, le code di attesa e i processi permanenti non figurano in nessun backup di sito. Ricopiali a mano, poi verifica che girino dopo il passaggio, non solo che siano dichiarati.
• I segreti. Chiavi SSH autorizzate, token di API, chiavi di cifratura applicative, credenziali di servizi: vivono spesso fuori dalla cartella del sito e si perdono silenziosamente. Un'applicazione che parte ma non decifra più i suoi dati è quasi sempre una chiave rimasta sul vecchio server.

Il DNS: che cosa si prepara prima, che cosa passa il giorno G

Il DNS è la parte della migrazione che non controlli da solo. Tra la tua zona e i tuoi visitatori ci sono dei resolver che tengono in memoria la vecchia risposta per esattamente la durata che hai annunciato loro. Questa durata si chiama TTL, ed è la sola leva di cui disponi per accorciare il passaggio.

Da qui la regola: il TTL si abbassa prima, mai durante. Se il tuo TTL vale oggi 86400 secondi e lo porti a 300 la mattina del passaggio, i resolver che detengono già il vecchio valore continueranno a rispettarlo per ventiquattro ore. Abbassandolo 48 ore prima, lasci scadere da sé il vecchio valore, e il passaggio diventa una questione di minuti.

1. 48 ore prima: abbassare il TTL a 300 secondi su tutti i record che andrai a modificare — almeno A e AAAA, più il MX e i CNAME associati se si sposta anche la posta. Il TTL si imposta nella zona DNS, presso chi ospita quella zona: il tuo registrar, nella maggior parte dei casi.
2. Rilevare la zona attuale prima di toccarla. Un'interrogazione dig tuodominio.it ANY, o un export di zona dall'interfaccia, ti dà lo stato di partenza. Conservalo: è il tuo punto di ritorno se qualcosa va male.
3. A e AAAA. Il record A porta l'indirizzo IPv4 del nuovo hosting, AAAA il suo indirizzo IPv6 se ne ha uno. Non dimenticare né www né i sottodomini realmente usati: un webmail, un'api, una preproduzione. Quelli che si dimenticano sono quelli che non si visitano mai di persona.
4. MX: il record che si dimentica. Designa il server che riceve la tua posta, ed è indipendente da quello che ospita il sito. Se la tua posta resta dov'è, non toccarlo: è l'errore classico del passaggio « sostituiamo tutti gli IP della zona », che dirotta la posta verso un server che non la conosce. Se la posta si sposta, cambia il MX solo dopo aver creato e sincronizzato le caselle.
5. SPF. È un unico record TXT che elenca i server autorizzati a inviare posta a tuo nome. Se continua a designare il vecchio hosting, i messaggi partiti dal nuovo finiranno in posta indesiderata o verranno rifiutati. Aggiungi il nuovo server prima del passaggio, togli il vecchio quando la migrazione è confermata — e tieni un solo record SPF: due si annullano a vicenda.
6. DKIM. La firma è prodotta dal server che invia e verificata grazie a una chiave pubblica pubblicata nella tua zona, sotto un selettore. Pubblica il selettore del nuovo server prima del passaggio e lascia il vecchio al suo posto qualche giorno: due selettori coesistono senza disturbarsi, cosa che non vale per l'SPF.
7. DMARC. Indica ai destinatari che cosa fare dei messaggi che non superano i controlli precedenti. Durante una migrazione resta in p=none con un indirizzo per i rapporti: osservi senza rompere nulla, e irrigidisci la politica quando SPF e DKIM sono in ordine su entrambi i lati.
8. CAA, se esiste. Questo record elenca le autorità autorizzate a emettere un certificato per il tuo dominio. Se non menziona quella usata dal tuo nuovo hoster, l'emissione fallisce in silenzio e il sito resta in HTTPS non valido, senza un messaggio di errore esplicito da nessuna parte.
9. Reverse DNS (PTR). Non si imposta nella tua zona ma sull'indirizzo IP, quindi presso l'hoster che lo detiene. Conta appena il tuo server invia posta da sé: senza un PTR coerente con il nome annunciato, una parte dei destinatari rifiuta il messaggio. Da noi il reverse DNS può essere personalizzato su richiesta.

L'indisponibilità reale, e come ridurla quasi a nulla

L'interruzione che la maggior parte delle persone teme — « il mio sito sarà irraggiungibile durante la propagazione DNS » — non esiste se i due hosting rispondono nello stesso momento. Durante la propagazione una parte dei visitatori arriva sul vecchio server, l'altra sul nuovo, e entrambi mostrano il sito. Nessuno vede un errore.

La vera finestra è altrove: è il momento in cui il sito accetta ancora scritture da un lato mentre la base è già stata esportata. Un ordine effettuato durante quella finestra è registrato sul vecchio server e non esisterà mai sul nuovo. Ridurre l'indisponibilità significa dunque ridurre quella finestra di scrittura — non combattere contro il DNS.

• Sito vitrina o sito statico: nessuna interruzione. Nulla si scrive lato server, la copia può essere fatta il giorno prima, e il passaggio non richiede alcuna precauzione particolare.
• Sito con base di dati: qualche minuto. Si mette il sito in sola lettura o in manutenzione, si esporta la base, la si importa, si passa. Su un sito ordinario la manovra sta in cinque-quindici minuti, da programmare in un'ora di basso traffico.
• Negozio online: la stessa finestra, ma annunciata. Avvisa il team, scegli un momento davvero tranquillo — spesso la prima mattina — e confronta poi gli ultimi ordini sui due lati prima di considerare il vecchio server come usa e getta.
• Posta: nessuna interruzione, ma un periodo di sovrapposizione. Finché il MX non è propagato ovunque, dei messaggi continuano ad arrivare sul vecchio server. Mantienine l'accesso qualche giorno e rifai una sincronizzazione IMAP dopo il passaggio: è questo che evita il messaggio perso.
• Applicazione con coda di attesa o elaborazioni differite: svuota la coda prima. Un lavoro in corso al momento dell'export andrà perso, o verrà rieseguito due volte. Ferma i consumatori, lascia svuotare la coda, poi esporta.

Dopo il passaggio: le verifiche, nell'ordine

Questa lista si percorre dall'alto verso il basso il giorno del passaggio. L'ordine non è decorativo: ogni punto presuppone il precedente verificato, e un esito negativo al punto 2 rende tutti i successivi non interpretabili.

1. La risoluzione DNS. Interroga un resolver pubblico e quello del tuo fornitore di accesso: entrambi devono restituire il nuovo indirizzo. Finché non è così, quello che vedi nel tuo navigatore non dimostra nulla.
2. Il sito risponde, dalla macchina giusta. curl -I https://tuodominio.it deve restituire un codice 200; in caso di dubbio, curl --resolve permette di forzare l'indirizzo e di confrontare i due server uno accanto all'altro.
3. Il certificato. Valido, con il nome giusto, e che copre anche www. Conta qualche minuto dopo la propagazione per un'emissione automatica; oltre l'ora, vai a guardare il record CAA.
4. I reindirizzamenti. Da HTTP a HTTPS, e da www al dominio nudo o viceversa — ma in un solo senso, in 301 e non in 302, e senza catene di due reindirizzamenti successivi.
5. Le pagine profonde. La home funziona quasi sempre. Apri cinque o sei URL interni presi a caso: è lì che si vedono le regole di riscrittura perse e i link assoluti rimasti sul vecchio dominio.
6. I moduli. Invia un messaggio di prova dal modulo di contatto e verifica che arrivi. Un modulo che mostra « grazie » senza spedire nulla è il difetto post-migrazione più frequente.
7. Il pagamento, se ce n'è uno. Un ordine di prova in modalità sandbox, fino alla conferma e all'e-mail associata. Verifica di passaggio che il gateway non abbia una lista di indirizzi IP autorizzati da aggiornare.
8. La posta in uscita. Invia un messaggio dal sito verso un indirizzo esterno, apri l'intestazione del messaggio ricevuto e leggi i risultati SPF e DKIM. Serve « pass » su entrambi; altrimenti riprendi la sezione DNS.
9. La posta in entrata. Scrivi dall'esterno a uno degli indirizzi migrati, e continua a sorvegliare la vecchia casella per qualche giorno.
10. Le attività pianificate. Aspetta che un'esecuzione sia passata e verificane la traccia, piuttosto che la sola presenza della riga nella tabella delle attività.
11. I registri degli errori. Rileggili durante le prime 48 ore. Un'estensione mancante o un percorso assoluto rimasto fisso nel codice si vede immediatamente, spesso prima che qualcuno se ne lamenti.
12. Un primo backup presso il nuovo hoster. Prendilo, poi ripristinalo una volta per verificare che sia utilizzabile. È la condizione da soddisfare prima di disdire il vecchio contratto.

Le trappole che fanno perdere una giornata

• Il TTL abbassato il giorno stesso. Non serve a nulla: il vecchio valore, lungo, è già in cache. Una parte dei tuoi visitatori resta sul vecchio server tutta la giornata, e tu cerchi un guasto che non esiste.
• Il MX sostituito per riflesso. Sostituire « tutti gli IP della zona » porta via la posta insieme al sito. Se la posta non si sposta, il MX non si muove.
• L'SPF lasciato sul vecchio server. Il sito funziona, le e-mail partono, e nessuno le riceve — oppure finiscono in posta indesiderata. È il difetto più difficile da diagnosticare a posteriori, perché nulla fallisce in modo visibile.
• Il vecchio contratto disdetto troppo presto. La disdetta cancella i dati, spesso il giorno stesso, e porta con sé i messaggi arrivati dopo il passaggio e la sola copia ancora fresca dei file.
• Il certificato richiesto prima che il DNS punti. La convalida fallisce, il sito si mostra con un avviso di sicurezza, e il navigatore tiene l'errore in memoria. Aspetta la propagazione, poi chiedi l'emissione.
• Il robots.txt di preproduzione ricopiato così com'è. Un Disallow: / ereditato dall'ambiente di prova deindicizza il sito in pochi giorni. Rileggi quel file subito dopo il passaggio.
• La versione di PHP che cambia senza che sia stato deciso. Il nuovo hosting propone spesso una versione più recente per impostazione predefinita. Riproduci prima la versione di origine, aggiorna poi, una volta che la migrazione è dietro le spalle.
• La cache e la CDN dimenticate. Se una CDN si trova davanti al tuo sito, non è il record A pubblico che va cambiato, ma l'origine dichiarata nella CDN. E svuota la cache dopo il passaggio, altrimenti continui a servire il vecchio sito.
• Le liste di indirizzi IP autorizzati presso i terzi. Gateway di pagamento, relay SMTP, API di un partner, base di dati remota: tutto ciò che filtra per indirizzo IP deve conoscere il nuovo prima del passaggio, non dopo.

Migrare un server non è migrare un sito

Le due operazioni portano lo stesso nome e non hanno lo stesso contenuto. Migrare un sito significa spostare file, una base e delle caselle verso un hosting già amministrato: il sistema, gli aggiornamenti di sicurezza e il pannello sono forniti. È quello che copre la migrazione svolta da noi verso le nostre offerte di hosting web.

Migrare un server significa ricostruire una macchina: sistema, pacchetti, servizi, firewall, utenti, certificati, backup. Su un VPS KVM ottieni un indirizzo IPv4 dedicato, un accesso root in SSH e un pannello che offre riavvio, reinstallazione, istantanee e console. Quella console conta il giorno del passaggio: è lei che ti permette di riprendere il controllo se una regola del firewall ti chiude la porta SSH.

Il nostro consiglio, quando la macchina di origine ha diversi anni: non ricopiare il disco, ricostruisci. Altrimenti erediti impostazioni di cui nessuno conosce più il motivo. Prendi un'istantanea appena prima di ogni tappa delicata — non costa nulla in tempo e trasforma un errore in un semplice ritorno indietro. Per un'infrastruttura intera da spostare, descrivici l'esistente in un preventivo: definiamo la sequenza con te invece di annunciare un tempo prima di aver visto la macchina.

Il posizionamento durante la migrazione

Cambiare hoster mantenendo lo stesso dominio e gli stessi URL non ha, in sé, alcun effetto sul posizionamento: per un motore di ricerca cambia solo l'indirizzo IP, e non è un criterio di classificazione. Le perdite osservate dopo una migrazione vengono quasi sempre da altro.

• URL che cambiano senza reindirizzamento. Se la struttura evolve insieme all'hosting, prepara la tabella di corrispondenza prima del passaggio e servi dei 301, non dei 302. Conservali per dodici mesi almeno.
• Un blocco dell'indicizzazione involontario. robots.txt, intestazione X-Robots-Tag, tag noindex ereditato da un ambiente di prova: verifica tutti e tre il giorno stesso.
• Un sito più lento di prima. La cache applicativa e la compressione sono spesso da riattivare sul nuovo hosting. Confronta il tempo di risposta prima e dopo, invece di darlo per scontato.
• Una mappa del sito rotta. Verifica che resti accessibile e aggiornata, poi lascia che il motore torni da sé. Il ritmo di scansione si ristabilisce in pochi giorni; non c'è nulla da forzare se gli URL non si sono mossi.