Cambiare hosting senza interrompere sito ed email: come preparare il trasferimento

Chiarire che cosa deve restare uguale

Scrivi il perimetro in una frase: trasferire il sito su un nuovo hosting mantenendo dominio, indirizzi delle pagine e funzioni concordate. Se nello stesso intervento vuoi cambiare CMS, struttura o nome del sito, stai aggiungendo attività che richiedono valutazioni proprie. Separarle nel piano consente di capire a quale cambiamento attribuire un eventuale problema.

Google distingue esplicitamente le migrazioni dell’hosting senza modifiche agli URL dai trasferimenti con nuovi indirizzi. La seconda situazione è approfondita nella guida al cambio di dominio.

Definisci anche perché vuoi spostarti: assistenza, risorse, gestione degli aggiornamenti o esigenze tecniche. Chiedi al nuovo fornitore di verificare la compatibilità con il sito effettivo. Una descrizione commerciale del piano di hosting non dimostra da sola che il progetto, con tutte le sue integrazioni, funzionerà nello stesso modo.

Il sito e la posta possono vivere in posti diversi

Ricostruisci dove sono gestiti dominio, DNS, file del sito, database e caselle email. Aggiungi servizi esterni usati dai moduli, prenotazioni, pagamenti, newsletter e aree riservate. Il compito è associare ogni funzione a un servizio e a una persona che possa verificarla, senza raccogliere password in documenti condivisi.

La documentazione Cloudflare sui record DNS della posta mostra il ruolo specifico di record come MX e TXT. Cambiare la destinazione del sito non significa automaticamente trasferire le caselle. Se cambia anche il gestore DNS, fai verificare l’intera configurazione necessaria ai servizi che devono continuare a funzionare.

Provare la nuova copia con un percorso aziendale

Concorda un ambiente di prova e chi lo può utilizzare. Non limitare il collaudo all’aspetto della homepage: scegli pagine servizio, immagini, documenti e funzioni rappresentative del lavoro quotidiano. La procedura di Google per il cambio hosting prevede di preparare e testare il nuovo ambiente prima di indirizzarvi il traffico pubblico.

Per un esempio ipotetico, considera uno studio che riceve richieste con allegati e pubblica documenti scaricabili. La prova include un invio con file consentito, un errore di compilazione, la consegna al destinatario e l’apertura del documento da telefono. Il sito può sembrare identico pur avendo un diverso limite agli allegati o una configurazione di invio mancante.

Registra risultato, eventuale problema e responsabile della correzione. Chiedi al tecnico di gestire l’accesso alla copia di prova e di evitare che questa diventi una versione pubblica indesiderata. Prima del lancio va controllata anche la rimozione dei blocchi temporanei che non devono restare sul sito definitivo.

Decidere dove finiscono le richieste durante il passaggio

Una copia fotografa il sito in un certo momento. Dopo quel momento possono arrivare nuove richieste, registrazioni, prenotazioni o modifiche ai contenuti. Chiedi quali informazioni il sito conserva e come saranno allineate prima della conclusione. Le email ricevute da un modulo e i dati registrati nel database non sono necessariamente la stessa cosa.

Prepara con i referenti una finestra operativa: chi può aggiornare il sito, quali funzioni restano attive e come si riconoscono i dati più recenti. Se occorre sospendere brevemente un’attività, definisci come viene spiegata agli utenti e quale percorso alternativo è effettivamente disponibile.

La possibilità di tornare al vecchio ambiente va valutata insieme ai dati generati nel frattempo. Un ritorno non pianificato potrebbe rendere invisibili richieste presenti soltanto sulla nuova copia. Nel piano inserisci quindi il criterio per fermare il passaggio, chi prende la decisione e come vengono riconciliate le informazioni. Non basta la dicitura generica “backup disponibile”.

Preparare il cambio DNS insieme alla verifica della posta

