Per trasferire WordPress a Xlogic senza downtime devi copiare file e database, configurare il sito sul nuovo hosting, provarlo prima del cambio DNS e sincronizzare nuovamente i dati che possono cambiare. Solo dopo il test si aggiornano A, AAAA o nameserver, mantenendo attivo il vecchio hosting durante la propagazione.
Una migrazione non consiste solamente nel copiare wp-content. WordPress dipende da file, database, configurazione PHP, cron, email, certificato, DNS e servizi esterni. Un trasferimento non pianificato può causare ordini mancanti, moduli non recapitati, redirect, contenuti misti o accesso all’amministrazione bloccato.
Questa guida illustra il flusso per trasferire WordPress a Xlogic senza downtime. I dettagli possono cambiare per multisite, WooCommerce, siti con membership, DNS esterno o configurazioni personalizzate.
Informazioni da raccogliere
- dominio e registrar;
- nameserver e gestore DNS attuale;
- percorso del sito e dimensione dei file;
- nome e dimensione del database;
- versione PHP ed estensioni;
- cron e processi pianificati;
- caselle email e servizi SMTP;
- CDN, firewall e proxy come Cloudflare;
- accessi al vecchio hosting;
- orari con meno traffico.
1. Riduci il TTL prima della migrazione
Se controlli il DNS, riduci il TTL dei record che verranno modificati almeno alcune ore prima. Un TTL più basso aiuta i resolver a conservare meno a lungo il vecchio indirizzo.
Non modificare TTL e destinazione nello stesso momento senza aver verificato la zona. Se utilizzi Cloudflare, la modifica si esegue nella dashboard Cloudflare, non nel Zone Editor locale.
2. Crea una copia completa
Salva:
- tutti i file WordPress, compresi file nascosti;
- database completo;
wp-config.php;- regole
.htaccess; - eventuali file esterni alla document root;
- configurazioni cron e variabili personalizzate;
- elenco di versione PHP, plugin e tema.
Verifica che l’archivio sia leggibile. Un backup non controllato non è una strategia di rollback.
3. Prepara il nuovo spazio Xlogic
- aggiungi il dominio al piano corretto;
- scegli una versione PHP compatibile;
- abilita le estensioni necessarie da Select PHP Version;
- crea database e utente con privilegi;
- carica i file nella document root corretta;
- importa il database;
- aggiorna le credenziali in
wp-config.php; - controlla permessi e proprietario dei file.
Non aumentare automaticamente memoria e timeout per nascondere errori. Consulta PHP Selector in cPanel e Limiti PHP.
4. Prova il sito prima del cambio DNS
Il metodo più affidabile consiste nel modificare temporaneamente il file hosts del computer amministrativo, associando dominio e www al nuovo IP. Il test riguarda soltanto quel computer e non cambia il sito pubblico.
Dopo la modifica:
- svuota cache DNS del computer;
- apri il sito in finestra privata;
- verifica che la risposta arrivi dal nuovo hosting;
- non utilizzare URL temporanei per test che modificano il database;
- rimuovi la riga hosts al termine.
Checklist del test
- homepage e pagine interne;
- login e amministrazione;
- permalink e redirect;
- immagini, CSS e JavaScript;
- form di contatto;
- invio email tramite SMTP o PHP;
- carrello, checkout e area cliente;
- webhook, API e servizi esterni;
- cron e pubblicazioni pianificate;
- cache LiteSpeed;
- errori PHP e Resource Usage.
5. Gestisci correttamente gli URL
Se il dominio non cambia, non eseguire sostituzioni inutili. Se cambia protocollo, sottocartella o dominio, utilizza strumenti compatibili con i dati serializzati di WordPress.
WP-CLI offre wp search-replace, che gestisce i dati serializzati. Prima esegui una simulazione:
wp search-replace 'https://vecchio.example' 'https://nuovo.example' --all-tables --dry-run
Solo dopo aver letto il risultato esegui il comando reale. Non effettuare sostituzioni globali con un editor sul dump SQL senza conoscere la serializzazione PHP.
6. Sincronizzazione finale
Tra la prima copia e il cambio DNS il sito originale può ricevere commenti, ordini, utenti o upload. Per un sito dinamico:
- scegli una finestra con poco traffico;
- attiva una manutenzione controllata sul vecchio sito, se necessario;
- esporta nuovamente il database;
- sincronizza gli upload creati dopo la prima copia;
- importa i dati finali nel nuovo hosting;
- ripeti i test essenziali;
- modifica i DNS.
Non sovrascrivere il database nuovo dopo che il sito ha già iniziato a ricevere ordini sul nuovo server.
7. Cambia DNS
Puoi modificare record A/AAAA oppure nameserver, in base alla configurazione. Controlla attentamente:
- IP del dominio principale;
- record
www; - eventuale AAAA;
- MX e record della posta;
- SPF, DKIM e DMARC;
- sottodomini e servizi esterni;
- record Cloudflare impostati Proxied o DNS only.
Se stai spostando solo il sito, non modificare i record email senza necessità.
8. SSL e cache
Dopo che il dominio punta al nuovo hosting, verifica AutoSSL. Controlla HTTP e HTTPS, redirect e contenuti misti. Poi svuota le cache WordPress, LiteSpeed, browser e CDN.
Non attivare contemporaneamente tutte le ottimizzazioni CSS e JavaScript durante la migrazione. Prima conferma che il sito funzioni con configurazione prudente.
9. Mantieni il vecchio hosting
Non chiudere subito il vecchio servizio. Conservalo per il periodo necessario a verificare propagazione, log e integrità dei dati. Impedisci però che due installazioni inviino contemporaneamente cron, newsletter o notifiche.
Rollback
Se emerge un problema grave prima che il nuovo sito riceva dati esclusivi, puoi riportare temporaneamente i DNS al vecchio IP. Documenta ogni modifica e considera il TTL. Se entrambe le installazioni hanno ricevuto dati, serve una riconciliazione e non un semplice ritorno indietro.
Migrazione di WooCommerce e siti con utenti
Per e-commerce, membership e portali con contenuti generati dagli utenti la sincronizzazione finale è il passaggio più delicato. Durante la finestra di passaggio impedisci nuovi ordini o registrazioni sul vecchio sito oppure utilizza una procedura incrementale progettata per le tabelle coinvolte. Non unire manualmente due database WordPress completi.
Verifica gateway di pagamento, webhook, email transazionali, licenze legate al dominio o all’IP e attività pianificate. Alcuni fornitori limitano le chiamate provenienti da un nuovo server e richiedono l’aggiornamento di whitelist o endpoint.
Controlli nelle 24 ore successive
- monitoraggio errori PHP e log web;
- verifica ordini, moduli e invii email;
- controllo cron e code programmate;
- verifica consumo di CPU, memoria e I/O;
- controllo indicizzazione, canonical e redirect;
- ricerca di richieste ancora dirette al vecchio IP.
Documenta la configurazione finale
Al termine conserva IP, nameserver, versione PHP, percorso del sito, database, cron e data del passaggio. Registra anche le esclusioni cache e gli endpoint esterni aggiornati. Questa scheda riduce il rischio di usare in futuro vecchie credenziali o riportare accidentalmente il dominio sul server precedente.
Quando aprire un ticket Xlogic
Apri un ticket prima del cambio DNS se non conosci IP, document root, versione PHP o metodo di test. Indica dominio, vecchio provider, dimensione, CMS, servizi email, Cloudflare, finestre disponibili e presenza di e-commerce. Non inviare password nel testo del ticket.
Fonti tecniche ufficiali
Domande frequenti sulla migrazione WordPress
È possibile trasferire WordPress senza downtime?
Sì, preparando e testando la copia prima del cambio DNS e sincronizzando i dati finali durante una breve finestra controllata.
Devo cambiare gli URL nel database?
Non se il dominio e il protocollo restano identici. Se cambiano, usa uno strumento compatibile con i dati serializzati e prova prima con dry-run.
Come provo il sito prima del cambio DNS?
Puoi associare temporaneamente dominio e nuovo IP nel file hosts del tuo computer, verificando che il test riguardi solo la tua postazione.
Quando posso chiudere il vecchio hosting?
Solo dopo aver verificato propagazione DNS, sito, email, cron, moduli, ordini e dati. Mantienilo disponibile come rollback per un periodo prudente.
La migrazione trasferisce anche le caselle email?
Non automaticamente. Il sito e la posta sono servizi distinti. Le caselle richiedono una migrazione e un cambio MX pianificati separatamente.