Come migrare WordPress su un nuovo hosting senza downtime: procedura sicura passo passo

Migrare WordPress su un nuovo hosting senza downtime assoluto non è sempre possibile: i resolver DNS possono conservare il vecchio indirizzo in cache e, nei siti dinamici, utenti e clienti possono continuare a creare dati durante il passaggio. Con una preparazione corretta, però, il cambio può risultare quasi impercettibile per un sito vetrina e controllato anche per progetti più complessi.

Questa procedura riguarda il trasferimento a parità di dominio, HTTPS, struttura URL e variante www/non-www. In queste condizioni non servono normalmente redirect 301, una procedura Change of Address in Search Console o una sostituzione globale degli URL nel database.

Procedura di migrazione in 9 passaggi

1. Verifica il nuovo hosting, gli accessi tecnici e i servizi collegati al sito.
2. Salva una copia della zona DNS e crea un backup completo, esterno ai due hosting.
3. Crea database e utente sul nuovo server.
4. Trasferisci file e database con una prima copia.
5. Configura la copia e testala in privato con il dominio reale.
6. Verifica certificato SSL, email del sito, cache, CDN e integrazioni.
7. Se il sito riceve scritture, bloccale temporaneamente e importa un dump finale del database.
8. Modifica solo i record DNS necessari per il web.
9. Controlla le funzioni essenziali e mantieni operativo il vecchio hosting durante la propagazione.

I passaggi 1-6 preparano la nuova copia senza coinvolgere gli utenti. Il passaggio 7 è indispensabile per WooCommerce, membership, form, commenti, login e altri siti in cui vengono creati o aggiornati dati.

1. Preparazione: ambiente, backup e servizi esterni

Prima di trasferire file o database, conferma che dominio, HTTPS, struttura dei permalink, percorso pubblico e versione con o senza www rimarranno invariati. Se questi elementi non cambiano, non modificare le opzioni home e siteurl solo perché cambia il server.

Raccogli gli accessi al vecchio e al nuovo hosting, al provider DNS e ai servizi esterni: CDN, WAF, SMTP, storage media, cron, API, gateway di pagamento e webhook. Verifica anche se firewall, servizi SMTP o API autorizzano uno specifico indirizzo IP del server.

Controlla la compatibilità del nuovo hosting

Confronta i due ambienti prima della copia: versione PHP, estensioni richieste, MySQL o MariaDB, charset e collation, spazio disco, limiti di memoria, upload e timeout. WordPress indica PHP 8.3 o superiore, MariaDB 10.11+ oppure MySQL 8.0+, HTTPS e Apache o Nginx tra i requisiti consigliati; temi, plugin e codice personalizzato possono avere esigenze ulteriori. Consulta i requisiti ufficiali di WordPress e verifica la compatibilità effettiva del sito.

Controlla inoltre regole di rewrite, cron, object cache come Redis o Memcached, CDN/WAF e configurazione SMTP. Un database importato correttamente non basta se una di queste dipendenze resta configurata per il vecchio server.

Crea un backup completo e verificabile

Conserva almeno un backup fuori da entrambi gli hosting. Deve includere file e database: core WordPress, wp-content, temi, plugin, upload, file di configurazione rilevanti e tabelle del database. L’export XML/WXR di WordPress non è un backup completo, perché non contiene l’intera installazione e tutte le configurazioni tecniche.

Controlla che l’archivio sia leggibile e che il database possa essere importato. La documentazione WordPress sulla migrazione di un’installazione descrive il trasferimento di file e database come elementi distinti della procedura.

Verifica separatamente la posta

La migrazione di WordPress non trasferisce automaticamente caselle email, archivi IMAP, filtri, inoltri e risponditori del provider di posta. Prima di modificare il DNS, verifica dove puntano i record MX e se la posta è ospitata dal vecchio provider, da un servizio esterno o dal nuovo hosting.

