Trasferiamo regolarmente siti web e caselle di posta dei clienti su nuovi hosting – spesso sulla nostra infrastruttura cloud, a volte tra fornitori esterni. Le richieste di hosting e migrazione hanno costituito il 4% delle nostre richieste di manutenzione, e l'accesso a hosting, domini e DNS è emerso in 28 dei nostri 110 progetti WordPress.
Una migrazione ben fatta è invisibile. Una migrazione mal fatta significa email perse, un sito non accessibile per alcuni visitatori o un negozio non funzionante. Ecco cosa abbiamo imparato.
Lezione 1: l'accesso è il primo traguardo
Prima di qualsiasi lavoro tecnico, abbiamo bisogno di accesso a:
- L'attuale hosting (per copiare file e database)
- Il registrar del dominio o il fornitore DNS (per puntare il dominio)
- L'attuale configurazione email (per migrare le caselle di posta)
L'hosting dei clienti è presso molti fornitori diversi – IONOS, Strato, GoDaddy, all-inkl, Namecheap e altri – ciascuno con il proprio pannello di controllo. Alcuni non offrono strumenti comuni come cPanel o Plesk, quindi lavoriamo con la loro interfaccia. I trasferimenti di dominio necessitano di un codice di autorizzazione dal registrar attuale.
La raccolta degli accessi è la fonte di ritardo più comune nelle migrazioni. Iniziamo da questa.
Lezione 2: l'email è la parte che fa male
I siti web possono essere copiati e testati prima del passaggio. L'email è in tempo reale: i messaggi arrivano ogni minuto. Quando i DNS cambiano, anche l'instradamento delle email cambia. Se i record di posta sono errati o le caselle di posta non sono pronte sul nuovo host, i messaggi rimbalzano o scompaiono.
Cosa facciamo:
- Inventario di tutte le caselle di posta, alias e inoltri prima del trasferimento
- Crearle in anticipo sul nuovo host
- Copiare la posta esistente nelle nuove caselle di posta
- Cambiare i record di posta in un momento tranquillo
- Sincronizzare ancora una volta dopo il passaggio per catturare i messaggi consegnati al vecchio server durante la propagazione
- Testare l'invio e la ricezione da ogni casella di posta
Se l'email deve rimanere con il fornitore attuale, ci assicuriamo che il trasferimento del sito non tocchi i record di posta.
Lezione 3: lo storage richiede pianificazione
Le caselle di posta e le librerie multimediali sono spesso molto più grandi del previsto. Prima di una migrazione controlliamo lo storage necessario e pianifichiamo la crescita. In un incidente su un server di posta, lo storage non è riuscito a montare e gli indici delle caselle di posta sono stati corrotti; il recupero ha richiesto un lavoro accurato. Da allora, la pianificazione e il monitoraggio dello storage sono una parte standard delle nostre migrazioni.
Lezione 4: il DNS richiede tempo
I cambiamenti DNS non sono istantanei ovunque. Per un periodo, alcuni visitatori raggiungono il vecchio server e alcuni il nuovo. Abbassiamo in anticipo la durata dei record DNS dove possibile, manteniamo l'hosting vecchio attivo fino al completamento della propagazione e evitiamo di cambiare contenuti durante il passaggio.
Spostare la gestione DNS a un fornitore come Cloudflare può rendere i cambiamenti futuri più veloci e aggiunge un livello di protezione – ma è esso stesso un cambiamento da pianificare con cura.
Lezione 5: testare sul nuovo server prima del passaggio
Testiamo il sito sul nuovo server tramite un indirizzo temporaneo o un override locale dell'host prima di cambiare DNS: pagine, moduli, checkout del negozio, accessi, integrazioni. Solo quando tutto funziona facciamo il passaggio.
Lezione 6: controlli cosa dipende dal vecchio server
- Cron job e attività programmate
- Integrazioni che inseriscono nella whitelist l'indirizzo IP del vecchio server
- Impostazioni SMTP nel sito web
- Certificati SSL
- Percorsi codificati
La nostra lista di controllo per la migrazione
| Fase | Compiti |
|---|---|
| Preparazione | Raccogliere accesso; inventario del sito web, caselle di posta, record DNS; pianificare l'archiviazione; ridurre la durata del DNS |
| Copia | File, database, caselle di posta al nuovo host |
| Test | Sito sul nuovo server tramite accesso temporaneo; moduli, checkout, accessi, integrazioni |
| Cambia | Aggiorni DNS o nameserver in un momento tranquillo |
| Verifica | Sito, SSL, invio e ricezione email, moduli, integrazioni |
| Sincronizzazione finale | Posta consegnata al vecchio server durante la propagazione |
| Pulizia | Mantenga il vecchio hosting per un periodo di sicurezza, poi lo annulli |
Migrazione come parte di un nuovo sito web
Molte migrazioni avvengono insieme al lancio di un sito web: il nuovo sito è costruito nel nostro ambiente di staging e al momento del go-live si sposta al nuovo hosting contemporaneamente. Questo è efficiente, ma combina due cambiamenti rischiosi. Li manteniamo in passaggi separati dove possibile – prima confermi che il nuovo hosting funzioni senza toccare l'email, poi lanci il nuovo sito – così se qualcosa va storto, è chiaro quale cambiamento lo ha causato. Il giorno del lancio, il go-live stesso è solitamente breve; la preparazione intorno all'accesso e al DNS è ciò che richiede tempo.
Quando migrare
Buone ragioni per trasferirsi: hosting lento, frequenti interruzioni, supporto scadente, software del server obsoleto, consolidamento dei servizi o limiti di archiviazione. Momenti sbagliati: durante una campagna, una vendita o un lancio di prodotto.
FAQ
Il mio sito web sarà offline durante la migrazione?
Di solito no. Prepariamo tutto sul nuovo server e cambiamo il DNS, quindi i visitatori si spostano gradualmente senza interruzioni.
Perderò email?
Non con una pianificazione adeguata: le caselle di posta sono preparate in anticipo e una sincronizzazione finale cattura tutto ciò che viene consegnato durante il passaggio.
Quanto tempo richiede una migrazione?
Il lavoro tecnico è spesso breve. La tempistica complessiva dipende principalmente dalla rapidità con cui è disponibile l'accesso e dalla propagazione del DNS.
Perché l'accesso all'hosting e al DNS è così importante?
Perché il sito finito non può andare online senza di esso. Argomenti come hosting, dominio o DNS sono emersi nel 25% dei nostri progetti WordPress. Risolvere chi controlla il dominio prima della settimana di lancio evita che un sito finito rimanga in attesa su staging.
Con quale frequenza i siti web mantenuti necessitano di interventi?
Tra i nostri 18 contratti di manutenzione, i clienti hanno inviato una media di 4,3 richieste al mese, variando da 1,2 a 14,7.
Da dove provengono i numeri: i nostri registri di progetto in Odoo – 233 progetti completati, 909 attività e circa 4941 ore registrate, principalmente dal 2025 al 2026. Le durate sono giorni di calendario dall'inizio e citiamo le mediane, quindi un progetto insolitamente lungo non distorce il quadro.
Sta pianificando un progetto di manutenzione e hosting?
Se desidera un piano realistico per il Suo progetto, prenota una call con il nostro team e La guideremo attraverso le fasi, ciò di cui abbiamo bisogno da Lei e dove i progetti come il Suo solitamente perdono tempo. Può anche sfogliare i lavori completati nel nostro portfolio di manutenzione e hosting.
Comments