← Tutti gli articoli

migrazione

Come spostare un VPS su un altro provider senza rompere il server

Un piano di migrazione in parole semplici per spostare il tuo server su un altro provider senza perdere file, domini, HTTPS o la pazienza.

  • migrazione
  • hosting
  • backup
Due schede server VPS migrano in sicurezza da un vecchio provider a uno nuovo con indicatori di backup, lucchetto e spunta.

Desideri passare a un provider di hosting più performante, ottimizzare i costi dell'infrastruttura o disporre di una macchina con risorse superiori, ma temi che una configurazione errata possa compromettere la disponibilità del tuo sito web.

In sintesi: per migrare un intero server verso un nuovo provider, occorre trasferire l'applicazione, i database, le risorse multimediali caricate dagli utenti, i certificati SSL, le variabili d’ambiente, le regole del firewall e i task pianificati (cron job) prima di modificare i puntamenti DNS. Il percorso più sicuro prevede l'allestimento completo del nuovo server, il collaudo della configurazione, la riduzione del valore TTL dei DNS per velocizzare la propagazione, il reindirizzamento del dominio e il mantenimento del vecchio server in parallelo fino a completa conferma della stabilità del traffico.

Cosa può rompersi quando sposti un server?

Un server non si riduce a una semplice raccolta di file applicativi; costituisce un ecosistema interconnesso di processi, servizi di rete, storage, politiche di sicurezza e routing.

Durante il cambio di provider, il codice sorgente rappresenta solo la componente più immediata da trasferire. Le criticità principali si concentrano di norma sugli elementi meno visibili: la base dati, le directory con gli upload degli utenti, i processi in background, le credenziali d'ambiente riservate, le configurazioni SMTP, le regole di filtraggio del firewall e i certificati HTTPS.

La corretta risoluzione del dominio tramite DNS è un altro punto fondamentale. Se i record A o AAAA puntano ancora all'indirizzo IP del vecchio server, i visitatori continueranno a essere instradati sulla precedente infrastruttura. Se il web server (come Nginx o Apache) risulta mal configurato rispetto al servizio applicativo a monte, il sistema risponderà con un errore 502 Bad Gateway. Allo stesso modo, l'assenza o l'errata associazione del certificato SSL genererà avvisi di protezione nel browser degli utenti, anche a fronte di un'applicazione perfettamente funzionante.

La migrazione richiede quindi il trasferimento completo dell'intero ambiente operativo e delle sue dipendenze.

Cosa dovresti copiare prima di toccare i DNS?

Prima di modificare i puntamenti del dominio, è opportuno stilare un inventario analitico di tutti i componenti che garantiscono l'operatività del server di origine.

Qualora non sia già disponibile un piano di backup testato, la sua predisposizione costituisce il primo passo imprescindibile. Un backup mai sottoposto a simulazione di ripristino non garantisce alcuna certezza operativa. Per un approfondimento sulle strategie di salvataggio, consulta la guida su come fare il backup del server.

ComponenteImportanza operativaErrore comune post-migrazione
File dell’applicazioneGarantiscono l'esecuzione del sito o servizioTrasferire il codice sorgente omettendo i file generati a runtime
DatabaseCustodisce contenuti, utenti, ordini e configurazioniEffettuare l'esportazione con l'applicazione ancora in scrittura
Media e uploadRisorse multimediali, immagini e documenti allegatiMigrare la base dati dimenticando le directory con i file collegati
Variabili d’ambienteContengono le credenziali e i secret di integrazioneOmettere le chiavi API di pagamento, email o servizi terzi
*Task pianificati (cron)*Gestiscono l'invio delle comunicazioni e la manutenzioneIl sito risulta raggiungibile ma i processi in background si interrompono

Verifica inoltre la configurazione del firewall di rete. Se la nuova macchina blocca le porte web di traffico (80 e 443), il sito risulterà inaccessibile; al contrario, regole troppo permissive potrebbero esporre all'esterno servizi che dovrebbero rimanere protetti all'interno della rete locale.

Come fai a tenere online il sito durante lo spostamento?

Imposta il nuovo server come un ambiente di staging isolato prima di reindirizzare il traffico di produzione.

Predisponi l'infrastruttura di destinazione mentre il vecchio server continua a erogare il servizio agli utenti. Configura l'ambiente applicativo, importa una copia aggiornata dei dati ed esegui i test di funzionamento tramite un IP temporaneo o un host locale. L'obiettivo è individuare eventuali dipendenze mancanti, errate credenziali di connessione al database o anomalie come il 502 Bad Gateway prima che abbiano impatto sull'utenza reale.

Pianifica la gestione dei tempi di propagazione DNS agendo sul parametro TTL (Time To Live). Ridurre il TTL nei record DNS con un congruo anticipo consentirà una transizione più rapida al momento dell'aggiornamento dei record A ed AAAA. Per approfondire la gestione dei puntamenti, fare riferimento alla guida come collegare un dominio al tuo server.

