Migrare WordPress senza downtime? La checklist che evita promesse impossibili

1. “Senza downtime” è un obiettivo operativo, non una garanzia

Cache DNS, propagazione, scritture sul database, servizi esterni e configurazioni diverse possono produrre comportamenti non prevedibili per tutti gli utenti. Una buona procedura mira a ridurre il fermo osservabile e la perdita di dati, ma non trasforma l’assenza di incidenti in una promessa assoluta.

Definisci prima cosa significa successo: pagine pubbliche raggiungibili, accesso amministrativo, ordini o moduli funzionanti, email consegnate e nessuna scrittura persa. Stabilisci anche il punto in cui interrompere e tornare al vecchio ambiente.

2. Fai l’inventario di accessi, dipendenze e contenuti che cambiano

Raccogli accessi a hosting, WordPress, database, SFTP o SSH, DNS, registrar, email, CDN, analytics e servizi di pagamento. Elenca versione PHP e database, plugin, tema, cron, redirect, certificati, regole server, directory esterne e integrazioni che usano IP o callback.

Individua le scritture durante il passaggio: ordini, commenti, form, prenotazioni, account e modifiche editoriali. Se il sito cambia mentre copi il database, devi prevedere una breve finestra di blocco o una sincronizzazione finale verificata.

• Proprietario e contatto per ogni account.
• Scadenza di dominio, hosting e certificati.
• Dipendenze da IP, percorsi, cron e servizi esterni.
• Dati che possono cambiare durante la migrazione.

3. Crea e prova un backup completo prima di toccare la produzione

La documentazione WordPress distingue file e database: servono entrambi per ricostruire il sito e raccomanda 3–5 backup recenti in posizioni differenti. Includi configurazioni e file caricati, verifica che gli archivi siano leggibili e conserva almeno una copia fuori dall’account che stai migrando.

Un backup non è verificato finché non sai come ripristinarlo. Annota comandi o procedura, credenziali, tempi e responsabile. Prima del passaggio effettua un test su un ambiente isolato e conferma che il contenuto atteso sia presente.

4. Porta la copia in staging e testa senza cambiare ancora il DNS

Configura il nuovo ambiente secondo i requisiti WordPress e importa file e database. Preferisci una risoluzione locale controllata che mantenga l’hostname finale senza dirigere il pubblico sul nuovo server. Se devi cambiare URL, usa strumenti compatibili con i dati serializzati e non sostituire i GUID: una sostituzione indiscriminata nel database può corrompere dati o riferimenti.

Testa pagine, login, media, permalink, ricerca, moduli, email, checkout, webhook, cron, cache, HTTPS e log. Confronta conteggi utili come utenti, ordini o articoli. Correggi gli errori prima del cambio DNS, non durante la finestra critica.

5. Prepara sincronizzazione finale, DNS e finestra di passaggio

Riduci il TTL con anticipo soltanto se sai perché serve e se il provider DNS lo consente; il cambiamento non rende istantanea ogni cache già esistente. Comunica la finestra agli utenti interni e limita le modifiche al sito durante la copia finale.

Esegui la sincronizzazione finale delle parti cambiate, verifica ancora i conteggi e poi aggiorna i record necessari. Durante la coesistenza evita scritture divergenti: mantieni il vecchio sito in modalità di sola lettura, inoltra le scritture al nuovo origin con un proxy controllato oppure registra e riconcilia ogni modifica incrementale finché le cache DNS possono ancora usare il vecchio indirizzo. Non trasferire contemporaneamente dominio, DNS, email e hosting se non è indispensabile: separare le variabili rende più chiara la diagnosi.

6. Monitora entrambi gli ambienti e conserva un rollback praticabile

Dopo il passaggio controlla risposte HTTP, certificato, errori applicativi, moduli, ordini, webhook, cron ed email da più reti o resolver. Mantieni il vecchio ambiente disponibile ma non lasciarlo accettare scritture non riconciliate; non cancellare dati finché il TTL applicabile è trascorso e i controlli sono conclusi.

Il rollback deve specificare quale record ripristinare, come recuperare eventuali nuove scritture e chi prende la decisione. Tornare al vecchio DNS senza riconciliare ordini o form arrivati nel frattempo può creare la perdita che stavi cercando di evitare.

7. Chiudi la migrazione soltanto dopo sito, dominio ed email

Verifica contatti e rinnovo del dominio, record DNS autorevoli, SPF, DKIM e DMARC se usati, caselle e inoltri. Controlla che backup, monitoraggio e procedure operative siano ora configurati sul nuovo servizio e che gli accessi temporanei siano rimossi.

Aggiorna la documentazione e calcola il costo futuro con rinnovi ed extra. Conserva per il periodo necessario export, log e vecchia configurazione; dismetti il servizio precedente soltanto quando il proprietario dei dati ha approvato i controlli finali.