Un cliente ci ha chiamato con un piano già pronto: finestra di manutenzione di sei ore, sabato notte, export/import classico. Il database gestiva gli ordini di un e-commerce con traffico internazionale, fusi orari diversi, zero tolleranza per il fermo. Sei ore di stop significavano ordini persi, notifiche ai clienti, un problema reputazionale prima ancora che tecnico. Non erano nemmeno sicuri che sei ore sarebbero bastate.
Questo è l’errore più comune: pensare la migrazione come un evento, non come un processo. Il downtime non si riduce lavorando più in fretta — si elimina cambiando approccio.
Il downtime si prepara, non si subisce
La finestra di manutenzione lunga nasce da un’idea sbagliata: che i dati vadano spostati tutti insieme, in un unico blocco, mentre il sistema è fermo. È il metodo di dieci anni fa. Con un database critico oggi non funziona, e non dovrebbe funzionare nemmeno su sistemi meno critici.
L’alternativa è la replica continua. Il database di origine resta attivo e operativo per tutto il tempo della migrazione. In parallelo, uno strumento di replica — Oracle GoldenGate per la replica logica, Data Guard per quella fisica, a seconda del caso — copia i dati sul target cloud e li mantiene sincronizzati in tempo reale. Non è un backup che scarichi una volta. È un flusso che non si interrompe.
Il cutover dura minuti, non ore
Quando il target è allineato — stessa struttura, stessi dati, stesso stato — arriva il momento del cutover: lo switch effettivo del traffico dal vecchio sistema al nuovo. Con la replica continua attiva, questo passaggio richiede minuti, non ore. In alcuni scenari ben progettati, secondi.
Il segreto non è la tecnologia in sé, ma il momento in cui la usi. Il lavoro pesante — la sincronizzazione, la validazione, il tuning del target — avviene prima, a sistema acceso. Il cutover è solo l’ultimo passo, quello visibile, ma è anche il più breve.
Cosa serve prima di partire
Prima di toccare una riga di configurazione, va fatta una diagnosi seria. Non un audit formale — un lavoro tecnico vero:
- Mappatura delle dipendenze: job schedulati, trigger, link tra database, applicazioni che scrivono direttamente sulle tabelle senza passare da API.
- Dimensionamento del workload: picchi di scrittura, orari critici, batch notturni che non puoi permetterti di far collidere con la sincronizzazione.
- Compatibilità di versione: Oracle su cloud non è sempre identico a Oracle on-premise. Alcune feature enterprise richiedono licensing specifico anche in ambiente gestito.
- RTO e RPO concordati: quanto tempo di fermo è davvero accettabile, e quanti dati puoi permetterti di perdere in caso di incidente durante il passaggio. Se non li hai definiti prima, li scopri nel modo peggiore durante il cutover.
Chi salta questa fase risparmia un giorno di assessment e ne perde una settimana in troubleshooting. Non è un’opinione, è quello che vediamo ogni volta che ci chiamano dopo un tentativo fallito.
Il rollback è parte del piano, non un’eccezione
Un piano di migrazione che non prevede il rollback non è un piano, è una scommessa. Il sistema di origine deve restare disponibile e sincronizzato per un periodo definito dopo il cutover — non per pigrizia, ma perché qualsiasi problema emerga nelle prime ore o nei primi giorni deve poter tornare indietro senza perdita di dati.
Questo significa mantenere la replica attiva anche dopo lo switch, in direzione inversa, per una finestra di sicurezza concordata. Solo dopo aver validato che il nuovo ambiente regge — performance, integrità referenziale, tempi di risposta delle query critiche — si dismette il vecchio sistema.
Quando farlo internamente, quando no
Un team interno può gestire questo processo se ha già esperienza diretta con GoldenGate o Data Guard su ambienti di produzione, e se può permettersi di dedicare un DBA senior a tempo pieno per le settimane della migrazione. Se questa esperienza manca, il rischio non è il fallimento della migrazione — è il fallimento silenzioso: dati disallineati che emergono tre mesi dopo, query che rallentano senza motivo apparente, un backup che in realtà non si può ripristinare perché nessuno lo ha mai testato davvero.
Noi lavoriamo con DBA certificati, on-site o in outsourcing, proprio su questo tipo di migrazioni: amministrazione, tuning, backup, spostamento in cloud di sistemi Oracle che non possono permettersi un errore. Non arriviamo con un metodo standard da applicare a tutti allo stesso modo — ogni sistema critico ha le sue dipendenze, i suoi orari, la sua tolleranza al rischio. Il piano si costruisce su quello, non su un template.
Il cliente dell’e-commerce, alla fine, ha fatto il cutover in un martedì mattina, dodici minuti di switch, zero ordini persi. La finestra di sei ore di sabato notte non è mai servita. Serviva solo cambiare l’ordine delle operazioni.
