Oracle-to-Microsoft-Fabric migrations are one of the more common platform projects we get asked about in 2026. The drivers are almost always the same: licence renewal coming up, an ageing Exadata or on-premise Oracle estate, a Microsoft tenant already in place, and a finance director who has done the maths. The question is rarely "should we?" and almost always "how, and how long?". Here is the version we wish someone had written before we ran our first one.
Why teams are moving
Three reasons keep coming up. The first is cost — Oracle's per-core licensing on modern hardware has become genuinely eye-watering, and Fabric's capacity model is far cheaper for most analytical workloads. The second is integration — Microsoft 365, Power BI, Teams and now Copilot all live in the same ecosystem as Fabric, so reporting and collaboration just work without bridge software. The third is talent — it is materially easier to hire someone who knows T-SQL, Python and Power BI than someone who knows PL/SQL and OBIEE.
What it is rarely about is performance. A well-tuned Exadata will outperform a small Fabric capacity on raw OLTP workload. The migration case is built on cost, ecosystem and skills, not on a faster query.
What moves easily, and what does not
Moves easily: reporting workloads, data warehouses built in third normal form or star schema, scheduled ETL jobs that already use ANSI SQL, and most BI semantic layers. Fabric's Warehouse workload speaks T-SQL, which is close enough to PL/SQL that most queries port with light rewrites.
Moves with effort: stored procedures with heavy PL/SQL, materialised views with on-commit refresh, anything using Oracle Advanced Queueing, partitioning strategies that rely on Oracle-specific syntax, and packages that bundle procedural logic. Each of these has a Fabric equivalent (Spark notebooks, scheduled pipelines, change feeds) but you are rewriting rather than porting.
Does not move at all: Oracle Forms applications, OLTP workloads with sub-millisecond requirements, anything that depends on Oracle Spatial in non-trivial ways, and most Oracle Apex applications. These need to be re-platformed onto something appropriate (typically Azure SQL or a different app stack) rather than moved into Fabric, which is analytics-oriented.
The realistic timeline
Vendors love to quote "Fabric migration in 12 weeks". For a single data mart with a few hundred objects, that can be true. For a 20-year-old Oracle estate with thousands of objects, it is fantasy. A more honest envelope:
Discovery and assessment: 4–6 weeks. Inventory of objects, classification of what migrates / refactors / retires, mapping of downstream dependencies, agreement on target architecture.
Pilot migration: 6–8 weeks. One subject area (often finance reporting) moved end to end. The point is to prove the approach, expose the gotchas and calibrate timelines.
Wave migrations: 3–6 months per wave, with waves grouped by business domain. A typical mid-sized organisation runs three or four waves.
Parallel run and decommission: 2–3 months. This is the part everyone forgets to budget. Reports run on both systems, results are reconciled, the business signs off, and only then is Oracle switched off.
Total: typically 12–18 months end to end for a meaningful estate. Anyone telling you six months has either not done one or is talking about a single mart.
Architecture choices that matter early
Lakehouse or Warehouse? Fabric offers both, and they are different products with the same job. Warehouse if your team thinks in T-SQL and you want stored procedures and a familiar relational feel. Lakehouse if you are happy with Spark and want maximum openness (Delta tables queryable from anything). We usually recommend a mixed model — Lakehouse for ingestion and Warehouse for the curated, business-facing layer.
How will you ingest from Oracle? Fabric's Data Factory has Oracle connectors but they are not the fastest. For large initial loads, Oracle's own DataPump export to flat files often beats live connectors hands down. For incremental loads, look at Oracle's GoldenGate or change-data-capture approaches feeding into a Fabric mirror.
Semantic model strategy. Power BI on Fabric gives you DirectLake, which is genuinely fast. But if you are coming from OBIEE, the temptation is to recreate the same sprawling subject areas in Power BI, which never ends well. Use the migration to consolidate, not to copy.
The risks worth managing
Three patterns we see go wrong often enough to flag.
Skills gap on the Microsoft side. Oracle DBAs are not Fabric engineers, and asking them to become both in parallel with a migration is a recipe for burnout. Bring in or contract proper Fabric expertise for the first two waves, then cross-train.
Reconciliation taking longer than the build. Getting numbers to match between Oracle and Fabric on the same report often surfaces decades-old rounding, timezone or business-rule quirks. Budget for it explicitly.
Oracle licence overlap costs. You will run both systems in parallel for months. Make sure procurement knows.
If you are sizing up a migration, our Microsoft Fabric consultancy page describes how we usually approach the discovery phase, and our Fabric pricing guide helps with the licence-cost half of the business case.
Frequently asked questions
How long does an Oracle to Microsoft Fabric migration take?
For a meaningful enterprise estate, typically 12–18 months end to end including discovery, pilot, wave migrations and a parallel-run period. Single-mart migrations can finish in 12–16 weeks.
Will my PL/SQL code work in Microsoft Fabric?
Most simple PL/SQL ports to T-SQL with light rewrites. Heavy procedural logic, packages and Oracle-specific features (Advanced Queueing, certain partitioning) need to be re-engineered as Spark notebooks or Fabric pipelines.
Should I use Fabric Lakehouse or Warehouse for the migration target?
Often both — Lakehouse for ingestion and engineering, Warehouse for the curated business layer that reporting and stored procedures hit. The right mix depends on your team's skills and the workload shape.
Want to talk this through with someone?
We are an independent UK Power BI and Microsoft Fabric consultancy. Honest opinions, fair prices, no sales pressure.