Come migrare un sito web con WP-CLI

Se stai gestendo un sito WordPress di grandi dimensioni e devi spostarlo su un nuovo hosting, WP-CLI ti offre un percorso più veloce e scriptabile.

Non ti darà timeout PHP su database di grandi dimensioni. Inoltre, avrai un processo che puoi ripetere o automatizzare su più siti.

In questo tutorial, ti mostrerò come migrare un sito WordPress utilizzando WP-CLI. Alla fine, il tuo sito sarà in esecuzione sul nuovo server e avrai confermato che funziona prima che un singolo visitatore raggiunga il nuovo hosting.

Ecco i punti chiave:

• La migrazione con WP-CLI è più veloce della migrazione basata su plugin per siti di grandi dimensioni, ma richiede l'accesso SSH su entrambi i server e WP-CLI installato su ciascuno.
• Il flag --precise su wp search-replace è il comando più importante in questo tutorial. Senza di esso, i dati serializzati si corrompono silenziosamente e le impostazioni del tema, i widget e le opzioni dei plugin si resettano senza alcun messaggio di errore.
• Copiare wp-config.php dal vecchio server al nuovo porta con sé le credenziali del database errate. Devi aggiornare DB_NAME, DB_USER, DB_PASSWORD e DB_HOST sul nuovo server prima dell'importazione.
• Non cambiare mai il DNS prima di verificare che la migrazione sia andata a buon fine. Il passaggio 7 copre una checklist pre-DNS utilizzando wp option get, wp core verify-checksums e un'anteprima del file hosts.
• wp duplicator build crea un backup completo del sito dal terminale prima di iniziare. Se qualcosa si rompe a metà migrazione, l'URL di ripristino di emergenza di Duplicator ripristina il sito originale senza SSH sul vecchio server.
• Se stai migrando verso un nuovo dominio, includi --skip-columns=guid nel tuo comando search-replace. La sostituzione dei GUID interrompe gli abbonamenti RSS.

Indice

Quando usare WP-CLI per migrare un sito WordPress

WP-CLI non è lo strumento giusto per ogni migrazione. Ecco quando ha senso scegliere la riga di comando (e quando un altro approccio è più adatto).

Usa WP-CLI quando:

• Il tuo sito è abbastanza grande da far sì che gli strumenti basati su browser raggiungano timeout PHP o limiti di memoria durante il trasferimento
• Il tuo hosting non ti fornisce spazio su disco temporaneo sufficiente per creare un backup completo tramite browser
• Stai migrando più siti e desideri un processo ripetibile e scriptabile. wp duplicator build all'interno di uno script bash gestisce i backup batch senza alcun lavoro manuale
• Vuoi il controllo completo su ogni passaggio: cosa viene trasferito, cosa viene sostituito e cosa viene verificato prima delle modifiche al DNS

Considera un plugin di migrazione invece quando:

• Non hai accesso SSH sul server di origine o di destinazione
• Non ti senti a tuo agio con la riga di comando
• Desideri un processo guidato e visivo con indicatori di avanzamento e rollback integrati

Quale usare dipende dalla tua configurazione e preferenza.

Cosa Ti Serve Prima di Iniziare

Prepara tutto questo prima di eseguire un singolo comando. Perdere qualcosa a metà migrazione (specialmente credenziali del database o percorsi dei file) è il modo in cui finisci con un database importato a metà e un sito non funzionante su entrambi i server.

