16 Sep 2026

Oracle to Microsoft Fabric: Migration & Mirroring

Oracle to Microsoft Fabric migration moves an Oracle database or data warehouse, including Exadata workloads, onto Microsoft Fabric by re-architecting schema, PL/SQL logic, and storage, not just repointing a connection string. Tables move to OneLake in open Delta format, PL/SQL becomes T-SQL or PySpark, and OBIEE reporting is rebuilt in Power BI. A separate, lower-effort option exists for operational systems that need to stay on Oracle: near-real-time Mirroring replicates data into OneLake without any ETL rebuild.

Quick Summary

Oracle to Fabric migration re-architects schema, PL/SQL logic, and storage, not just the connection string. PL/SQL becomes T-SQL or PySpark; stored procedures and materialized views are re-derived and validated, not mechanically translated. Licensing is usually the biggest driver: Oracle's per-core database and Exadata licensing often costs far more annually than the Fabric capacity that replaces it. For systems that need to stay operational on Oracle, Mirroring offers a genuinely different, much lower-effort path to live analytics access without a rebuild.

oracle-to-microsoft-fabric-migration-mirroring

Key Takeaways

Not a lift-and-shift. Oracle to Fabric migration re-architects schema, PL/SQL logic, and storage, not just the connection string.
Mirroring is a genuine alternative to full migration. Operational Oracle systems can replicate into OneLake live via Change Data Capture, with no ETL pipeline rebuild required.
PL/SQL becomes T-SQL or PySpark. Stored procedures, packages, and materialized views are re-derived, not mechanically translated, and validated against source output.
Licensing is usually the biggest driver. Oracle's per-core database and Exadata licensing often costs far more annually than the Fabric capacity that replaces it.
Reporting moves too. OBIEE and Oracle Analytics dashboards are rebuilt against a Fabric semantic model, often using Direct Lake for near-real-time performance.
Data types need explicit validation. Oracle's NUMBER and VARCHAR2 types don't map automatically, risking precision or truncation loss.
Validation determines go-live. Row- and column-level parity testing against the original Oracle output is what makes a migrated warehouse production-ready.

What Is Oracle to Microsoft Fabric Migration?

Oracle to Microsoft Fabric migration is the process of moving an Oracle database or data warehouse, including Exadata-hosted workloads, to Microsoft Fabric by rebuilding schema, PL/SQL transformation logic, and reporting within Fabric's OneLake-based platform. Because Oracle's PL/SQL procedural engine and proprietary storage differ fundamentally from Fabric's T-SQL and Spark engines on open, Delta-format storage, migration is a structural rebuild: tables and partitions are re-modeled on OneLake, PL/SQL logic is re-derived as T-SQL, Spark SQL, or PySpark, and Oracle-based reporting is rebuilt in Power BI, the same layered-rebuild approach covered in our ETL migration to Microsoft Fabric guide for other source platforms.

In short: Oracle-to-Fabric migration replaces a proprietary, license-heavy database engine with an open, capacity-based Lakehouse platform; every stored procedure, materialized view, and report is rebuilt, not copied.

Oracle Integration Options: Mirroring vs. Full Migration

Before scoping a full rebuild, it's worth knowing that Microsoft offers a genuinely different, much lower-effort path for a specific use case: keeping Oracle running and simply replicating its data into Fabric live, rather than migrating and rebuilding the ETL logic around it.

Mirroring (near-real-time replication). Fabric's Oracle Mirroring provides a zero-ETL replication path that continuously mirrors supported Oracle databases into OneLake using Oracle LogMiner, allowing organizations to keep the operational Oracle system in place while making its data available for analytics in Fabric.
Data Factory pipelines and Dataflow Gen2 (full migration). This is the rebuild path the rest of this guide covers: Copy Activity for full or incremental loads, Dataflow Gen2 for Power Query-based transformation, and the PL/SQL-to-T-SQL/PySpark rebuild for stored procedures and business logic.

The two aren't mutually exclusive. Many organizations mirror lower-priority or still-operational Oracle systems into OneLake for immediate analytics access, while running the full migration process on the systems actually being retired- the same hybrid-first framing covered in our Snowflake vs Microsoft Fabric comparison for a different platform pairing facing the same coexistence question.

Why Enterprises Are Moving Off Oracle

Retiring an Oracle data warehouse is usually driven by a mix of licensing cost, hardware age, and platform-consolidation pressure rather than any single missing feature, and the decision often gets revisited every time an Oracle or Exadata support renewal comes due:

