Migrazione WordPress per Agenzie: Guida Completa con WP-CLI e Script [2026]

La migrazione WordPress è l’operazione che ogni agenzia fa almeno una volta al mese, e che nove agenzie su dieci sbagliano. Spostare un sito da un hosting all’altro, da un dominio a un altro, o da un ambiente shared a uno dedicato sembra banale: copi file, copi database, cambi URL. Poi il sito non carica. Oppure carica ma i permalink sono rotti. Oppure funziona ma il redirect dal vecchio dominio manda tutto in loop. Nella nostra esperienza su 50+ siti gestiti con AgencyPilot, abbiamo sistematizzato il processo di migrazione WordPress fino a renderlo un’operazione ripetibile in meno di 30 minuti, con zero downtime e zero chiamate di emergenza dai clienti.

In questa guida vediamo come migrare un sito WordPress in ogni scenario possibile: cambio hosting, cambio dominio, migrazione a Docker, migrazione verso headless, e migrazione bulk di 10+ siti simultaneamente. Con script reali, comando per comando.

TL;DR

• Una migrazione WordPress completa richiede 4 fasi: backup, trasferimento file, trasferimento database, riconfigurazione URL e permalink
• Il 70% dei problemi post-migrazione deriva da serialized data nel database che non viene aggiornato correttamente
• WP-CLI + rsync riducono il tempo di migrazione da ore a minuti per siti fino a 10GB
• Il redirect 301 dal vecchio dominio al nuovo deve essere configurato a livello di server (Nginx/Apache), non di plugin
• Per migrazioni bulk (10+ siti), uno script bash con WP-CLI automatizza l’intero processo in parallelo
• Sempre testare su ambienti staging prima del deploy finale

Tipi di Migrazione WordPress: Quale Scenario Ti Trovi Davanti

Prima di toccare qualunque cosa, devi capire che tipo di migrazione ti serve. Le migrazioni WordPress si dividono in quattro categorie, ognuna con insidie diverse.

1. Migrazione di Hosting (Same Domain, New Server)

Il caso più semplice. Il dominio resta uguale, cambi solo il server. I problemi principali qui sono: differenze di versione PHP, permessi dei file, e configurazione del web server. Se il vecchio server ha PHP 8.1 e il nuovo ha PHP 8.3, alcuni plugin potrebbero deprecare. Se il vecchio server usa Apache e il nuovo usa Nginx, i file .htaccess non funzionano più e le regole di rewrite vanno riscritte.

2. Migrazione di Dominio (New Domain, Same or New Server)

Qui cambia l’URL del sito. Ogni riferimento a vecchiodominio.it nel database deve diventare nuovodominio.it. Il problema è che WordPress serializza molti dati (opzioni dei plugin, widget, menu) e un semplice REPLACE SQL non basta. Una stringa serializzata che contiene l’URL vecchio ha una lunghezza fissa scritta nel campo. Se cambi l’URL e la lunghezza cambia, il dato diventa illeggibile. Serve wp search-replace di WP-CLI, che gestisce la deserializzazione e riserializzazione correttamente.

3. Migrazione a Docker o Container

Se stai migrando verso un setup Docker come quello che abbiamo descritto nella nostra guida, il processo è diverso. I file non vanno copiati via rsync: vanno montati come volumi. Il database non va esportato come SQL dump: va inizializzato come container MariaDB con il dump importato. La complessità è nella configurazione del docker-compose.yml, non nel trasferimento dei dati.

4. Migrazione Headless (WordPress come Backend API)

Se stai separando il frontend (Next.js, React) dal backend WordPress, la “migrazione” è in realtà una ristrutturazione. WordPress diventa un’API headless: i contenuti si servono via REST API o GraphQL, il frontend è un’applicazione separata. Qui la migrazione riguarda principalmente la configurazione degli endpoint REST API personalizzati e l’autenticazione.

Pre-migrazione: Checklist Obbligatoria

Prima di iniziare qualunque migrazione, questa checklist deve essere 100% completata. Saltare un punto significa rischiare perdita di dati.

Questa checklist ti prende 15 minuti. Una migrazione andata male per un passo saltato ti può costare ore. O giorni, se il cliente scopre che il suo e-commerce non funziona lunedì mattina.

Migrazione di Hosting: Step by Step con WP-CLI

