Spostare un database — da un server vecchio a uno nuovo, o dall’on-premise al cloud — spaventa per un motivo solo: il downtime. Se il gestionale o l’e-commerce si ferma, l’azienda si ferma. La buona notizia: con il metodo giusto il fermo si può ridurre a pochi minuti o azzerare. Ecco come.
Perché il downtime è il vero problema
Una migrazione database “ingenua” (spegni, copia, riaccendi) può richiedere ore, durante le quali nessuno lavora. Per un database da centinaia di GB, la sola copia può durare mezza giornata. Per molte PMI questo è inaccettabile: serve una strategia che mantenga il sistema operativo durante la migrazione.
Le tecniche, dalla più semplice alla zero-downtime
| Tecnica | Downtime | Quando |
|---|---|---|
| Backup & restore | Alto (ore) | DB piccoli, finestra notturna/weekend disponibile |
| Backup + log di transazione | Medio-basso | Si ripristina il backup, poi si applicano solo le modifiche recenti |
| Replica / log shipping | Basso (minuti) | Il DB di destinazione resta sincronizzato; si fa il “cutover” finale rapido |
| Migrazione online (es. Azure DMS) | Quasi zero | Strumenti che replicano in continuo fino allo switch finale |
Il principio delle soluzioni a basso downtime è sempre lo stesso: tenere sorgente e destinazione sincronizzate mentre il sistema lavora, e fare lo switch (cutover) solo all’ultimo, quando le due copie sono allineate.
L’esempio tipico: SQL Server → Azure SQL
Lo scenario più frequente nelle PMI è portare un SQL Server on-premise nel cloud (Azure SQL Database / Managed Instance). Qui si usa tipicamente Azure Database Migration Service (DMS) in modalità online: replica continua dei dati, validazione, e cutover finale di pochi minuti in una finestra concordata.
I passi per farla bene (e senza sorprese)
- Assessment: dimensioni, dipendenze applicative, compatibilità, requisiti di compliance. È il passo che evita i blocchi a metà strada — vedi il cloud assessment.
- Scelta della tecnica in base al downtime tollerabile e alla dimensione del DB.
- Ambiente di test: si prova la migrazione su una copia prima del produttivo.
- Sincronizzazione + validazione: si verifica che i dati di destinazione siano integri e completi.
- Cutover pianificato: switch finale in una finestra concordata, con piano di rollback pronto.
- Verifica post-migrazione: performance, backup, sicurezza, monitoraggio.
La migrazione di un database è spesso parte di un progetto più ampio di lift and shift o modernizzazione cloud o di migrazione di un gestionale legacy.
Come ti aiuta SynSphere
Pianifichiamo ed eseguiamo migrazioni database con downtime minimo: assessment, scelta della strategia, test, cutover e supporto. Vedi i servizi di migrazione cloud e l’assistenza database gestita, oppure parla con un nostro consulente per valutare la finestra di fermo sostenibile per la tua azienda.