Modernizzare i dati legacy: migrazione da Oracle on-premises a Azure SQL Database

Il contesto: quando il dato frena l’evoluzione

Molte aziende stanno spostando applicazioni e analytics nel cloud, ma il dato operativo resta spesso ancorato a database legacy perché lì vive la parte più critica del business.

In questo progetto, il cuore informativo dell’organizzazione era un Oracle on-premises storico: affidabile, ma sempre più difficile da far dialogare con l’ecosistema cloud, più costoso da mantenere e meno flessibile per le nuove esigenze di reporting e integrazione.

L’obiettivo era quindi sbloccare una roadmap: rendere il dato governabile, integrabile e pronto per un’evoluzione cloud-first senza destabilizzare l’operatività quotidiana.

Il problema di business: continuità e fiducia nei dati

Quando la base dati è legacy, il rischio è operativo oltre che tecnologico:

• integrazioni lente o fragili con nuove applicazioni,
• reporting poco reattivo e difficile da scalare,
• costi che crescono (licensing, manutenzione, competenze rare),
• scarsa tracciabilità del ciclo di vita del dato.

Per questo l’organizzazione ha scelto un target Azure SQL / SQL Server-based, più coerente con lo stack Microsoft già presente, più semplice da integrare con BI e servizi cloud e con opzioni di licensing più flessibili.

Il vincolo principale: migrare in modo governato, preservando integrità e coerenza dei dati, senza introdurre rischi sistemici.

La scelta architetturale: ADF come orchestratore, SharePlex per il CDC

In questo scenario, la sensibilità al tempo non era il driver principale: la priorità era affidabilità e tracciabilità.

Inoltre il Change Data Capture era già gestito esternamente tramite SharePlex, quindi Azure Data Factory poteva concentrarsi su ciò che fa meglio in contesti enterprise:

• orchestrazione end-to-end,
• migrazione iniziale completa,
• pipeline batch ripetibili,
• bulk load controllati,
• validazioni e compensazioni in caso di anomalie,
• gestione errori con retry e monitoraggio.

Il punto non era “far partire una copia”, ma costruire un processo ripetibile, osservabile e controllabile, in grado di reggere la complessità reale del legacy.

Le sfide e come le abbiamo affrontate

1) Differenze tra tipi di dato e schema
Oracle e SQL Server non parlano la stessa lingua: NUMBER, DATE, encoding e precisioni possono creare errori o inconsistenze. Abbiamo gestito la normalizzazione definendo mapping espliciti e controlli di coerenza per evitare failure in fase di load.

2) Tabelle grandi e tempi non sostenibili
Con milioni di record, un batch unico diventa un collo di bottiglia (o un incidente annunciato). Abbiamo usato partitioned copy e parallelizzazione controllata, con filtri per range (date/ROWID) e, dove opportuno, logiche incrementali con watermark.

3) Connettività ibrida e sicurezza
L’Oracle on-prem era in rete privata: niente scorciatoie. Abbiamo adottato Self-Hosted Integration Runtime (SHIR) all’interno della rete del cliente, con sole chiamate HTTPS in uscita verso Azure, riducendo l’impatto sulle policy di rete. Per la gestione credenziali, l’architettura prevede l’uso di Azure Key Vault.

4) Qualità del dato legacy: l’elefante nella stanza
Il legacy raramente è “pulito”: mancano vincoli, ci sono formati misti, record obsoleti. Caricare direttamente nel modello finale significa portarsi dietro il debito, spesso amplificandolo. Per questo abbiamo implementato una strategia a doppio staging:

• Raw staging: copia fedele per audit e reprocessing.
• Transformation staging: pulizia, validazioni e arricchimenti prima del merge.

La qualità del dato non è un effetto collaterale: è parte della migrazione.

Il design dell’architettura: governabilità prima di tutto

La soluzione è stata costruita intorno a un principio: se non è tracciabile, non è governabile.

• Oracle on-prem come sorgente.
• SHIR come ponte sicuro verso Azure.
• ADF come regia: copy activity, data flow/stored procedure, trigger e orchestrazione.
• Staging come “zona di controllo”: validazione, rollback, reprocessing.
• Merge/Upsert nello schema target come ultimo passo, solo dopo controlli.

Questa struttura consente di gestire non solo la migrazione, ma anche l’evoluzione: una volta costruita la pipeline, diventa un asset operativo.

I risultati: dal trasferimento dati alla maturità operativa

Una migrazione ben governata non si misura solo con “il dato è arrivato”. Si misura con ciò che abilita dopo.

Con il nuovo ambiente SQL Server/Azure SQL:

• Modello dati più coerente e documentato: riduzione ridondanze, normalizzazione relazioni, naming e strategie PK uniformate.
• Reporting più performante e flessibile: dati puliti e trasformati disponibili direttamente per i tool BI moderni.
• Maggiore affidabilità operativa: pipeline ripetibili, controlli, reprocessing e tracciabilità end-to-end.
• Base solida per l’ecosistema cloud: integrazioni più semplici, evoluzioni più rapide, meno attrito tra sistemi.

In pratica: il dato, da vincolo da gestire, diviene una piattaforma su cui costruire.

Conclusione: modernizzare il dato è modernizzare l’azienda

Questo progetto è un esempio di modernizzazione “realistica”: senza promesse magiche e senza big bang.

Quando il legacy viene trattato con metodo, staging, validazioni, orchestrazione, governance, la migrazione diventa un acceleratore: aumenta la qualità del dato, riduce i rischi e sblocca nuove iniziative digitali.

Se stai valutando una migrazione dati da on-prem a cloud, la domanda non è “quale tool usare”, ma come garantire controllo, qualità e continuità mentre cambi le fondamenta. Parliamone: possiamo aiutarti a progettare una migrazione governata, tracciabile e pronta per evolvere.