• Accesso SSH a entrambi i server. Dovrai eseguire comandi sul vecchio server e sul nuovo server in diversi momenti di questo processo.
• WP-CLI installato su entrambi i server. Se non è ancora installato, segui la guida ufficiale all'installazione. Ti servirà sul nuovo server per i passaggi di verifica nel Passaggio 7, non solo sul vecchio server.
• Duplicator Pro installato e attivo sul vecchio server. Questo plugin di backup/migrazione ha i comandi wp duplicator build, wp duplicator info e wp duplicator cleanup.
• Un nuovo database già creato sul nuovo server con un utente che ha privilegi completi. wp db import non crea il database per te: se non esiste, l'importazione fallisce.
• Credenziali del database del tuo nuovo server pronte: DB_NAME, DB_USER, DB_PASSWORD e DB_HOST. Ti serviranno nel Passaggio 4.
• I percorsi assoluti dei file per entrambe le installazioni di WordPress. Esegui pwd all'interno di ogni directory principale di WordPress e copia l'output in un posto comodo.
• Se stai cambiando dominio: il tuo vecchio URL e il nuovo URL pronti da copiare/incollare esattamente come appaiono nel database, incluso il protocollo (https:// vs http://).

Come migrare un sito WordPress con WP-CLI

Ecco cosa farai. Ogni passaggio si basa direttamente sull'ultimo, quindi procedi in ordine.

• Passaggio 1: Esegui un controllo preliminare e crea un backup completo con wp duplicator info e wp duplicator build
• Passaggio 2: Esporta il database dal vecchio server usando wp db export
• Passaggio 3: Trasferisci i file di WordPress e il database sul nuovo server usando rsync e scp
• Passaggio 4: Aggiorna wp-config.php sul nuovo server con le tue nuove credenziali del database
• Passaggio 5: Reimposta e importa il database sul nuovo server usando wp db reset e wp db import
• Passaggio 6: Esegui search-replace per aggiornare gli URL usando wp search-replace (solo per modifiche al dominio)
• Passaggio 7: Svuota la cache e verifica la migrazione prima di toccare il DNS
• Passaggio 8: Aggiorna il DNS e vai online
• Passaggio 9: Pulisci il vecchio server con wp duplicator cleanup

Passaggio 1: Esegui il backup del sito originale

Prima di esportare qualsiasi cosa, hai bisogno di un punto di ripristino pulito sul server originale. Se qualcosa va storto a metà migrazione, vuoi essere in grado di tornare a un sito funzionante senza affanno.

Utilizzo Duplicator per la protezione dei backup di WordPress. È un plugin di backup e migrazione utilizzato da oltre 1,5 milioni di professionisti di WordPress e dispone di comandi WP-CLI integrati.

Ciò significa che puoi creare un backup completo del sito senza lasciare il terminale. Per un flusso di lavoro da riga di comando, questo è importante.

Inizia verificando che la configurazione di backup di Duplicator funzioni correttamente. Accedi via SSH al vecchio server, naviga nella directory principale di WordPress ed esegui:

wp duplicator info

Una volta che questo comando restituisce un risultato pulito, crea il tuo backup:

wp duplicator build

Questo crea un backup completo del tuo sito dal terminale.

Se desideri salvare il backup in una posizione specifica anziché quella predefinita, utilizza:

wp duplicator build --dir=/path/to/backup/location

Esegui wp duplicator build --help per vedere tutti i flag disponibili, inclusi --template=<ID> per i modelli di backup predefiniti e opzioni del motore di archiviazione come --phpsqldump, --phpzip e --duparchive.

Se questa migrazione dovesse causare problemi, l'URL di ripristino di emergenza di Duplicator può ripristinare il tuo sito anche se WordPress è completamente bloccato sul vecchio server. Questa è la tua rete di sicurezza prima di toccare qualsiasi altra cosa.

Passaggio 2: Esporta il database dal vecchio server

Ancora sul vecchio server, naviga nella directory principale di WordPress ed esporta il database:

wp db export site-backup.sql

Al termine, vedrai: Success: Exported to 'site-backup.sql'.

Il file viene salvato nella directory corrente. Prendi nota di dove si trova, poiché lo trasferirai nel passaggio successivo.

Una cosa da fare prima di procedere. Se il tuo file .sql finisce all'interno di una directory accessibile dal web come /public_html o /htdocs, spostalo o eliminalo immediatamente dopo il trasferimento.

Un file .sql esposto è una copia completa del tuo database, inclusi nomi utente, password con hash e ogni singolo pezzo di contenuto del sito. Non è un rischio teorico.

Se stai migrando una rete WordPress Multisite, aggiungi --all-tables per acquisire i dati dell'intera rete:

wp db export site-backup.sql --all-tables

Passaggio 3: Trasferisci i file di WordPress e il database sul nuovo server

Due cose devono essere spostate sul nuovo server: i file di WordPress e l'esportazione .sql che hai appena creato.

Per i file, usa rsync. Gestisce bene i trasferimenti di grandi dimensioni, mostra i progressi e riprende da dove si era interrotto se la connessione cade:

rsync -avz --progress /path/to/old-wordpress/ user@newserver:/path/to/new-wordpress/

Con la barra, rsync copia il contenuto della directory. Senza di essa, rsync copia la directory stessa, il che posiziona i tuoi file un livello più in basso del previsto sul nuovo server.

Esegui prima una prova a secco per verificare cosa verrà trasferito prima di confermare:

rsync -avz --progress --dry-run /path/to/old-wordpress/ user@newserver:/path/to/new-wordpress/

Per il file di database, usa scp:

scp site-backup.sql user@newserver:/path/to/new-wordpress/

Se preferisci comprimere tutto in un unico archivio prima, funziona anche quello:

tar -czf site_files.tar.gz .
scp site_backup.sql site_files.tar.gz user@newserver:/path/to/new-wordpress/

Quindi estrai sul nuovo server:

tar -xzf site_files.tar.gz

Questo approccio funziona bene per siti più piccoli o host che gestiscono trasferimenti di file singoli in modo più affidabile rispetto alle connessioni rsync.

Passaggio 4: Aggiorna wp-config.php sul nuovo server

Questo è il passaggio che la maggior parte dei tutorial di migrazione WP-CLI salta, ed è il motivo più comune per cui una migrazione fallisce immediatamente dopo l'importazione.

Quando hai trasferito i tuoi file di WordPress nel passaggio precedente, wp-config.php è arrivato con loro. Questo è il file giusto, ma contiene ancora le credenziali del database del tuo vecchio server. Se esegui l'importazione ora, WP-CLI tenterà di connettersi a un database che non esiste sul nuovo server.

Accedi via SSH al nuovo server, naviga nella root di WordPress e apri wp-config.php:

nano /path/to/new-wordpress/wp-config.php

Aggiorna questi quattro valori con i dettagli del database del tuo nuovo server:

• DB_NAME: il nome del database che hai creato sul nuovo server
• DB_USER: il nome utente del database
• DB_PASSWORD: la password del database
• DB_HOST: solitamente localhost, ma conferma con il tuo host. Alcuni host gestiti utilizzano un valore diverso qui.

Salva ed esci. Su nano, premi Ctrl+O per salvare e Ctrl+X per uscire.

Non dimenticare questo passaggio. Se le credenziali sono errate, wp db import si connetterà al database sbagliato o fallirà con “Errore nell’instaurare una connessione al database”, e non sarà sempre ovvio che wp-config.php sia la causa.

Passaggio 5: Reimposta e importa il database sul nuovo server

Accedi via SSH al nuovo server e naviga nella root di WordPress. Se hai una nuova installazione di WordPress sul nuovo server, elimina le sue tabelle predefinite prima di importare. Saltare questo passaggio può causare conflitti tra le tabelle esistenti e quelle nel tuo export.

wp db reset --yes

Vedrai: Successo: Database resettato.

Il flag --yes salta la richiesta di conferma. Senza di esso, WP-CLI ti chiederà conferma prima di eliminare tutte le tabelle.

Ora importa il database:

wp db import site-backup.sql

Appena l'importazione è confermata, elimina il file SQL:

rm site-backup.sql

Quindi accedi nuovamente via SSH al vecchio server ed eliminalo anche lì.

Questa non è una pulizia opzionale. Un file .sql che si trova in una directory accessibile via web è una copia completa del tuo database. Eliminalo da entrambi i server prima di fare qualsiasi altra cosa.

Passaggio 6: Esegui Search-Replace per aggiornare gli URL

Se stai mantenendo lo stesso dominio e stai solo cambiando host, salta questo passaggio e vai direttamente al Passaggio 7. I tuoi URL sono già corretti nel database.

Se stai cambiando dominio, è qui che la maggior parte delle migrazioni si rompe silenziosamente. Non con un errore, ma con impostazioni del tema che sembrano sbagliate, widget scomparsi e opzioni dei plugin ripristinate ai valori predefiniti. La causa è quasi sempre la stessa: una ricerca-sostituzione che non ha gestito correttamente i dati serializzati.

Prima di eseguire qualsiasi operazione, fai una prova a secco:

wp search-replace 'https://olddomain.com' 'https://newdomain.com' --all-tables --precise --dry-run

Questo esegue l'operazione completa e ti mostra una tabella di quante sostituzioni verrebbero effettuate per tabella del database, senza salvare alcuna modifica. Rivedila.

Cerca le tabelle in cui ti aspetti sostituzioni (wp_options, wp_posts, wp_postmeta) e assicurati che i conteggi sembrino ragionevoli. Zeri inaspettati su quelle tabelle meritano un'indagine prima di procedere.

Quando sei soddisfatto, eseguilo senza –dry-run:

wp search-replace 'https://olddomain.com' 'https://newdomain.com' --all-tables --precise

Perché --precise è importante: WordPress memorizza alcuni dati come PHP serializzato. Le impostazioni del personalizzatore del tema, le configurazioni dei widget, le opzioni dei plugin: questi non sono memorizzati come testo semplice. Sono memorizzati come stringhe PHP strutturate che includono conteggi di caratteri.

Una normale ricerca-sostituzione basata su SQL scambia la stringa dell'URL ma non ricalcola quei conteggi di caratteri. PHP legge il conteggio, trova una discrepanza e scarta silenziosamente i dati.

Il tuo tema si resetta. I tuoi widget scompaiono. Non viene generato alcun errore: il sito semplicemente appare sbagliato.

Il flag --precise forza WP-CLI a usare PHP invece di SQL. Dis-serializza ogni valore, effettua la sostituzione, ricalcola il conteggio dei caratteri e ri-serializza il risultato correttamente. È più lento su database di grandi dimensioni. Usalo comunque.

Una cosa che wp search-replace salta correttamente per impostazione predefinita: la colonna guid in wp_posts. Non cercare di forzarla a sostituire i GUID.

La documentazione di WordPress afferma esplicitamente che i GUID devono rimanere costanti. Identificano i post per i lettori di feed e cambiarli interrompe le sottoscrizioni RSS.

Se stai migrando una rete Multisite, aggiungi il flag –network:

wp search-replace 'https://olddomain.com' 'https://newdomain.com' --all-tables --precise --network

La documentazione ufficiale di WordPress descrive un ordine diverso: aggiorna i tuoi URL in Impostazioni » Generali sul vecchio server prima di migrare, quindi esporta il database già aggiornato e salta completamente il passaggio di ricerca e sostituzione sul nuovo server. Funziona. L'approccio in questo tutorial (migra prima, cerca e sostituisci dopo) è più facile da verificare perché puoi eseguire una simulazione prima di apportare modifiche permanenti agli URL.

Passaggio 7: Svuota la cache e verifica prima di toccare il DNS

Una volta completata la ricerca e la sostituzione, è allettante passare direttamente al DNS. Non farlo.

Cambiare il DNS prima di aver confermato che il sito funziona significa che eventuali problemi che trovi saranno problemi live, visibili ai visitatori reali. Prenditi dieci minuti qui e verifica prima tutto sul nuovo server.

Inizia svuotando la cache degli oggetti:

wp cache flush

Quindi svuota le regole di riscrittura:

wp rewrite flush

Ora verifica che gli URL nel database siano corretti. Esegui entrambi questi comandi:

wp option get siteurl
wp option get home

Entrambi dovrebbero restituire il tuo dominio corretto. Se uno dei due restituisce il vecchio dominio, puoi aggiornarli manualmente:

wp option update siteurl 'https://newdomain.com'

wp option update home 'https://newdomain.com'

Successivamente, verifica che i tuoi file core di WordPress siano stati trasferiti senza corruzione:

wp core verify-checksums

Se restituisce errori, annota quali file sono segnalati. Una manciata di file modificati in wp-content è prevista e non è un problema: quelli sono i tuoi file di temi e plugin, che non fanno parte del confronto dei checksum. Gli errori sui file core in wp-admin o wp-includes meritano un'indagine.

Visualizza in anteprima il sito prima di aggiornare il DNS. Aggiungi una riga temporanea al file hosts della tua macchina locale che punti il tuo dominio all'indirizzo IP del nuovo server. Su Mac o Linux, apri /etc/hosts in un editor di testo e aggiungi:

123.456.789.0 yourdomain.com

Sostituisci 123.456.789.0 con l'IP del tuo nuovo server. Salva il file, quindi apri il tuo dominio in un browser. Ora stai visualizzando il nuovo server mentre tutti gli altri accedono ancora a quello vecchio.

Controlla ognuno di questi prima di procedere:

• La homepage si carica correttamente
• Il login dell'amministratore funziona su /wp-admin
• Le immagini vengono visualizzate su post e pagine
• I menu di navigazione sono intatti
• I widget appaiono correttamente nella barra laterale o nel piè di pagina
• L'aspetto del tema corrisponde all'originale

Quando tutto è a posto, rimuovi la riga che hai aggiunto al tuo file hosts. Quindi, sei pronto per un aggiornamento del DNS.

Passaggio 8: Aggiorna il DNS e vai online

Punta il record A del tuo dominio all'indirizzo IP del tuo nuovo server. Dove fai questo dipende da dove sono puntati i nameserver del tuo dominio: o il tuo registrar di dominio o il gestore DNS del tuo provider di hosting.

Accedi, trova il record A per il tuo dominio e aggiorna l'IP.

La propagazione del DNS richiede da pochi minuti a 48 ore, a seconda del tuo registrar e dell'impostazione TTL (time to live) del tuo dominio. Durante questo intervallo, alcuni visitatori raggiungeranno il vecchio server e altri il nuovo. È normale. Non è un segno che qualcosa si sia rotto.

Mantieni il vecchio server in funzione per almeno 24-48 ore dopo l'aggiornamento del DNS. Spegnerlo durante la propagazione significa che alcuni visitatori non raggiungeranno nulla.

Una volta che sei sicuro che la propagazione sia completa, esegui un ultimo svuotamento della cache sul nuovo server:

wp cache flush

Passaggio 9: Pulisci con wp duplicator cleanup

Una volta confermato che il nuovo server è attivo e stabile, torna al vecchio server ed esegui:

wp duplicator cleanup

Questo rimuove i file di backup e qualsiasi dato temporaneo creato da Duplicator durante il processo di creazione nel Passaggio 1. Mantiene il vecchio server ordinato e cancella eventuali artefatti di migrazione prima di dismetterlo.

Esegui questo comando solo dopo essere certo che la migrazione sia completa. Una volta che i file di backup sono spariti, l'opzione di disaster recovery del Passaggio 1 se ne va con loro.

Se desideri conservare il backup come archivio a lungo termine, spostalo su uno storage remoto prima di eseguire la pulizia.

Risoluzione dei problemi comuni degli errori di migrazione di WP-CLI

Anche una migrazione attenta può incontrare intoppi. Ecco i punti di fallimento più comuni, come si presentano e come risolverli.

“Errore di connessione al database” dopo l'importazione

Cosa vedi: WordPress mostra una schermata bianca o il messaggio “Errore di connessione al database” sul nuovo server immediatamente dopo l'importazione.

Perché succede: wp-config.php contiene ancora le credenziali del database del vecchio server. Questo è l'errore più comune in una migrazione WP-CLI ed è facile da trascurare se hai trasferito i file prima di aggiornare la configurazione.

Come risolverlo: Apri wp-config.php sul nuovo server e aggiorna DB_NAME, DB_USER, DB_PASSWORD e DB_HOST per farli corrispondere al database del tuo nuovo server. Salva il file e ricarica il sito.

Impostazioni del tema, widget o opzioni dei plugin resettate dopo la migrazione

Cosa vedi: Il sito si carica, ma il tema sembra sbagliato, i widget sono mancanti o le impostazioni dei plugin sono tornate ai valori predefiniti. Nessun messaggio di errore.

Perché succede: Hai eseguito wp search-replace senza il flag --precise. La sostituzione dell'URL ha corrotto i dati serializzati nel database e WordPress ha scartato silenziosamente i valori corrotti.

Come risolverlo: Riesegui search-replace con --precise e --all-tables:

wp search-replace 'https://olddomain.com' 'https://newdomain.com' --all-tables --precise

Se i dati sono già gravemente corrotti e rieseguire search-replace non ripristina le impostazioni, ripristina il backup di Duplicator creato nel Passaggio 1 ed esegui nuovamente la migrazione.

“wp: command not found” sul nuovo server

Cosa vedi: Qualsiasi comando WP-CLI sul nuovo server restituisce wp: command not found o command not found: wp.

Perché succede: WP-CLI non è installato sul nuovo server, o è installato ma non è nel tuo PATH.

Come risolvere: Installa WP-CLI sul nuovo server. Se non hai i permessi per rendere eseguibile il file sul tuo host, puoi eseguire i comandi usando php wp-cli.phar invece di wp.

rsync esce con "Permesso negato"

Cosa vedi: rsync viene eseguito ma termina presto con uno o più errori "Permesso negato" su file o directory specifici.

Perché succede: O la tua chiave SSH non è configurata correttamente per il server di destinazione, o c'è una discrepanza nella proprietà dei file tra i due server.

Come risolvere: Verifica prima l'accesso tramite chiave SSH con ssh user@newserver. Se fallisce, risolvi l'autenticazione della chiave prima di riprovare rsync. Se la connessione funziona ma a specifici file viene negato l'accesso, potresti dover usare chown sui file trasferiti sul nuovo server per farli corrispondere all'utente web utilizzato dal tuo host - comunemente www-data su Ubuntu o il nome utente dell'account sugli host cPanel.

Il sito si carica ma le immagini sono corrotte

Cosa vedi: Le pagine si caricano correttamente, ma le immagini mostrano icone di immagini corrotte in tutto il sito.

Perché succede: O la cartella wp-content/uploads non è stata trasferita completamente, o gli URL delle immagini hardcoded nel contenuto dei post non sono stati rilevati da search-replace.

Come risolvere: Esegui nuovamente rsync puntando solo alla cartella uploads per catturare eventuali file che non sono stati trasferiti:

rsync -avz --progress /path/to/old-wordpress/wp-content/uploads/ user@newserver:/path/to/new-wordpress/wp-content/uploads/

Quindi riesegui search-replace con --dry-run per verificare se gli URL delle immagini fanno ancora riferimento al vecchio dominio.

Nulla funziona: Ripristina e ricomincia

Se il sito è completamente rotto e non riesci a identificare una causa chiara, non passare ore a fare il debug di uno stato di migrazione parziale. Ripristina il backup di Duplicator Pro che hai creato nel Passo 1.

L'URL di ripristino di emergenza di Duplicator può riportare il vecchio sito anche se WordPress è bloccato.

Una volta tornato a uno stato pulito e funzionante, ripercorri lentamente i passaggi. Usa –dry-run su rsync e wp search-replace prima di confermare qualsiasi cosa, e ricontrolla le credenziali di wp-config.php prima di eseguire l'importazione.

Domande frequenti (FAQ)

Il tuo sito è sul nuovo server. Ecco cosa controllare dopo.

Hai esportato il database, trasferito i file, aggiornato wp-config.php, importato, eseguito una ricerca-sostituzione, verificato tutto sul nuovo server e modificato il DNS. Questa è la migrazione completa.

Le prime 48 ore meritano attenzione. La propagazione DNS significa che alcuni visitatori colpiranno ancora il vecchio server durante questa finestra, quindi non dismetterlo ancora.

Controlla eventuali livelli di cache che potrebbero servire contenuti obsoleti. Un flush completo della cache sul nuovo server una volta confermata la propagazione richiede dieci secondi e risolve molti problemi di visualizzazione.

Se qualcosa sembra ancora fuori posto dopo che la propagazione è completa, usa wp search-replace --dry-run come strumento diagnostico prima di toccare qualsiasi cosa:

wp search-replace 'https://olddomain.com' 'https://newdomain.com' --all-tables --precise --dry-run

Questo ti mostra quali tabelle contengono ancora il vecchio dominio senza apportare alcuna modifica. È il modo più veloce per confermare se un URL persistente è un errore di ricerca-sostituzione o qualcosa codificato in un file del tema.

Gli URL codificati nei file del tema personalizzato non verranno rilevati dalla ricerca-sostituzione. Dovrai trovarli e aggiornarli manualmente nel codice del tema.

Migra con fiducia usando Duplicator Pro

Una migrazione senza backup è un azzardo. I server si comportano in modo imprevisto, le importazioni vengono interrotte e i dati serializzati non sempre sopravvivono a una ricerca-sostituzione in modo pulito.

Avere un punto di ripristino prima di iniziare significa che qualsiasi di queste situazioni è un piccolo intoppo invece di un grave problema.

Duplicator Pro rende il backup un singolo comando dal terminale: wp duplicator build. E se qualcosa va storto, l'URL di ripristino di emergenza ripristina il tuo sito originale anche se WordPress è completamente bloccato.

Oltre 1,5 milioni di professionisti WordPress utilizzano Duplicator Pro per eseguire il backup, migrare e clonare i propri siti. Unisciti a loro!

Se questo tutorial ti è stato utile, anche queste guide meritano di essere aggiunte ai preferiti.

• Come spostare un sito web WordPress su un nuovo host
• Perché non riesci ad accedere a WordPress dopo una migrazione
• Migrazione DNS fatta bene: Come evitare gli errori più comuni
• La checklist completa per il testing di WordPress post-migrazione
• Come controllare i contenuti prima di una migrazione del sito web
• Come migrare un sito WordPress GRATUITAMENTE