Once the cost of staying on a legacy warehouse is on the table, the next question is the one that stalls most programmes: how do we actually move without breaking the reporting the organisation runs on? An Oracle data warehouse migration is rarely lost on technology. It is lost on method - on big-bang cutovers, on lifting thousands of undocumented jobs across unchanged, and on hoping the numbers still tie out afterwards rather than proving it.

The good news is that this is a solved problem when it is treated as an engineering discipline rather than a leap of faith. The momentum is real: more than 28,000 organisations are now running Microsoft Fabric in production, and the tooling for moving off Oracle has matured quickly - Microsoft has introduced native mirroring for Oracle (in preview) alongside an open-mirroring partner ecosystem, making continuous replication into the cloud far more practical than it was even a year ago.

This is the seven-step framework we use to migrate an Oracle data warehouse to the cloud with the risk engineered out.

The governing principle: migrate capability, not just tables

Before the steps, the mindset. A migration that simply re-hosts your old structures in the cloud buys you faster technical debt. The goal is to migrate the capability - clean, governed, analytics-ready data - while keeping the legacy system queryable until trust in the new platform is earned, not assumed. Every step below serves that principle.

Step 1 - Inventory and assess the estate

You cannot plan a migration from an estimate. Start by parsing the full estate: every ETL mapping, every stored procedure, every table and view, and the dependencies between them. For an Oracle and ODI environment that typically means cataloguing thousands of objects and classifying each by complexity - simple, moderate, complex or genuinely bespoke.

The output is an inventory register signed off before any code is written. It turns a vague "we have about a thousand mappings" into an evidence-based scope, sized and sequenced. This single step is the difference between a programme that runs to plan and one that discovers its true scale halfway through.

Step 2 - Design the target architecture

Design the destination before you move anything. The dominant pattern is the medallion lakehouse on a single, tenancy-wide data lake: a Bronze layer for raw, immutable source captures; a Silver layer where data is cleansed, conformed and given history; and a Gold layer of curated, subject-area marts ready for reporting. Organise workspaces by business domain so each team owns its own area while central governance and a single source of truth are preserved.

Define your environment strategy at the same time - separate development, test and production environments, with code-based promotion between them. Getting this right early is what makes the later steps repeatable rather than improvised.

Step 3 - Choose the migration path for each object

Not everything should be treated the same way. Using the complexity classification from Step 1, decide a path per object against clear criteria: functional fit, performance, code quality, ownership, dependencies and cost-benefit. In practice most mappings are straightforward lift-and-shift candidates; a meaningful minority need templated re-engineering with human review; and a small bespoke group needs full redesign with the relevant data owner. Deciding this deliberately - rather than rewriting everything or lifting everything - is where time and budget are won or lost.

Step 4 - Move the data

With the design set, bring the data across. The right mechanism depends on the source. Microsoft's mirroring for Oracle (currently in preview) and its open-mirroring partner ecosystem - including tools such as Qlik Replicate and Oracle GoldenGate - can stream changes continuously into the lake with minimal impact on the source system. Where native mirroring is not yet appropriate, a metadata-driven Data Factory pipeline using change-data-capture remains the dependable approach.

Whichever you use, build for incremental loading and idempotency from the start: a re-run should produce the same result, and a failed run should resume cleanly rather than double-loading. Land everything in Bronze with full audit metadata so the raw capture is always replayable.

Step 5 - Re-engineer the transformation logic

This is the heart of the work: converting Oracle ETL and PL/SQL into the target platform. Mappings are re-expressed as cloud-native pipelines and notebooks; stored-procedure logic is translated to the warehouse's SQL and to PySpark where appropriate. Automate the high-volume, low-complexity majority and reserve specialist effort for the bespoke logic that genuinely needs a human.

Crucially, do not let business logic scatter the way it did in the legacy estate. Place it deliberately by layer - conformance and history in Silver, curated business rules in Gold - so it is documented, owned and testable rather than buried in opaque jobs.

Step 6 - Reconcile and validate against the legacy

This step is what lets you decommission Oracle with confidence. Run the old and new platforms in parallel and reconcile across multiple layers, each with an explicit tolerance:

• Structural - schema, columns, data types and keys match exactly.

• Volumetric - row counts agree by table and partition within tolerance.

• Content - column-level hashing confirms the values themselves match.

• Key integrity - no orphaned or duplicated keys.

• Metric - business KPIs reconcile between old and new.

• User acceptance - the most-used reports are compared side by side and signed off by the data owner.

The rule is simple: nothing is approved for cutover until the technical layers stay green for a sustained, agreed period and the report-level comparison is signed off. Reconciliation is not a formality at the end - it is the evidence base for the whole programme.

Step 7 - Cut over in waves, not in one leap

Finally, move to production in calendar-aware waves rather than a single big-bang event. Sequence the cutover around the organisation's critical cycles - never into a peak reporting or operational window - and run each domain in parallel before switching it over. Keep the legacy platform available read-only for a defined period after each wave so rollback is always possible, then decommission once trust is established. This is how you migrate while statutory and operational reporting keeps running uninterrupted.

The things that run through every step

Three concerns are not steps but constants:

• Governance and lineage from day one. Import lineage into your catalogue as you migrate, applying sensitivity labels and access controls, so governance is preserved through the move rather than rebuilt afterwards.

• A semantic layer for self-service. Present Gold data through governed, business-friendly semantic models (Direct Lake removes refresh windows entirely), so the migration ends in trusted self-service, not just relocated tables.

• Knowledge transfer and skills. Build your in-house team's capability throughout - Microsoft's DP-600 and DP-700 certifications map directly to these skills - so the platform is owned and operable without ongoing reliance on a partner.

Common pitfalls to avoid

Most failed migrations repeat the same mistakes: a big-bang cutover with no rollback; lifting-and-shifting everything to "save time" and inheriting the old technical debt; treating reconciliation as a tick-box at the end; losing lineage in the move; and cutting over into a peak business cycle. The framework above exists precisely to design these risks out.

Planning a migration? Book a short discovery call to pressure-test your approach.