Questo è lo scenario più comune. Stesso dominio, server nuovo. Vediamo il processo completo usando WP-CLI e rsync, che è il metodo più veloce e affidabile per siti fino a 20GB.

Step 1: Backup sul server vecchio

# Sul server VECCHIO
cd /var/www/sito

# Export database
wp db export /tmp/migrazione-backup.sql --allow-root

# Backup file (tar preserva permessi e symlink)
tar czf /tmp/sito-backup.tar.gz .

Step 2: Trasferimento al nuovo server

# Dal nuovo server, scarica i backup
rsync -avz --progress vecchio-server:/tmp/migrazione-backup.sql /tmp/
rsync -avz --progress vecchio-server:/tmp/sito-backup.tar.gz /tmp/

# Oppure, se rsync diretto non è possibile, usa scp
scp vecchio-server:/tmp/migrazione-backup.sql /tmp/
scp vecchio-server:/tmp/sito-backup.tar.gz /tmp/

Step 3: Ripristino sul nuovo server

# Sul server NUOVO
mkdir -p /var/www/sito
cd /var/www/sito

# Estrai i file
tar xzf /tmp/sito-backup.tar.gz

# Correggi ownership (se il web server gira come www-data)
chown -R www-data:www-data /var/www/sito

# Correggi permessi
find /var/www/sito -type d -exec chmod 755 {} \;
find /var/www/sito -type f -exec chmod 644 {} \;
chmod 644 /var/www/sito/wp-config.php

# Crea il database vuoto
mysql -u root -p -e "CREATE DATABASE sito_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"

# Importa il database
wp db import /tmp/migrazione-backup.sql --allow-root

# Aggiorna wp-config.php con le nuove credenziali DB
# (edit manuale di DB_NAME, DB_USER, DB_PASSWORD, DB_HOST)

Step 4: Verifica post-migrazione

# Flush rewrite rules (critico dopo cambio server)
wp rewrite flush --allow-root

# Svuota cache
wp cache flush --allow-root

# Verifica che il sito carichi
wp option get siteurl --allow-root
wp option get home --allow-root

# Testa la homepage con curl
curl -I https://tuosito.it/

Se la risposta è 200 OK, la migrazione base è completa. Ma ci sono tre cose che spesso saltano fuori e ti fanno perdere tempo.

Problema 1: Permalink rotti

Su Apache, se .htaccess non si rigenera, i permalink danno 404. Soluzione: vai in Impostazioni > Permalink e clicca “Salva” senza cambiare nulla. WordPress rigenera il file. Su Nginx, devi verificare che la configurazione del server block includa try_files $uri $uri/ /index.php?$args;.

Problema 2: Mixed content (HTTP vs HTTPS)

Se il vecchio server serviva HTTP e il nuovo ha SSL, o viceversa, alcuni contenuti potrebbero caricarsi sul protocollo sbagliato. Esegui:

wp search-replace 'http://tuosito.it' 'https://tuosito.it' --allow-root
wp search-replace 'http://www.tuosito.it' 'https://tuosito.it' --allow-root

Problema 3: Cron jobs non funzionano

Se sul vecchio server avevi configurato un cron reale al posto di WP-Cron, devi ricreare la stessa configurazione sul nuovo server. Controlla crontab -l sul vecchio server e replica. La configurazione tipica è:

# Disabilita WP-Cron in wp-config.php
define('DISABLE_WP_CRON', true);

# Cron reale (eseguito ogni 5 minuti)
*/5 * * * * curl -s https://tuosito.it/wp-cron.php?doing_wp_cron > /dev/null 2>&1

Migrazione di Dominio: Cambiare URL Senza Rompere Nulla

La migrazione di dominio è il tipo più insidioso. Non perché sia tecnicamente complessa, ma perché WordPress memorizza l’URL in centinaia di punti diversi: opzioni del database, serialized data nei widget, meta dei post, link nei contenuti, URL delle immagini. Se ne manchi uno, il sito ha link rotti o immagini mancanti.

Il comando sbagliato (che trovi in troppi tutorial) è questo:

-- SBAGLIATO: non gestisce i serialized data
UPDATE wp_options SET option_value = REPLACE(option_value, 'vecchio.it', 'nuovo.it');

Questo funziona per le stringhe semplici. Ma i widget di WordPress memorizzano i dati come array serializzati. Se vecchio.it ha 10 caratteri e nuovo.it ne ha 9, la lunghezza nella stringa serializzata non corrisponde più e il widget va in tilt.