Salva l’intera zona DNS, inclusi record A, AAAA, CNAME, MX, SPF, DKIM, DMARC, sottodomini e record di verifica. Modificare i record web non equivale a cambiare i nameserver: il cambio dei nameserver sposta la gestione dell’intera zona e richiede di ricreare tutti i record necessari. Se cambia anche il provider email, pianifica il trasferimento delle mailbox come attività separata e verifica invio e ricezione dopo il cutover.

2. Prima copia di file e database

Puoi usare una migrazione gestita dal provider, un plugin oppure la procedura manuale. Per un sito standard, il servizio del nuovo hosting può ridurre il lavoro operativo; chiedi comunque quali elementi sono inclusi e come vengono trattati dati recenti, email, DNS, CDN, SMTP, webhook e licenze.

Con un plugin come Duplicator, il flusso documentato prevede la creazione di archivio e installer, il caricamento nella directory di destinazione e l’esecuzione dell’installer. La directory deve essere vuota o verificata con attenzione; al termine, installer e archivi devono essere rimossi. Consulta il processo di installazione di Duplicator per i dettagli specifici del plugin.

Nella procedura manuale, crea il database e il relativo utente sul nuovo hosting, trasferisci l’intera installazione via SFTP o SSH, esporta il database dal vecchio server e importalo nel nuovo. SFTP è preferibile al vecchio FTP quando disponibile, perché protegge le credenziali durante il trasferimento.

Dopo l’import, aggiorna le credenziali nel file wp-config.php:

define( 'DB_NAME', 'nome_database' );
define( 'DB_USER', 'utente_database' );
define( 'DB_PASSWORD', 'password_database' );
define( 'DB_HOST', 'localhost' );

Il valore di DB_HOST non è sempre localhost: usa quello indicato dal nuovo provider.

Quando intervenire sugli URL

Se dominio, HTTPS e percorso restano invariati, non è normalmente necessario eseguire un search-replace globale. L’operazione serve se esistono riferimenti reali a un ambiente di staging o se cambiano dominio, protocollo o sottodirectory.

Evita sostituzioni SQL indiscriminate: WordPress e molti plugin memorizzano dati PHP serializzati. Il comando wp search-replace di WP-CLI gestisce i dati serializzati. Prima esegui una simulazione:

wp search-replace 'https://staging.esempio.it' 'https://www.esempio.it' \
  --skip-columns=guid \
  --dry-run

Valuta le tabelle coinvolte e conserva il backup. Rimuovi --dry-run soltanto dopo aver verificato l’anteprima.

3. Testare il nuovo server prima del DNS

Il test deve usare il dominio reale senza esporre subito il nuovo server a tutti gli utenti. Puoi associare temporaneamente il dominio al nuovo IP nel file hosts del tuo computer e rimuovere la modifica al termine. In alternativa, per un controllo tecnico, usa curl --resolve:

curl -I --resolve www.esempio.it:443:203.0.113.10 \
  https://www.esempio.it/

203.0.113.10 è un IP di esempio da sostituire con quello del nuovo server. Il comando mantiene hostname e richiesta HTTPS corretti, ma indirizza la connessione verso l’IP indicato. Non verifica automaticamente servizi esterni come gateway, webhook o CDN.

Controlla pagine e permalink, login/logout, recupero password, immagini, documenti e upload. Prova form ed email, redirect HTTP/HTTPS e www/non-www, sitemap, robots.txt, canonical, analytics, cache, cron, API e integrazioni. Per WooCommerce aggiungi carrello, checkout, gateway, email ordine, webhook, stock e area cliente.

Verifica anche che la copia non conservi password di protezione, noindex o impostazioni tipiche dello staging.

SSL prima della pubblicazione