Licensing and infrastructure cost can be major migration drivers. Oracle database, RAC, and Exadata licensing and support costs can be substantial, while Microsoft Fabric uses capacity-based pricing. The actual economics depend on workload size, utilization, existing Microsoft licensing, and required Fabric capacity.
Cloud-native elasticity. Fabric's Spark and warehouse engines scale up and down with Fabric capacity, instead of a fixed, over-provisioned Exadata rack sized for peak load.
Open storage format. Data lands on OneLake in open Delta/Parquet format, removing the vendor lock-in of Oracle's proprietary storage engine, the same open-format advantage covered in our data lake work.
Unified analytics. Once Oracle data lands on OneLake, it's directly queryable from Power BI, Data Factory, and notebooks, removing the export/ETL layer a standalone Oracle warehouse requires, the same consolidation benefit covered in our ETL Solutions overview.
End-of-support and hardware pressure. Aging Exadata hardware and Oracle version upgrades push many enterprises toward Oracle modernization on a defined timeline, not an open-ended one.
Simpler operating model. A cloud-native Lakehouse removes the need to size, patch, and refresh Exadata hardware, often the least-loved part of running a legacy Oracle estate, the same operational simplification covered in our Azure to Microsoft Fabric migration guide.

Oracle to Fabric Asset Mapping

Mapping Oracle objects to their Fabric equivalent is the foundation of scoping any Oracle to Fabric Warehouse conversion.

Oracle Object	Fabric Equivalent	Migration Note
Table/partition	Fabric Data Warehouse table / Lakehouse Delta table	Partitioning strategy is redesigned around Fabric's storage and query patterns
PL/SQL stored procedure	T-SQL stored procedure / PySpark notebook	Procedural logic is re-derived and validated, not mechanically translated
PL/SQL package	Notebook function / Data Factory pipeline	Related procedures and functions are regrouped as reusable Fabric artifacts
Materialized view	Fabric Data Warehouse view / Dataflow Gen2 query	Refresh logic is rebuilt using Fabric's scheduled refresh or incremental patterns
Oracle Data Integrator (ODI) job	Data Factory pipeline / Dataflow Gen2	Orchestration and transformation logic move to Fabric-native pipelines
Sequence / trigger-based ID	Identity column / surrogate key logic	Auto-increment behavior is re-implemented using Fabric-native identity patterns
Oracle RAC / Exadata compute	Fabric capacity (F-SKU)	Fixed engineered-system compute is replaced by elastic, consumption-based capacity
OBIEE / Oracle Analytics report	Power BI report on a Fabric semantic model	Rebuilds dashboards, often using Direct Lake mode
Database role/grant	Fabric workspace role / OneLake permission	Database-level security moves to Fabric's workspace and item-level access control
Oracle job scheduler (DBMS_SCHEDULER)	Data Factory pipeline trigger	Scheduled jobs and dependency chains are rebuilt as Fabric pipeline triggers
Oracle export/import (Data Pump)	OneLake data ingestion (Data Factory/notebook)	Bulk historical loads are re-implemented as a one-time Fabric ingestion pipeline
Data types (NUMBER, VARCHAR2, etc.)	Fabric-native SQL/Spark types	Map carefully; precision and truncation loss are common if type mapping isn't validated explicitly
On-premises Oracle connectivity	Oracle Client for Microsoft Tools (OCMT) + on-premises data gateway	Required for secure pipeline connections when Oracle sits behind a corporate firewall

Step-by-Step Migration Process

Discovery. Catalog every Oracle schema, table, PL/SQL object, and downstream report, and score complexity to sequence the work, the same complexity-scoring approach covered in our key checklist for BI modernization.
Schema and storage design. Re-model tables and partitions for OneLake, choosing Fabric Data Warehouse or Lakehouse per workload.
PL/SQL conversion. Translate stored procedures, packages, and materialized views into T-SQL, Spark SQL, or PySpark, validating each against source output.
Data migration. Move historical and incremental data onto OneLake, replacing Oracle's storage engine with open Delta/Parquet format, or configure Mirroring for systems remaining operational on Oracle.
Reporting rebuild. Convert OBIEE and Oracle Analytics dashboards into Power BI reports against a Fabric semantic model, the same reporting-rebuild discipline covered in our guide to BI automation for report migration and our broader BI reports and dashboard development work.
Validate and cut over. Reconcile Fabric output against the original Oracle warehouse row by row before retiring Oracle infrastructure, the same validation discipline covered in our guide to automating ETL testing with Python.

Common Oracle Migration Challenges

