Checklist: migrare dominio e sito web senza interruzioni

Che cosa viene trasferito esattamente?

Prima di iniziare, chiarisca quali dei quattro livelli cambiano. Sono indipendenti l’uno dall’altro:

1. Registrazione: presso quale registrar è registrato il dominio, ad es. Hostpoint?
2. Hosting DNS: quali name server rispondono alle richieste per il dominio, ad es. Cloudflare?
3. Web hosting: su quale server si trova il sito web?
4. Mail hosting: chi riceve e invia le e-mail?

Uno scenario frequente: il dominio resta registrato presso Hostpoint, il DNS passa a Cloudflare, il sito web si trasferisce presso un nuovo hoster e il mail hosting resta invariato. Lo stato attuale di registrar e name server lo mostra la ricerca WHOIS.

Il calendario a colpo d’occhio

• Una settimana prima: creare l’inventario, esportare la zona, preparare il nuovo server e la nuova zona.
• 24–48 ore prima: abbassare il TTL, chiarire lo stato DNSSEC.
• Giorno della migrazione: cambiare name server o modificare i record, testare sito web ed e-mail.
• Prima settimana dopo: monitorare Search Console, reindirizzamenti e report DMARC, aumentare di nuovo il TTL.
• Dopo una o due settimane: disdire il vecchio hosting.

Per il giorno della migrazione scelga un momento con poco traffico, in cui Lei stesso e idealmente anche il supporto di entrambi i provider siate raggiungibili. Un venerdì pomeriggio prima di un lungo fine settimana è una pessima scelta.

Prima della migrazione: preparazione (1–7 giorni prima)

Inventario di tutti i record DNS

Dall’esterno non è possibile elencare tutti i nomi di una zona. I selettori DKIM o i sottodomini poco usati restano invisibili se non se ne conosce il nome. Esporti quindi la zona direttamente presso il provider DNS attuale, idealmente come file di zona.

• Zona esportata e salvata presso il provider attuale
• A e AAAA annotati per dominio principale, www e tutti i sottodomini
• Record CNAME censiti (ad es. www, autodiscover, shop, domini di tracciamento)
• Record MX annotati con le priorità
• Record TXT censiti: SPF, verifiche (Google, Microsoft e altri)
• Selettori DKIM annotati (ad es. google._domainkey, selector1._domainkey)
• _dmarc, _mta-sts e _smtp._tls censiti
• Record SRV e CAA annotati

Con la ricerca DNS di NetScanner confronta i record pubblicamente visibili con la Sua esportazione.

Abbassare il TTL e chiarire i casi particolari

• TTL dei record che cambiano abbassato a 300 secondi con 24–48 ore di anticipo
• Stato DNSSEC verificato: è presente un record DS presso il registrar?
• Con DNSSEC attivo: record DS rimosso e atteso il suo TTL (oppure trasferimento delle chiavi pianificato con il nuovo provider)
• I record CAA autorizzano l’autorità di certificazione del nuovo hoster
• Credenziali di accesso per registrar, vecchio e nuovo provider a portata di mano

Perché serve un anticipo sul TTL lo spiega la guida sulla propagazione DNS.

Preparare il sito web

• Backup completo di file e banca dati eseguito
• Sito web configurato sul nuovo server e testato tramite il file hosts locale
• Certificato SSL sul nuovo server pianificato (molti hoster lo emettono solo quando il dominio punta a loro)
• In caso di URL modificati: elenco dei reindirizzamenti 301 dal vecchio al nuovo creato
• Moduli di contatto: tramite quale server invia le e-mail il nuovo hoster?

Durante la migrazione

Spostare il DNS su Cloudflare e mantenere la registrazione presso Hostpoint

1. Aggiungere il dominio su Cloudflare. Cloudflare riprende i record esistenti tramite una scansione, ma non li riconosce necessariamente tutti.
2. Confrontare la nuova zona record per record con la Sua esportazione e completare ciò che manca, in particolare selettori DKIM e verifiche.
3. Impostare su «DNS only» i record per la posta (destinazioni MX, nomi host dei server di posta). Il proxy di Cloudflare inoltra solo il traffico web, non le e-mail.
4. Nel Control Panel del registrar, ad es. presso Hostpoint, sostituire i name server con i due assegnati da Cloudflare. La registrazione resta presso il registrar, cambia solo la delega.
5. Non eliminare né modificare più la vecchia zona. Alcuni resolver interrogano ancora per un certo tempo i vecchi name server.

Passare al nuovo sito web

1. Congelare le modifiche ai contenuti sul vecchio sito; per gli shop, tenere d’occhio gli ordini.
2. Trasferire sul nuovo server l’ultima versione di banca dati e file.
3. Modificare i record A e AAAA (o il CNAME) verso il nuovo server.
4. Far emettere il certificato SSL non appena i record puntano al nuovo server.

Subito dopo la migrazione: verificare

• Il WHOIS mostra i nuovi name server
• Tutti i record della nuova zona corrispondono all’inventario
• Sito web raggiungibile con e senza www, HTTP reindirizza a HTTPS
• Certificato SSL valido per dominio principale e www
• I vecchi URL reindirizzano con 301 ai nuovi
• Header di sicurezza impostati; reindirizzamenti, header e cookie li controlla con la verifica header HTTP
• Test e-mail in entrambe le direzioni con indirizzi esterni (ad es. Gmail e Outlook.com); nell’intestazione dell’e-mail ricevuta SPF, DKIM e DMARC risultano superati
• I moduli di contatto inviano e-mail e il nuovo server web è incluso nel record SPF

I record di posta li controlla in un unico passaggio la verifica e-mail: MX, SPF con conteggio dei lookup, DMARC, i selettori DKIM più diffusi nonché MTA-STS e TLS-RPT. Approfondimenti sui record li trova nella guida Configurare SPF, DKIM e DMARC.

Nei giorni successivi

1. Search Console: verificare che la proprietà sia ancora confermata (TXT di verifica ripreso?). Inviare di nuovo la sitemap e monitorare i rapporti sugli errori per le pagine 404. In caso di cambio di dominio utilizzare anche la funzione «Cambio di indirizzo».
2. Aumentare il TTL: se tutto funziona in modo stabile, riportare il TTL a 3600 secondi o più.
3. Attivare DNSSEC: abilitarlo presso il nuovo provider DNS e registrare il nuovo record DS presso il registrar.
4. Leggere i report DMARC: le nuove fonti di invio compaiono qui per prime.
5. Disdire il vecchio hosting: non prima di una o due settimane e solo dopo aver salvato un backup aggiornato.

Ostacoli frequenti

• Record DKIM o di verifica mancanti: raramente figurano nella documentazione dell’hoster, di solito solo nella vecchia zona.
• Proxy sui nomi host di posta: un nome di server di posta instradato tramite il proxy di Cloudflare non è raggiungibile per le e-mail.
• Record DS obsoleto: se il record DS della vecchia zona resta presso il registrar, la risoluzione fallisce con i resolver che effettuano la convalida.
• Consegna locale presso il vecchio hoster: se sul vecchio server web è ancora configurata una casella di posta per il dominio, spesso le e-mail dei moduli vengono consegnate localmente invece di essere inviate al server MX. Rimuova lì il dominio di posta.
• Eliminazione prematura della vecchia zona: i resolver con vecchi record NS memorizzati non ricevono più alcuna risposta.