Mantieni il server sorgente attivo per un periodo di affiancamento. Poiché la propagazione dei record DNS a livello globale avviene in modo graduale, alcuni utenti o servizi esterni potrebbero continuare a raggiungere il vecchio indirizzo IP per alcune ore. Se l'applicazione consente la creazione di nuovi dati (ordini, commenti, registrazioni), è opportuno prevedere una breve finestra di manutenzione o una sincronizzazione finale del database per evitare disallineamenti.

Completa la procedura verificando la cifratura HTTPS. I certificati emessi da Let’s Encrypt richiedono la convalida del dominio, pertanto il nuovo server deve essere in grado di risponder alle sfide di autenticazione dell'autorità di certificazione. Per le indicazioni pratiche di configurazione, fare riferimento alla guida come ottenere HTTPS gratis sul tuo server.

Come controlli che il nuovo server sia davvero uguale?

Il collaudo non deve fermarsi alla semplice verifica della pagina iniziale, che spesso si limita a erogare elementi statici.

Verifica le funzionalità interne dell'applicazione: effettua l'accesso come utente registrato, invia un modulo di contatto, carica un file di test, richiedi il ripristino della password ed esegui una transazione simulata in caso di e-commerce. Ispeziona la dashboard di amministrazione, i webhook d'integrazione, il servizio di invio email e i job in background. Se l'applicazione impiega sistemi di gestione delle code, assicurati che i worker stiano elaborando i task correttamente.

Presta attenzione ai dettagli di configurazione dell'ambiente: permessi di lettura/scrittura errati sul filesystem, assenza di librerie per la manipolazione delle immagini, riferimenti ad indirizzi IP rigidi nel codice (hardcoded), regole del firewall che bloccano chiamate API esterne o connessioni residue verso il precedente database.

La migrazione si considera conclusa con successo solo quando il nuovo server gestisce la totalità dei processi operativi in modo autonomo e stabili.

FAQ

*È possibile migrare un intero server con zero tempi di inattività (zero-downtime)?* Sì, preparando completamente il nuovo ambiente, riducendo preventivamente il TTL dei record DNS ed eseguendo un'eventuale sincronizzazione finale dei dati prima dell'aggiornamento del dominio.

Quando è opportuno dismettere il vecchio server? È consigliabile mantenere il vecchio server attivo per qualche giorno dopo la migrazione. Questo consente di monitorare la completa propagazione dei DNS, recuperare eventuali file non migrati e disporre di un'infrastruttura di ripristino immediato in caso di anomalie impreviste.

Come si gestiscono i dati inviati dagli utenti durante il trasferimento? Per evitare disallineamenti è preferibile programmare una breve finestra di manutenzione impostando l'applicazione in sola lettura, oppure effettuare un'ulteriore sincronizzazione del database subito prima dell'aggiornamento DNS.

Perché dopo la migrazione viene visualizzato un avviso di certificato SSL non valido? Questo avviso si verifica in genere quando il certificato HTTPS non è stato ancora generato sul nuovo server, oppure quando la richiesta proviene da client i cui DNS risolvono ancora verso l'indirizzo IP del vecchio server.

La soluzione semplificata

Server Manager ti aiuta a gestire la migrazione dell'infrastruttura fornendo una visione chiara e ordinata di tutte le risorse coinvolte. Invece di dover ricostruire l'architettura a memoria dopo mesi dal rilascio, avrai sempre un quadro preciso di quali applicativi, domini e certificati HTTPS siano associati al server.

Questo approccio riduce il rischio delle problematiche più comuni durante un cambio di provider: puntamenti DNS incompleti, certificati SSL scaduti, interferenze tra progetti distinti o configurazioni di sistema non documentate. Il vantaggio risiede nell'intelligibilità dell'ambiente, che consente di confrontare la precedente e la nuova configurazione in modo sistematico.

La sovranità sulla gestione dell'infrastruttura rimane tua, garantendo una migrazione ordinata, priva di imprevisti e con un'architettura comprensibile anche per la manutenzione futura.

Che sensazione dà un cambio di provider fatto bene?

Una migrazione eseguita con metodo si distingue per la totale continuità operativa: gli utenti continuano ad accedere al servizio senza interruzioni, la cifratura HTTPS rimane attiva, le procedure di upload e l'invio delle notifiche funzionano regolarmente e la dismissione del vecchio server avviene in piena sicurezza.

L'obiettivo è trasferire l'intero ecosistema applicativo, collaudarne le componenti in un ambiente isolato prima del rilascio in produzione e conservare una linea di ripristino fino a completa conferma della stabilità del nuovo sistema.