Area cliente
Linux•29 agosto 2026• 12 visualizzazioni

Migrare un sito da un hosting condiviso a un VPS (2026)

Migrare un sito da un hosting condiviso a un VPS (2026)

Perché migrare verso un VPS?

L'hosting condiviso è adatto ai siti con poco traffico e ai progetti che non hanno bisogno di controllo sull'ambiente server. Alcune esigenze superano questo quadro: una versione PHP specifica non disponibile, accesso root richiesto da una dipendenza di sistema, prestazioni influenzate dal vicinato sul nodo condiviso, o la necessità di ospitare più progetti con configurazioni isolate. La migrazione verso un VPS risponde a questi casi precisi, senza che l'hosting condiviso risulti inadatto agli usi che copre.

Passo 1: Inventario prima della migrazione

Realizzate l'inventario completo prima di toccare qualsiasi cosa. Una migrazione fallita deriva quasi sempre da un elemento dimenticato in questa fase.

File e directory

  • Directory web principale (spesso public_html/, www/ o htdocs/)
  • File di configurazione fuori dalla radice web (file .env, configurazioni applicative)
  • File caricati dagli utenti (spesso in una sottocartella uploads/ o storage/)
  • Cron configurati sull'hosting condiviso (elencarli dal pannello di controllo del provider attuale)