Verifica come il nuovo hosting emette il certificato TLS. La challenge HTTP-01 richiede che l’autorità possa raggiungere il server via HTTP sulla porta 80 e può essere problematica prima che il DNS punti al nuovo server. La DNS-01 usa invece un record TXT _acme-challenge, supporta anche i wildcard e può essere adatta a scenari pre-switch in cui è possibile gestire il DNS. Le differenze sono spiegate nella documentazione di Let’s Encrypt sulle challenge.

4. Cutover: sequenza corretta per siti statici e dinamici

Blog e siti vetrina

1. Conferma il test sul nuovo server e la disponibilità di HTTPS.
2. Se previsto, riduci il TTL dei record web con anticipo. Il TTL più basso influenza le cache future, non quelle già esistenti.
3. Modifica i record A, AAAA o CNAME necessari per il sito, senza alterare i record di posta.
4. Controlla il sito dal nuovo ambiente e mantieni il vecchio hosting attivo durante la propagazione.

La documentazione Cloudflare sul TTL DNS chiarisce che la modifica non rende la propagazione istantanea.

WooCommerce, membership, form e login

Una prima copia eseguita ore o giorni prima non contiene automaticamente gli ordini, le registrazioni, i commenti o gli invii form successivi. Per limitare la divergenza dei dati, scegli una fascia a basso traffico e segui questo ordine operativo:

1. Completa la prima copia, testala e correggi eventuali problemi senza modificare ancora il DNS.
2. Nel momento del cutover, attiva una manutenzione breve sul vecchio sito o sospendi le funzioni che scrivono dati, compresi gli acquisti se possibile.
3. Se gateway e integrazioni lo richiedono, verifica come gestire webhook e notifiche durante la finestra di manutenzione. Non disabilitarli senza una procedura compatibile con il servizio utilizzato.
4. Crea un dump finale del database del vecchio server. Se sono stati caricati file dopo la prima copia, trasferisci anche gli upload rilevanti.
5. Importa il dump finale sul nuovo server, sovrascrivendo i dati della prima copia. Non importarlo prima di avere bloccato le nuove scritture sul vecchio ambiente.
6. Svuota cache applicativa, object cache e cache CDN quando applicabile; poi ripeti i controlli critici sul nuovo server tramite hosts o curl --resolve.
7. Modifica i record DNS web e riapri il sito solo dopo aver verificato checkout, email e integrazioni essenziali.

Per un e-commerce ad alto volume o con integrazioni complesse, questa attività può richiedere una procedura specifica del gateway o del provider. WooCommerce gestisce ordini, clienti e prodotti nel database: strumenti di importazione ed esportazione non equivalgono a una sincronizzazione in tempo reale. Consulta la documentazione WooCommerce sulla gestione di import ed export degli ordini prima di usare procedure aggiuntive.

5. Verifiche post-migrazione e rollback

Nelle prime ore verifica URL rappresentativi con risposta 200, login, form, email transazionali, media, HTTPS, redirect, sitemap, robots, canonical, tracking, cron, backup, CDN/WAF e DNS della posta. Invia e ricevi almeno un messaggio di test se la posta usa il dominio interessato.

Rimuovi installer e archivi lasciati dal plugin di migrazione, controlla chiavi API e credenziali temporanee e disattiva il debug dopo la diagnosi. Se usi WP-CLI, wp core verify-checksums confronta i file del core con i checksum di WordPress.org; non sostituisce il controllo di plugin premium o codice personalizzato.

 
Un rollback DNS non è immediato: alcuni resolver possono già avere in cache l’indirizzo del nuovo server. Inoltre, dopo la riapertura del nuovo ambiente, tornare semplicemente al vecchio database può creare una nuova divergenza di ordini, utenti, form e altri dati.

Se è necessario rientrare sul vecchio hosting, blocca prima le nuove scritture sul nuovo ambiente. Stabilisci quale database contiene i dati più recenti, riconcilia le informazioni prodotte dopo il cutover e solo dopo valuta il cambio dei record DNS. Mantieni entrambi gli ambienti e i backup finché il sito, la posta e le integrazioni non sono stati verificati con continuità.