Il comando corretto è wp search-replace di WP-CLI, che deserializza, sostituisce, e riserializza correttamente:

# Sul nuovo server, dopo aver importato il database
wp search-replace 'https://vecchiodominio.it' 'https://nuovodominio.it' --allow-root --all-tables

# Verifica quante sostituzioni sono state fatte
wp search-replace 'https://vecchiodominio.it' 'https://nuovodominio.it' --allow-root --all-tables --dry-run

# Non dimenticare il www (se usato)
wp search-replace 'https://www.vecchiodominio.it' 'https://www.nuovodominio.it' --allow-root --all-tables

# Aggiorna anche eventuali riferimenti HTTP
wp search-replace 'http://vecchiodominio.it' 'https://nuovodominio.it' --allow-root --all-tables

Dopo il search-replace, tre passaggi obbligatori:

1. Flush rewrite rules: wp rewrite flush --allow-root
2. Rigenera thumbnail: wp media regenerate --allow-root (le immagini con URL vecchio nei meta devono essere rigenerate)
3. Clear cache: wp cache flush --allow-root e svuota la cache del server (Redis, Varnish, Nginx fastcgi cache)

Redirect 301: Configurazione Server

Dopo una migrazione di dominio, il vecchio dominio deve reindirizzare al nuovo. Questo passa PageRank e traffico. Non usare un plugin per questo: la latenza di PHP è inaccettabile per un redirect che deve servire ogni singola URL del sito.

Su Nginx:

# Configurazione del vecchio dominio (Nginx)
server {
    listen 80;
    listen 443 ssl;
    server_name vecchiodominio.it www.vecchiodominio.it;
    
    # SSL cert del vecchio dominio (deve restare attivo)
    ssl_certificate /etc/letsencrypt/live/vecchiodominio.it/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/vecchiodominio.it/privkey.pem;
    
    # Redirect 301 permanente
    return 301 https://nuovodominio.it$request_uri;
}

Su Apache:

# .htaccess del vecchio dominio
RewriteEngine On
RewriteCond %{HTTP_HOST} ^vecchiodominio\.it [OR]
RewriteCond %{HTTP_HOST} ^www\.vecchiodominio\.it
RewriteRule ^(.*)$ https://nuovodominio.it/$1 [R=301,L]

Secondo i dati di Google Search Central, un redirect 301 passa il 100% del PageRank dalla vecchia URL alla nuova. Ma il redirect deve restare attivo per almeno 6 mesi, idealmente 12. Tienilo su finché Google non ha indicizzato tutto il nuovo dominio.

Migrazione Bulk: 10+ Siti in Parallelo

Quando un’agenzia acquisisce il portafoglio clienti di un’altra agenzia, si trovano a dover migrare 20, 30, 50 siti in una settimana. Farlo manualmente, uno per uno, significa lavorare 14 ore al giorno per una settimana. Con uno script bash e WP-CLI, puoi migrare 10 siti in parallelo in circa un’ora.

Ecco lo script che usiamo noi, semplificato per leggibilità:

#!/bin/bash
# bulk-migrate.sh — Migrazione bulk WordPress con WP-CLI
# Uso: ./bulk-migrate.sh sites.txt

SITES_FILE="$1"
NEW_SERVER_WEBROOT="/var/www"
NEW_DB_PREFIX="wp_"

if [ -z "$SITES_FILE" ]; then
    echo "Uso: $0 "
    echo "Formato file: dominio|vecchio_server|db_user|db_pass|db_name"
    exit 1
fi