PL/SQL complexity. Deeply nested procedural logic, cursors, and exception handling don't translate mechanically and need manual redesign, the same manual-redesign discipline covered in our legacy scripts modernization work.
Materialized view refresh logic. Oracle's fast-refresh and complex-refresh semantics must be reproduced explicitly in Fabric's scheduling model.
Performance tuning differences. Oracle's cost-based optimizer and Exadata-specific features (smart scan, storage indexes) have no direct Fabric equivalent, so query patterns often need redesign.
Data type precision. NUMBER and VARCHAR2 mappings need explicit validation to prevent silent truncation or precision loss during initial loads.
Licensing and hardware wind-down. Retiring Exadata and Oracle licensing on a defined schedule requires coordinating the migration cutover with existing support contracts.
Institutional knowledge. Critical PL/SQL logic is often held by one or two long-tenured DBAs, so documenting the reasoning behind each procedure matters as much as converting it, the same knowledge-capture discipline behind our reports conversion services.

Oracle Migration Best Practices

Inventory every schema, table, and PL/SQL object before estimating migration effort, including who actually queries each one and how often- the same inventory-first discipline covered in our key checklist for BI modernization.
Consider Mirroring for systems staying operational. Not every Oracle workload needs a full rebuild; mirroring provides analytics access without the migration effort when the source system isn't being retired.
Migrate the highest-value, most-queried tables first to build momentum and prove the approach before tackling the long tail of rarely used objects.
Automate most straightforward table and view conversions, and reserve manual effort for complex PL/SQL, where automated tooling reliably falls short.
Redesign partitioning and indexing around Fabric's query patterns, not a copy of the Oracle schema, since the two engines optimize very differently.
Validate data types explicitly, not just row counts. NUMBER and VARCHAR2 precision issues surface as subtle value drift, not obvious failures.
Validate row- and column-level parity for every converted object, not just a representative sample, since silent drift is easy to miss otherwise; the same rigor is covered in our guide to automating ETL testing with Python.
Run legacy Oracle and the new Fabric warehouse in parallel for a defined validation window before retiring Oracle infrastructure.
Coordinate the cutover with Oracle support and licensing renewal dates so the migration timeline aligns with when licensing costs would otherwise reset.

Case Study: Oracle Data Warehouse Modernization

Representative profile of an Oracle to Fabric migration engagement, not a single named client, reflecting a pattern seen across enterprise Oracle modernization projects.

The challenge. A manufacturing enterprise ran its core data warehouse on an aging Exadata rack, with a small DBA team maintaining PL/SQL ETL logic and rising per-core licensing costs at each renewal cycle.

The approach. DataTerrain inventoried every schema and PL/SQL object and scored it for complexity, re-modeled the highest-value tables on Fabric Data Warehouse first, converted PL/SQL procedures to T-SQL and PySpark, and rebuilt OBIEE dashboards as Power BI reports on a Fabric semantic model, validating output against Oracle before each cutover wave.

Metric	Result
PL/SQL objects converted	300+ procedures and views rebuilt
Row-level parity	Full match after validation
Legacy platform	Exadata rack retired

Frequently Asked Questions

Can Oracle schemas be imported directly into Fabric?

No. Tables are re-modeled for OneLake, and PL/SQL logic is rebuilt as T-SQL, Spark SQL, or PySpark; there's no native import path.

How does licensing compare?

Oracle's per-core database and Exadata licensing is retired entirely; Fabric uses capacity-based F-SKUs that can be shared with existing Power BI workloads, which is central to any Oracle-to-Fabric cost comparison.

What's a realistic Oracle-to-Fabric timeline?

It depends on schema size and PL/SQL volume; a mid-size warehouse often runs 4-9 months across discovery, conversion, and validation.

Why are people moving away from Oracle?

Most commonly, licensing and hardware costs: Oracle's per-core database and Exadata licensing is among the most expensive in enterprise IT, combined with the operational burden of patching and refreshing engineered-system hardware on a fixed cycle. Platform consolidation, wanting one unified analytics stack instead of a standalone database plus separate BI tools, is the other major driver.

What can Microsoft Fabric connect to?

A broad range of sources, including Oracle (via native connector, mirroring, or gateway), SQL Server, Azure services, Snowflake, Databricks, and most major cloud and on-premises databases, with new connectors added regularly as Fabric's ecosystem matures.

Migrate Your Oracle Estate with DataTerrain

DataTerrain has modernized legacy Oracle and Exadata data warehouses across enterprise engagements, covering both the full migration path and Mirroring-based coexistence for systems that need to stay operational. Our assessment inventories your Oracle schema and PL/SQL estate, maps it to Fabric Data Warehouse and Lakehouse patterns, and delivers a validated migration with output-parity testing before cutover, the same broad platform coverage reflected in our best data analytics services.

Talk to Our Migration Team