Migrare WordPress a un nuovo hosting significa spostare i file del sito, il database e la configurazione dal vecchio al nuovo server, senza perdere dati né tempi di attività. Se stai leggendo questa guida, quasi sicuramente hai un motivo concreto: il sito carica lento, il prezzo dell’hosting è salito, il supporto non risponde. Cambiare host è una mossa necessaria, e non serve essere sviluppatori: serve seguire la sequenza giusta, che è sempre la stessa.
Cosa stai spostando davvero
Prima della tecnica, la domanda che quasi nessuno si fa: perché stai migrando? Le due risposte più comuni sono diverse e portano a scelte diverse. La prima è economica: il rinnovo costa due o tre volte il primo anno, e a quel punto conviene guardarsi intorno (i numeri di questo effetto sono nella guida su quanto costa un sito web). La seconda è tecnica: il sito è cresciuto, il piano condiviso non basta più, e il sintomo è la lentezza (gli errori di hosting più comuni sono elencati qui).
Il movente conta perché cambia il piano: se il problema è il prezzo, cerchi lo stesso tipo di hosting a condizioni migliori; se è la lentezza, cambiare tipo di piano (condiviso → risorse isolate) è l’unico intervento che sposta i numeri. In entrambi i casi la migrazione la fai una volta, e farla bene è più importante di farla in fretta.
WordPress vive in due mondi separati: i file su disco (tema, plugin, uploads, file di sistema) e il database (articoli, pagine, utenti, impostazioni). Il punto di contatto è il file wp-config.php, che dice a WordPress dove trovare il database e come chiamarlo. Una migrazione fatta bene copia tutti e tre gli elementi; una fatta a metà copia solo i file e poi si chiede perché il sito dà errore di connessione al database.
Il percorso in sintesi: backup, nuovo hosting, copia file, importa database, aggiorna wp-config, punti il DNS, verifica, svuota la cache. Otto passi, nessuno dei quali richiede competenze da sysadmin. La mappa completa è qui sotto: tienila aperta mentre procedi.
Un esempio concreto per capire il quadro: il sito di un artigiano con 300 prodotti, un blog con articoli e una galleria di foto. La parte “pesante” sono le immagini in uploads (anche 2-3 GB), la parte “invisibile” è il database (le schede prodotto, gli ordini, gli utenti). Se la migrazione porta tutto, il sito nuovo è identico in poche ore. Se dimentica il database, il risultato è una pagina con l’errore “Error establishing a database connection”, un messaggio frequente di WordPress. La sequenza che segue evita esattamente questo.
Backup completo: file e database
Cosa serve davvero per il backup?
Il backup è un passaggio che influenza l’esito di tutta l’operazione. Due pezzi, entrambi obbligatori. File: tema, plugin, la cartella wp-content/uploads con le immagini e il resto. Database: articoli, pagine, commenti, impostazioni, utenti. Per il database, da phpMyAdmin si esporta tutto in un file .sql; se hai accesso a WP-CLI, wp db export fa lo stesso lavoro in un comando. Se sul pannello del vecchio hosting c’è una funzionalità di backup automatico, usala comunque, ma scarica le copie anche fuori dal server: un backup che resta sullo stesso disco del sito è un backup a metà.
Se il tuo sito fa già backup automatici regolari (e dovrebbe: qui trovi la guida completa ai backup di WordPress), puoi riusare l’ultima copia: controllo che sia recente, scaricala e vai avanti. Se invece arrivi da WordPress.com e vuoi passare a un hosting tuo, il percorso è leggermente diverso, e in questa guida dedicata trovi le differenze passo per passo.
Prepara il nuovo hosting
Sul nuovo hosting crei da zero l’ambiente: database (con utente e password dedicate), spazio web per i file e SSL. Molti pannelli moderni (cPanel, Plesk, i pannelli proprietari) offrono l’installazione di WordPress in un click: se la usi, fai attenzione a quello che installa, perché poi andrai a sovrascriverlo con i tuoi file. L’alternativa pulita è preparare solo il database e caricare i file a mano. Prima di procedere, verifica anche che il piano scelto rispetti almeno le basi: PHP aggiornato, risorse dedicate e cache lato server. I requisiti ufficiali di WordPress, aggiornati a ogni release, sono elencati nella documentazione ufficiale: una cosa da controllare prima di firmare, non dopo. Se stai ancora valutando dove andare, ti conviene partire dalla guida su come scegliere l’hosting WordPress e dal confronto dei migliori hosting italiani.
Copia i file e importa il database
Cosa cambio nel file wp-config?
Copi i file con FTP o con un file manager: tema, plugin, uploads e tutto il contenuto della root di WordPress. Poi importi il .sql del database nel database nuovo (phpMyAdmin: importa; WP-CLI: wp db import). Infine apri wp-config.php e aggiorni queste tre righe con i dati del nuovo database:
define( 'DB_NAME', 'nuovo_nome_database' );
define( 'DB_USER', 'nuovo_utente' );
define( 'DB_PASSWORD', 'nuova_password' );Se il dominio resta lo stesso, non devi toccare gli URL nel database: gli indirizzi nel wp_options restano validi. Cambi anche dominio? Allora serve una ricerca-e-sostituisci degli indirizzi (la fanno i plugin di migrazione o WP-CLI con wp search-replace), da fare con attenzione sulle tabelle giuste.
Un dettaglio che dimenticano quasi tutti: i permessi dei file. Dopo la copia, le directory devono avere lettura ed esecuzione per chi serve le pagine (tipicamente 755) e i file 644; molti archivi divisi copiano i file con permessi sbagliati e il sito risponde con errori che non c’entrano niente con la migrazione. Pannelli come cPanel hanno un pulsante per riparare i permessi in un click; da terminale si risolve con un comando ricorsivo. Controllalo come parte della verifica.
Il DNS: la parte che richiede pazienza
Quanto dura la propagazione DNS?
Il DNS collega il nome del dominio all’indirizzo del server. Quando lo cambi, l’aggiornamento si propaga per il mondo e può servire fino a due giorni: alcuni visitatori vedono il nuovo server, altri ancora il vecchio. Due accorgimenti per farlo in modo pulito. Prima, abbassa il TTL (il tempo di vita delle risposte DNS) a 300 secondi: le modifiche viaggiano più in fretta (la documentazione di Cloudflare sul TTL spiega bene il meccanismo). Durante, non toccare il vecchio hosting: lascialo in piedi finché il sito non risponde in modo stabile dal nuovo (il piano gratuito di Cloudflare, se lo usi, gestisce la parte CDN senza costi extra). Dopo, verifica da fuori, da un telefono o da una rete diversa, non dal computer con cui lavori. E se hai il controllo dei nameserver, controlla anche i record NS: alcuni hosting gestiti richiedono di puntare direttamente i loro nameserver, altri funzionano solo con i record che punti tu. Sapere dov’è il confine (registrar, DNS, hosting) evita il giro a vuoto del supporto tecnico.
Verifica dopo la migrazione
Cosa controllo subito dopo?
La verifica si fa in ordine. HTTPS: il sito deve rispondere con il lucchetto; se il certificato non è attivo, anche questa è una cosa da fare prima del DNS. Contenuti: apri qualche articolo, controlla che le immagini si vedano e che i link funzionino. Permalink: se le pagine danno 404, vai su Impostazioni e salvi di nuovo la struttura dei permalink; WordPress rigenera le regole da solo. Email: invia e ricevi una prova; se i record MX restano nello stesso DNS, di solito non cambia nulla. Velocità: un test con PageSpeed Insights dopo una settimana ti dice se il nuovo host mantiene le promesse. E per ultimo, svuota la cache del nuovo server: a migrazione finita, non deve restare traccia del vecchio sito. Un trucco da professionisti: prima di puntare il DNS, puoi testare il sito sul nuovo server con un sottodominio temporaneo (o l’host file locale), così la verifica vera la fai senza fretta e senza toccare il sito in produzione.
Se qualcosa non torna, niente panico: prima di tutto svuota la cache del server e del plugin cache, poi rigenera i permalink, e solo dopo inizia a cercare. La stragrande maggioranza dei “siti rotti dopo la migrazione” sono cache da svuotare. E se proprio non trovi la causa, sul forum di supporto italiano di WordPress trovi una comunità attiva che le migrazioni le vede ogni giorno.
Gli errori che rovinano la migrazione
Il `search-replace` e le stringhe serializzate
È l’errore che si scopre dopo: il sito si apre, ma i link interni puntano al vecchio dominio, oppure una pagina perde i widget e le impostazioni. Il motivo è che cambiare dominio non è un semplice «trova e sostituisci»: il database di WordPress contiene valori «serializzati», cioè stringhe che dichiarano la propria lunghezza. Se sostituisci il vecchio indirizzo con uno più corto o più lungo senza correggere quel numero, il valore diventa illeggibile e WordPress lo scarta.
Come si fa bene: si usa uno strumento che gestisce la serializzazione — WP-CLI con wp search-replace (la sezione qui sopra), o lo strumento incluso nei plugin di migrazione — e mai una sostituzione fatta a mano in phpMyAdmin. Due regole pratiche: fai la sostituzione dopo l’importazione del database e prima di aprire il sito al pubblico, e controlla sempre tre cose dopo: i link interni di un articolo, il logo e le immagini in home, e le impostazioni di un plugin qualsiasi (è lì che si vedono i valori serializzati rotti).
Le email: l’unico danno irreversibile
È il punto in cui una migrazione può fare un danno che non si ripara con un backup, ed è la domanda che nessuna delle tredici guide di hosting in prima pagina affronta. Mentre il sito cambia server, la posta elettronica collegata al dominio continua a puntare dove dicono i record MX: se li sposti prima che la nuova casella sia pronta, i messaggi in arrivo si perdono (e non tornano). La sequenza sicura è questa: prima si creano le caselle sul nuovo provider e si verificano, poi si testano invio e ricezione, e solo alla fine si cambiano i record MX. Se il dominio ha email che usi per lavoro, tenere le due configurazioni attive per qualche giorno è la scelta prudente: la posta non ha la tolleranza che ha un sito web.
Migrare senza fermare il sito: come si fa
«Zero downtime» è una promessa commerciale: la tecnica esiste, e vale la pena conoscerla. Il metodo è non cambiare il DNS finché il nuovo server non è pronto e verificato, e nel frattempo controllare il sito nuovo tramite una corrispondenza locale: si modifica il file hosts del proprio computer (o si usa il DNS locale del pannello) per far puntare il dominio al nuovo IP solo per te. Navighi il sito nuovo come se fosse online, clicchi, verifichi i form, e quando è tutto a posto sposti il DNS per tutti. Se preferisci non toccare nulla, la variante è una breve finestra di manutenzione — dieci minuti in una notte — che è più sicura di una migrazione fatta «a sito aperto» senza controllo.
Gli errori si ripetono con una costanza impressionante. Copiare solo i file e scoprire che il database non c’è. Dimenticare che wp-config.php contiene i dati del vecchio hosting e lasciarlo così com’è. Fare il cambio DNS con TTL alto, condannandosi a ore di attesa inutili. Testare di fretta, guardando il sito dal computer di lavoro, che magari ha già la copia in cache e mostra il vecchio server. Dimenticare le email, che se vivono sul vecchio hosting smettono di arrivare. E migrare in pieno traffico, nel giorno sbagliato, senza margine per correggere.
Molti di questi errori sono gli stessi che vediamo ogni giorno nei siti nuovi: se vuoi riconoscerli a colpo d’occhio, la nostra raccolta degli errori comuni con l’hosting WordPress li elenca tutti con il rimedio. La regola pratica resta una: mai migrare di venerdì pomeriggio, mai senza backup fresco, mai la settimana dei saldi se sei un negozio. La migrazione si fa quando si ha il tempo di verificare.
WP-CLI: la via per chi ama il terminale
wp search-replace da WP-CLI, che gestisce i valori serializzati, o con lo strumento incluso nel plugin di migrazione. Mai con una sostituzione fatta a mano in phpMyAdmin.Per chi ha accesso SSH (molti hosting gestiti lo danno), WP-CLI comprime l’intera procedura. Sul vecchio server: wp db export per il database e un archivio della cartella (per esempio con tar). Sul nuovo: ripristini database con wp db import, scompatti i file e aggiorni wp-config.php. Un esempio di sequenza, da adattare ai tuoi percorsi:
# sul vecchio server
wp db export sito.sql
tar czf sito-files.tar.gz wp-content
# sul nuovo server
wp db import sito.sql
tar xzf sito-files.tar.gzLa versione di PHP installata fa la differenza: la pagina ufficiale delle versioni supportate è il riferimento quando confronti vecchio e nuovo ambiente. Se non hai mai usato il terminale, non partire da qui: la via grafica descritta sopra funziona benissimo.
I plugin che migrano al posto tuo
Tre scenari diversi (e i nomi che si cercano)
La procedura di questa guida vale per il caso più comune — da un hosting all’altro, stesso dominio. Due varianti cambiano i passaggi, e sono quelle che la gente cerca per nome:
- Da WordPress locale a un hosting remoto: il caso di chi ha sviluppato in locale (Local, DevKinsta, Studio) e ora pubblica. Qui il database è già tuo e non c’è DNS da cambiare: serve esportare file e database, importarli, aggiornare l’URL nel database (dal dominio locale a quello vero) e sistemare i permessi dei file.
- Su un dominio diverso: oltre alla migrazione c’è il cambio di indirizzo. Oltre al
search-replace, serve decidere cosa fare del vecchio dominio: un redirect 301 verso il nuovo è la scelta che conserva il posizionamento, e va tenuto attivo a lungo — non qualche settimana. - Con un plugin: tra i più usati c’è Duplicator — 1 milione di installazioni, 98/100, aggiornato il 18 settembre 2026 — che esporta un pacchetto completo da importare sul nuovo server. Resta vero quello che dicevamo sopra: qualunque strumento usi, la verifica finale è sempre la stessa. E se il nuovo hosting è un provider italiano molto diffuso, come Aruba, la sua procedura di importazione è documentata nel pannello: quello che conta è che tu faccia il backup prima di usarla.
Se la via manuale ti sembra troppa, i plugin di migrazione esistono e funzionano: All-in-One WP Migration esporta il sito intero (file e database insieme) in un unico archivio da importare sul nuovo host; Duplicator fa lo stesso con pacchetti separati. Il limite è la dimensione: gli hosting impongono tetti all’upload e i siti con molte immagini superano presto i limiti del piano gratuito. La logica resta identica alla via manuale: backup, copia, configurazione, test. L’unica differenza è che il plugin fa i passi 3 e 4 al posto tuo.
Quanto dura e quanto costa
I tempi reali, per farti un’idea concreta prima di partire.
| Fase | Tempo tipico | Dove si sbaglia di più |
|---|---|---|
| Backup file + database | 20-40 min | Dimenticare il database |
| Setup nuovo hosting | 30-60 min | SSL non attiva prima del DNS |
| Copia file + import DB | 30-90 min | wp-config non aggiornato |
| DNS e propagazione | 1-48 ore | TTL alto e test troppo presto |
| Verifica finale | 30 min | Dimenticare email e cache |
Domande frequenti
- Quanto tempo serve per migrare WordPress?
L’operazione vera e propria dura da 30 minuti a 3 ore. Il DNS, invece, ha bisogno fino a 48 ore per propagarsi: durante quel periodo il sito può rispondere dal vecchio o dal nuovo server.
- Rischio di perdere i dati?
No, se fai un backup completo (file e database) e lo tieni fuori dal server. La maggior parte delle perdite nasce da backup a metà, non dalla migrazione in sé.
- Posso migrare senza fermare il sito?
Sì, quasi del tutto: prepari e testi tutto sul nuovo hosting mentre il vecchio continua a servire le visite, poi giri il DNS e svuoti la cache. Il tempo di inattività reale è minimo.
- Cosa succede alle email durante la migrazione?
Se i record MX restano nello stesso DNS, le email continuano ad arrivare. Se il nuovo hosting gestisce anche la posta, pianifica il cambio dei record MX come parte della migrazione.
- Devo rifare il backup dopo la migrazione?
Sì. Il backup del vecchio hosting non vale più: appena il sito è stabile sul nuovo server, fai una copia fresca di file e database e impostala come base per i backup futuri.
In pratica: il piano d’azione in 8 mosse
Ricapitoliamo: questa è la sequenza completa da seguire, nell’ordine. Se la rispetti, la probabilità di problemi si riduce.
- Fai il backup completo (file + database) e tienilo fuori dal server
- Prepara il nuovo hosting: database, utente, SSL
- Copia i file e importa il database
- Aggiorna wp-config.php con i dati del nuovo database
- Abbassa il TTL nel DNS, poi punta il dominio al nuovo server
- Verifica HTTPS, link, email, permalink e velocità
- Svuota la cache del nuovo hosting
- Non spegnere il vecchio server finché il sito non è stabile
Se durante la migrazione vuoi un punto di riferimento sulla sicurezza (i permessi dei file, per esempio, sono un classico da sistemare dopo il trasferimento), la guida completa alla sicurezza WordPress ti copre. E quando il sito è sul nuovo server, il lavoro successivo comincia: la guida alle performance WordPress ti mostra come sfruttarlo al massimo.
Un’ultima cosa, che viene da chi lo ha scritto dopo averlo fatto: «e poi la migrazione su un hosting migliore, perché quello incluso non reggeva». È la frase che riassume la migrazione più comune, quella in cui il sito è cresciuto e l’hosting incluso nell’offerta ha smesso di bastare. Non è un fallimento: è il momento in cui il progetto ha superato i limiti del piano che aveva. Se stai leggendo questa guida, sei esattamente lì.
Se preferisci farti seguire da chi queste migrazioni le fa di mestiere, su madweb.it ci occupiamo di hosting WordPress: ti trasferiamo il sito, verifichiamo ogni dettaglio e la prima settimana la passiamo insieme al monitoraggio.
Lascia un commento