Database

  • Nome del database, nome utente, password (disponibili nel pannello o nel file di configurazione dell'applicazione)
  • Versione MySQL/MariaDB usata sull'hosting condiviso (verificare la compatibilità con la versione di destinazione)

Email

  • Le caselle email ospitate presso il provider di hosting condiviso non migrano automaticamente sul VPS
  • Elencare gli indirizzi email attivi e decidere: migrarli sul VPS (Postfix/Dovecot), spostarli su un servizio terzo, oppure lasciarli presso il provider attuale con i record MX invariati

DNS e TTL

Prima di qualsiasi migrazione, abbassate il TTL del record A del dominio a 300 secondi (5 minuti). Questo riduce il ritardo di propagazione durante il passaggio finale.

Individuate il record A nella zona DNS del dominio (di solito nel pannello del registrar o del provider attuale) e modificate il valore TTL:

; Prima della migrazione: TTL abituale (spesso 3600 o 86400)
miosito.it.  3600  IN  A  1.2.3.4

; Modificare a 300 almeno 24h prima del passaggio
miosito.it.  300   IN  A  1.2.3.4

Attendete almeno la durata del vecchio TTL dopo la modifica prima di procedere al passaggio, affinché la propagazione sia effettiva.

Passo 2: Preparare il VPS

Installate e mettete in sicurezza il VPS prima di trasferire i dati. Non migrate verso un server non configurato.

  • Messa in sicurezza di base (SSH con chiave, UFW, aggiornamenti): Checklist sicurezza VPS
  • Accesso SSH con chiave: Guida chiave SSH
  • Installazione dello stack web (Nginx + PHP-FPM + MariaDB): Guida Nginx + PHP-FPM
  • Creare la directory di destinazione: sudo mkdir -p /var/www/miosito.it
  • Verificare che la versione PHP installata sul VPS sia compatibile con l'applicazione

Passo 3: Trasferire i file

Con rsync (accesso SSH disponibile sull'hosting condiviso)

rsync è il metodo raccomandato: trasferisce solo i file modificati, supporta la ripresa in caso di interruzione e preserva i permessi. Fonte: man rsync

Dal VPS (tirando i file dall'hosting condiviso):

rsync -avz --progress \
  [email protected]:/home/utente/public_html/ \
  /var/www/miosito.it/

Oppure da una macchina locale (con accesso SSH a entrambi i server):

rsync -avz --progress \
  [email protected]:/home/utente/public_html/ \
  [email protected]:/var/www/miosito.it/

Opzioni utilizzate:

  • -a: modalità archivio (preserva permessi, timestamp, link simbolici)
  • -v: verboso (mostra i file trasferiti)
  • -z: compressione durante il trasferimento
  • --progress: mostra l'avanzamento

Senza accesso SSH sull'hosting condiviso (SFTP o download manuale)

Se l'hosting condiviso non offre accesso SSH, utilizzate un client SFTP (FileZilla, Cyberduck) per scaricare i file in locale, poi inviateli sul VPS:

# Dalla macchina locale verso il VPS
rsync -avz --progress /percorso/locale/public_html/ \
  utente@ip-vps:/var/www/miosito.it/

Regolare i permessi

sudo chown -R www-data:www-data /var/www/miosito.it
sudo find /var/www/miosito.it -type d -exec chmod 755 {} \;
sudo find /var/www/miosito.it -type f -exec chmod 644 {} \;

Passo 4: Esportare e importare il database

Esportazione dall'hosting condiviso

Se l'hosting condiviso offre accesso SSH:

mysqldump -u utente_db -p nome_db > export-$(date +%F).sql

Senza accesso SSH, utilizzate phpMyAdmin (disponibile sulla maggior parte degli hosting condivisi): Esporta > Formato SQL > Scarica.

Fonte: dev.mysql.com: mysqldump

Trasferire il file di esportazione sul VPS

scp export-$(date +%F).sql utente@ip-vps:/home/utente/

Creare il database sul VPS

sudo mariadb -u root
CREATE DATABASE nome_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'utente_db'@'localhost' IDENTIFIED BY 'password_forte';
GRANT ALL PRIVILEGES ON nome_db.* TO 'utente_db'@'localhost';
FLUSH PRIVILEGES;
EXIT;

Importare i dati

mariadb -u utente_db -p nome_db < /home/utente/export-$(date +%F).sql

Passo 5: Riconfigurare l'applicazione sul VPS

File di configurazione dell'applicazione

Aggiornate i parametri di connessione al database nel file di configurazione dell'applicazione (.env, wp-config.php, config.php a seconda del framework):

  • Host del database: localhost (il database è sullo stesso server)
  • Nome del database, utente e password: quelli creati al passaggio precedente

Percorsi assoluti

Verificate e aggiornate tutti i percorsi assoluti scritti nella configurazione. Su un hosting condiviso i percorsi iniziano spesso con /home/utente/public_html/; sul VPS iniziano con /var/www/miosito.it/.

URL nel database (se applicabile)

Alcune applicazioni (in particolare WordPress) memorizzano l'URL del sito nel database. Se l'URL cambia durante la migrazione, aggiornate questi valori. Per WordPress, usate WP-CLI:

sudo -u www-data wp search-replace 'http://vecchio-dominio.it' 'https://miosito.it' \
  --path=/var/www/miosito.it

Per le altre applicazioni, consultate la documentazione del framework interessato.

Vhost Nginx

Create il vhost Nginx per il sito. Per un sito PHP generico:

server {
    listen 80;
    server_name miosito.it www.miosito.it;
    root /var/www/miosito.it;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.4-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }
}
sudo ln -s /etc/nginx/sites-available/miosito.it /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

Per WordPress: Guida WordPress su VPS (vhost specifico con gestione dei permalink).

Passo 6: Testare il sito prima del cambio DNS

Non cambiate mai il DNS senza aver verificato che il sito funzioni sul VPS. Modificate il file hosts locale per forzare la risoluzione verso il nuovo IP, senza toccare il DNS pubblico.

Modificare il file hosts locale

Su Linux o macOS:

sudo nano /etc/hosts

Su Windows: C:\Windows\System32\drivers\etc\hosts (aprire come amministratore)

Aggiungete la riga:

ip-del-vps  miosito.it www.miosito.it

Il browser risolve ora miosito.it verso il VPS, senza che gli altri utenti ne siano influenzati.

Punti da verificare

  • Home page e pagine interne si visualizzano correttamente
  • I moduli di contatto funzionano (invio email)
  • Accesso all'area di amministrazione
  • File caricati accessibili (immagini, documenti)
  • Reindirizzamenti attivi (301, 302)
  • Nessun errore nei log di Nginx: sudo tail -f /var/log/nginx/error.log

Rimuovere la voce hosts dopo i test

# Rimuovere la riga aggiunta in /etc/hosts
sudo nano /etc/hosts

Passo 7: Emettere il certificato SSL

Emettere il certificato Let's Encrypt prima del cambio DNS non è possibile (Certbot deve risolvere il dominio verso il VPS). Emettete il certificato subito dopo il passaggio, mentre il TTL basso è ancora attivo.

sudo certbot --nginx -d miosito.it -d www.miosito.it

Guida completa: Guida Certbot OuiHeberg.

Passo 8: Cambiare il DNS

Una volta convalidati i test, modificate il record A del dominio per puntare all'IP del VPS:

; Prima
miosito.it.  300  IN  A  1.2.3.4   (vecchio IP condiviso)

; Dopo
miosito.it.  300  IN  A  5.6.7.8   (nuovo IP del VPS)

Con il TTL a 300 secondi, la propagazione è effettiva in 5-10 minuti per la maggior parte dei resolver DNS. Monitorate i log di Nginx durante questo periodo per confermare che il traffico arrivi sul VPS:

sudo tail -f /var/log/nginx/access.log

Una volta confermata la propagazione, riportate il TTL a un valore standard (3600 o 86400):

miosito.it.  3600  IN  A  5.6.7.8

Passo 9: Periodo di sovrapposizione

Mantenete l'hosting condiviso attivo per 1 o 2 settimane dopo il passaggio. Questo periodo permette di:

  • Recuperare file dimenticati durante l'inventario iniziale
  • Verificare che le email ospitate sul condiviso continuino ad arrivare (se i record MX non sono cambiati)
  • Disporre di un punto di ritorno rapido in caso di problema critico

Non cancellate i dati sull'hosting condiviso prima di aver confermato che tutto funziona correttamente sul VPS.

Errori frequenti

Le email restano presso il vecchio provider

Se il dominio aveva caselle email sull'hosting condiviso, i record MX continuano a puntare al vecchio provider dopo il cambio del record A. Spesso è voluto (mantenere le email presso il provider attuale durante la transizione), ma verificate che sia intenzionale. Decidete esplicitamente la strategia email prima del cambio DNS.

I cron non si attivano più

Le attività pianificate configurate nel pannello dell'hosting condiviso non migrano automaticamente. Ricreatele nel crontab del VPS:

crontab -e

Elencate i cron del vecchio provider dal suo pannello di controllo prima della migrazione (fase di inventario).

Il certificato SSL non viene emesso subito

Certbot non può emettere un certificato per un dominio che non punta ancora al VPS. Emettete il certificato subito dopo il cambio DNS, mentre il TTL basso è ancora attivo. Tra il passaggio e l'emissione del certificato, il sito è accessibile solo in HTTP.

I percorsi assoluti nel database

Alcune applicazioni memorizzano percorsi assoluti nel database (percorso dei file caricati, URL delle immagini). Questi percorsi vanno aggiornati dopo la migrazione. Usate la funzione cerca e sostituisci dell'applicazione oppure uno script SQL:

UPDATE wp_options SET option_value = REPLACE(option_value,
  '/home/vecchio/public_html',
  '/var/www/miosito.it')
WHERE option_value LIKE '%/home/vecchio/public_html%';

Domande frequenti

Quanto dura una migrazione?

Per un sito standard (qualche centinaio di MB, un database di dimensioni ragionevoli), la migrazione tecnica richiede da 1 a 3 ore. La preparazione (inventario, abbassamento del TTL, configurazione del VPS) rappresenta la maggior parte del tempo. Il cambio DNS in sé richiede meno di 10 minuti con un TTL di 300 secondi.

Si può migrare senza interruzione di servizio?

Sì, se la procedura viene seguita nell'ordine: il sito resta attivo sull'hosting condiviso per tutta la preparazione e i test. L'unica interruzione potenziale è la finestra tra il cambio DNS e l'emissione del certificato SSL (pochi minuti). Con un TTL di 300 secondi, questa finestra è breve.

Bisogna avvisare i visitatori?

Per un sito con poco traffico, no. Per un sito e-commerce o un'applicazione con utenti connessi (sessioni attive), pianificate la migrazione fuori dagli orari di punta e mostrate una pagina di manutenzione durante il passaggio.

Cosa fare se il sito non funziona dopo il passaggio?

Riportate il record A sul vecchio IP dell'hosting condiviso (il TTL di 300 secondi permette un ritorno rapido). Diagnosticate il problema sul VPS senza pressione, poi rilanciate il passaggio una volta risolto. È proprio per questo che l'hosting condiviso deve restare attivo durante il periodo di sovrapposizione.

Non avete ancora deciso? Il nostro articolo VPS o hosting condiviso illustra i casi in cui la migrazione ha senso.

State migrando più siti sullo stesso VPS? Preparate in anticipo la struttura delle directory e l'isolamento: configurazione multi-sito con Nginx.

Torna alla documentazione