migrate_site() {
    local domain=$1
    local old_server=$2
    local db_user=$3
    local db_pass=$4
    local db_name=$5
    
    local webroot="${NEW_SERVER_WEBROOT}/${domain}"
    local logfile="/tmp/migrate-${domain}.log"
    
    echo "[$(date +%H:%M:%S)] Inizio migrazione $domain" > "$logfile"
    
    # 1. Crea directory
    mkdir -p "$webroot"
    
    # 2. Rsync file dal vecchio server
    rsync -avz --delete "${old_server}:/var/www/${domain}/" "${webroot}/" >> "$logfile" 2>&1
    
    # 3. Export database dal vecchio server via SSH
    ssh "$old_server" "wp db export /tmp/${domain}.sql --path=/var/www/${domain} --allow-root" >> "$logfile" 2>&1
    scp "${old_server}:/tmp/${domain}.sql" "/tmp/${domain}.sql" >> "$logfile" 2>&1
    
    # 4. Crea database sul nuovo server
    mysql -u root -p"${MYSQL_ROOT_PASS}" -e "CREATE DATABASE IF NOT EXISTS \`${db_name}\` CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;" >> "$logfile" 2>&1
    mysql -u root -p"${MYSQL_ROOT_PASS}" -e "GRANT ALL ON \`${db_name}\`.* TO '${db_user}'@'localhost' IDENTIFIED BY '${db_pass}';" >> "$logfile" 2>&1
    
    # 5. Importa database
    mysql -u "${db_user}" -p"${db_pass}" "${db_name}" < "/tmp/${domain}.sql" >> "$logfile" 2>&1
    
    # 6. Aggiorna wp-config.php
    sed -i "s/define( *'DB_NAME'.*/define('DB_NAME', '${db_name}');/" "${webroot}/wp-config.php"
    sed -i "s/define( *'DB_USER'.*/define('DB_USER', '${db_user}');/" "${webroot}/wp-config.php"
    sed -i "s/define( *'DB_PASSWORD'.*/define('DB_PASSWORD', '${db_pass}');/" "${webroot}/wp-config.php"
    sed -i "s/define( *'DB_HOST'.*/define('DB_HOST', 'localhost');/" "${webroot}/wp-config.php"
    
    # 7. Fix permessi
    chown -R www-data:www-data "$webroot"
    find "$webroot" -type d -exec chmod 755 {} \;
    find "$webroot" -type f -exec chmod 644 {} \;
    
    # 8. WP-CLI post-migrazione
    wp rewrite flush --path="$webroot" --allow-root >> "$logfile" 2>&1
    wp cache flush --path="$webroot" --allow-root >> "$logfile" 2>&1
    
    # 9. Verifica
    http_code=$(curl -s -o /dev/null -w "%{http_code}" "https://${domain}/")
    echo "[$(date +%H:%M:%S)] $domain → HTTP $http_code" >> "$logfile"
    
    # Cleanup
    rm "/tmp/${domain}.sql"
    ssh "$old_server" "rm /tmp/${domain}.sql" 2>/dev/null
    
    echo "[$(date +%H:%M:%S)] Fine migrazione $domain" >> "$logfile"
}

# Esegui migrazioni in parallelo (max 5 contemporanee)
MAX_PARALLEL=5
count=0

while IFS='|' read -r domain old_server db_user db_pass db_name; do
    migrate_site "$domain" "$old_server" "$db_user" "$db_pass" "$db_name" &
    count=$((count + 1))
    
    if [ $((count % MAX_PARALLEL)) -eq 0 ]; then
        wait
    fi
done < "$SITES_FILE"

wait
echo "Tutte le migrazioni completate."

Il file sites.txt ha questo formato:

cliente1.com|old-server.agency.com|wp_cliente1|pass123|db_cliente1
cliente2.com|old-server.agency.com|wp_cliente2|pass456|db_cliente2
cliente3.com|old-server.agency.com|wp_cliente3|pass789|db_cliente3

Con 5 migrazioni in parallelo, 30 siti finiscono in circa 45 minuti. Il limite a 5 parallele evita di saturare la banda di rete tra i due server. Se i siti sono piccoli (sotto 1GB), puoi spingere a 10 paralleli.

Tool di Migrazione: Confronto delle Opzioni

Non tutte le migrazioni richiedono WP-CLI e script manuali. Esistono plugin e tool che automatizzano parte del processo. Ecco i principali, con i loro limiti reali.

La verità: per un'agenzia che gestisce più di 5 siti, WP-CLI + rsync è l'unico metodo che scala. I plugin vanno bene per migrazioni occasionali o per clienti che vogliono farlo da soli.

Migrazione verso Docker: Caso Specifico

Se stai migrando verso un setup Docker come quello descritto nella nostra guida al deploy WordPress con Docker, il processo cambia. I file non vanno copiati nel document root: vanno montati come volumi nel container.

Ecco il workflow completo.

1. Prepara il dump del database

# Sul server vecchio
wp db export /tmp/migrazione.sql --path=/var/www/sito --allow-root
gzip /tmp/migrazione.sql

2. Copia i file wp-content

# Sul nuovo server Docker
mkdir -p ./wordpress/wp-content ./mariadb/init