Il tecnico deve stabilire quali record aggiornare e quali preservare. Evita di sostituire impostazioni seguendo istruzioni generiche trovate online: la configurazione dipende dai servizi effettivamente utilizzati. Chiedi una copia della situazione precedente e un elenco delle modifiche previste, utile anche a rendere il lavoro controllabile.

Il TTL descrive per quanto tempo un record DNS può essere conservato in cache, come spiega la documentazione Cloudflare. Per questo il cambiamento può essere osservato in momenti diversi da reti differenti. L’eventuale modifica preventiva del TTL va concordata; cambiare il valore all’ultimo momento non cancella le copie già memorizzate.

Se le caselle restano dove sono, la prova deve confermare invio e ricezione sul servizio previsto. Se migrano anche le caselle, apri un’attività specifica per messaggi, configurazione dei dispositivi e passaggio finale. Nel confronto fra offerte chiedi esplicitamente quali di queste attività sono comprese: trasferimento del sito e migrazione della posta possono avere perimetri diversi.

Controllare il percorso completo dopo la pubblicazione

Dopo il cambio, ripeti le prove essenziali sull’indirizzo pubblico. Usa dati riconoscibili come test e controlla dove vengono ricevuti. Concorda verifiche da più reti e il controllo tecnico del traffico, degli errori e dell’accesso dei crawler; la guida Google include il monitoraggio del nuovo e del precedente ambiente.

• Le pagine importanti si aprono agli indirizzi previsti.
• Immagini e download funzionano anche da smartphone.
• Moduli e integrazioni consegnano i dati al referente corretto.
• Invio e ricezione della posta sono verificati separatamente.
• I nuovi contenuti vengono salvati nell’ambiente definitivo.

Non attribuire automaticamente una variazione delle visite al nuovo hosting: verifica prima che gli strumenti di misurazione funzionino e confronta periodi pertinenti. Se emergono errori, registra l’URL e l’azione che li provoca. “Non funziona dopo il trasferimento” è meno utile di una prova che un fornitore possa riprodurre.

Disdire il vecchio servizio soltanto con un quadro completo

Prima della disdetta, verifica che il vecchio piano non includa ancora servizi necessari, come posta, DNS o copie di dati da conservare. La chiusura dell’ambiente precedente va collegata al completamento del passaggio, non soltanto alla data prevista nel calendario. Chiedi conferma tecnica che il vecchio sito non sia più utilizzato per servire le richieste.

Raccogli un documento finale con ambiente attivo, fornitori, accessi assegnati ai rispettivi responsabili, rinnovi e attività di manutenzione. Indica anche ciò che non è stato trasferito, perché potrebbe servirti in un confronto futuro. Non inserire segreti o password nel normale riepilogo amministrativo.

Un trasferimento verificabile si conclude con la possibilità di gestire il sito senza dipendere da informazioni disperse. Se il motivo iniziale era migliorare assistenza o manutenzione, controlla che siano stati definiti anche canali e responsabilità successivi: il nuovo spazio hosting è solo una parte del servizio atteso.

Domande frequenti

Per cambiare hosting devo trasferire anche la registrazione del dominio?

Non necessariamente. Registrazione del dominio, gestione DNS e hosting sono funzioni distinte, anche quando vengono acquistate dallo stesso fornitore. Verifica con i soggetti coinvolti quale combinazione viene mantenuta e chi potrà gestirla dopo il passaggio.

Quanto tempo richiede il trasferimento?

La stima dipende da dimensioni, database, posta e integrazioni. Chiedi un calendario che separi preparazione, collaudo, cambio effettivo e controlli finali. La durata della copia dei file non rappresenta la durata dell’intero lavoro.

Un hosting nuovo farà salire il sito su Google?

Il trasferimento non garantisce un miglioramento dei posizionamenti. Va valutato per compatibilità, prestazioni e gestione; la visibilità dipende anche da contenuti e altri fattori. Durante il passaggio è utile controllare che il sito resti correttamente accessibile e misurabile.