# Copia wp-content (temi, plugin, uploads)
rsync -avz vecchio-server:/var/www/sito/wp-content/ ./wordpress/wp-content/

# Copia il dump del database
scp vecchio-server:/tmp/migrazione.sql.gz ./mariadb/init/

3. Crea il docker-compose.yml

version: '3.8'

services:
  wordpress:
    image: wordpress:7.0-php8.3-fpm-alpine
    volumes:
      - ./wordpress/wp-content:/var/www/html/wp-content
      - ./wordpress/php.ini:/usr/local/etc/php/conf.d/custom.ini
    environment:
      WORDPRESS_DB_HOST: mariadb
      WORDPRESS_DB_USER: wp_user
      WORDPRESS_DB_PASSWORD: secure_pass
      WORDPRESS_DB_NAME: wp_db
    depends_on:
      mariadb:
        condition: service_healthy
  
  mariadb:
    image: mariadb:11.4
    volumes:
      - db_data:/var/lib/mysql
      - ./mariadb/init:/docker-entrypoint-initdb.d
    environment:
      MYSQL_ROOT_PASSWORD: root_pass
      MYSQL_DATABASE: wp_db
      MYSQL_USER: wp_user
      MYSQL_PASSWORD: secure_pass
    healthcheck:
      test: ["CMD", "healthcheck.sh", "--connect"]
      interval: 10s
      timeout: 5s
      retries: 3
  
  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx/default.conf:/etc/nginx/conf.d/default.conf
      - ./wordpress:/var/www/html
      - ./certbot:/etc/letsencrypt
    depends_on:
      - wordpress

volumes:
  db_data:

Il dump SQL in ./mariadb/init/ viene importato automaticamente al primo avvio del container MariaDB. Questo è il modo più pulito per migrare un database in Docker.

4. Avvia e verifica

docker compose up -d

# Verifica che WordPress risponda
curl -I http://localhost/

# Se 200 OK, fix permessi nei volumi
docker compose exec wordpress chown -R www-data:www-data /var/www/html/wp-content

# Flush rewrite rules
docker compose exec wordpress wp rewrite flush --allow-root

Post-migrazione: Verifica e Troubleshooting

Dopo ogni migrazione, un set di controlli standard. Ecco cosa testare e come.

Controlli automatici con WP-CLI

# Verifica salute del sito
wp debug check --path=/var/www/sito --allow-root

# Lista plugin con errori
wp plugin list --status=active --path=/var/www/sito --allow-root --format=table

# Verifica permessi file
wp eval 'echo (is_writable(WP_CONTENT_DIR) ? "OK" : "PROBLEM") . "\n";' --path=/var/www/sito --allow-root

# Verifica cron jobs
wp cron event list --path=/var/www/sito --allow-root

# Controlla broken links (richiede plugin WPCLI-Inspect)
wp inspect-links broken --path=/var/www/sito --allow-root 2>/dev/null || echo "Installa WPCLI-Inspect per check link automatico"

Controlli manuali con curl

# Homepage
curl -sI https://tuosito.it/ | head -5

# Una pagina interna (verifica permalink)
curl -sI https://tuosito.it/sample-page/ | head -5

# wp-login.php (verifica che admin sia raggiungibile)
curl -sI https://tuosito.it/wp-login.php | head -5

# robots.txt
curl -s https://tuosito.it/robots.txt | head -10

# sitemap.xml (se presente)
curl -sI https://tuosito.it/sitemap.xml | head -3

# REST API
curl -s https://tuosito.it/wp-json/wp/v2/posts?per_page=1 | head -c 200

Se tutti questi rispondono correttamente, la migrazione è completa. Se qualcuno fallisce, ecco i problemi più comuni e le soluzioni.

Problema: Errore 500 dopo migrazione

Nel 90% dei casi è un problema di permessi o di memoria PHP. Controlla:

# Log errori PHP
tail -50 /var/log/php8.3-fpm.log
tail -50 /var/log/nginx/error.log

# Aumenta memory limit se necessario
wp config set WP_MEMORY_LIMIT '256M' --path=/var/www/sito --allow-root

# Verifica permessi wp-content
ls -la /var/www/sito/wp-content/
chown -R www-data:www-data /var/www/sito/wp-content/

Problema: Immagini non caricano

Le immagini caricate con URL del vecchio dominio non si vedono. Soluzione:

# Search-replace anche nei meta delle immagini
wp search-replace 'vecchiodominio.it' 'nuovodominio.it' wp_postmeta --allow-root

# Rigenera tutti i thumbnail (può richiedere tempo)
wp media regenerate --path=/var/www/sito --allow-root

# Se ci sono immagini referenziate nel contenuto dei post
wp search-replace 'vecchiodominio.it/wp-content/uploads' 'nuovodominio.it/wp-content/uploads' wp_posts --allow-root

Problema: Email di WordPress non partono

Dopo migrazione, le email di WordPress (notifiche, reset password, form di contatto) spesso smettono di funzionare. Il motivo: il nuovo server non ha un MTA configurato, oppure l'IP del nuovo server è in una blacklist. Soluzione rapida: usa SMTP.

# Installa WP Mail SMTP
wp plugin install wp-mail-smtp --activate --path=/var/www/sito --allow-root

# Configura SMTP via wp-config.php
wp config set WPMS_SMTP_HOST 'smtp.tuodominio.it' --path=/var/www/sito --allow-root
wp config set WPMS_SMTP_PORT 587 --path=/var/www/sito --allow-root
wp config set WPMS_SMTP_AUTH true --path=/var/www/sito --allow-root

Oppure, se hai accesso al server, configura Postfix come MTA locale. Per agenzie che gestiscono molti siti, un sistema di monitoring che avvisa quando le email falliscono è essenziale.

Checklist Finale: Cosa Verificare dopo una Migrazione

• Homepage carica correttamente (HTTP 200)
• Almeno 3 pagine interne caricano (permalink funzionanti)
• wp-login.php accessibile e login funziona
• Admin dashboard carica senza errori PHP
• Plugin attivi tutti funzionanti (verifica uno per uno nei plugin più critici)
• Immagini visibili (nessuna immagine rotta)
• Form di contatto invia email di test
• Sitemap.xml accessibile
• robots.txt accessibile
• SSL valido (verifica con curl -vI https://tuosito.it/ 2>&1 | grep -i ssl)
• Redirect 301 dal vecchio dominio funzionante (se applicabile)
• Cron jobs configurati e funzionanti
• Cache attiva e funzionante (Redis, Varnish, o page cache)
• Google Search Console: notifica il cambio di dominio se applicabile
• Bing Webmaster Tools: stesso, se monitorato
• Backup automatico configurato sul nuovo server
• Hardening di sicurezza verificato (firewall, fail2ban, security headers)

FAQ

Quanto tempo richiede una migrazione WordPress?

Per un sito standard (200-500MB di file + database fino a 50MB), una migrazione completa con WP-CLI richiede 15-30 minuti. Per siti più grandi (multimedia pesanti, database di 500MB+), il tempo sale a 1-2 ore. Per migrazioni bulk di 20+ siti, uno script parallelo completa tutto in 1-2 ore totali.

Si può migrare WordPress senza downtime?

Sì. Il metodo: configura il nuovo server completamente, testalo con un host file o un sottodominio temporaneo, e poi cambia i DNS del dominio per puntare al nuovo server. Il TTL del DNS dovrebbe essere abbassato a 300 secondi (5 minuti) almeno 24 ore prima del cambio. Durante la propagrazione DNS, mantieni entrambi i server attivi. Il downtime effettivo è zero.

Cosa succede se la migrazione fallisce a metà?

Hai il backup pre-migrazione (vero?). Ripristina il backup sul vecchio server e ricomincia. Il punto critico è non aver modificato nulla sul vecchio server prima che la migrazione sia verificata sul nuovo. Mantieni il vecchio server attivo per almeno 7 giorni dopo la migrazione come safety net.

Serve un plugin per migrare WordPress?

No, per migrazioni tecniche WP-CLI + rsync sono sufficienti e più affidabili. I plugin come Duplicator o All-in-One WP Migration sono utili per chi non ha accesso SSH o per migrazioni occasionali. Per un'agenzia che migra siti regolarmente, lo script bash con WP-CLI è la soluzione più scalabile.

Come gestire i DNS durante una migrazione di dominio?

Abbassa il TTL del DNS a 300 secondi almeno 24 ore prima. Configura il nuovo server completamente. Cambia il record A per puntare al nuovo IP. Monitora la propagrazione con uno strumento come dig tuosito.it +short da diverse posizioni. Mantieni il vecchio server attivo con il redirect 301 per almeno 6 mesi.