Oracle to Microsoft Fabric: Why PL/SQL Conversion Drives the Timeline

Key takeaways

• PL/SQL to T-SQL conversion is the dominant timeline driver, not the destination platform.
• Cursor-heavy procedural patterns need refactoring into set-based operations.
• Oracle features like sequences, materialized views, RAC/Exadata patterns, and autonomous transactions need Fabric-native rebuilds.
• Realistic timeline: 16 to 24 weeks for mid-size Oracle estates with accelerators. Manual programs commonly run 18 to 36 months.

Why Oracle is the toughest Fabric migration path

Oracle and Microsoft Fabric are not in the same language family. Synapse Dedicated and Fabric share T-SQL. SQL Server and Fabric share T-SQL. Oracle and Fabric share nothing at the language level. PL/SQL has its own syntax, its own error model, its own transaction semantics, and its own procedural patterns. Migration is rewriting, not translating.

The conversion volume is the same as the source code volume, but the per-object effort is two to five times higher than a same-family migration.

Five PL/SQL patterns that drive most of the work

Cursor loops and row-by-row processing

Oracle PL/SQL code is often written in procedural style with cursor loops processing one row at a time. T-SQL prefers set-based operations. Direct translation of cursor loops produces working but extremely slow Fabric code. Refactoring to set-based logic is required for production performance. This is the largest single source of conversion effort.

Packages and modular code organization

Oracle packages group related procedures, functions, and variables into a single unit with shared state. T-SQL has no direct equivalent. Packages need decomposition into individual procedures with state externalized to tables or session variables. The decomposition itself is straightforward. Getting the dependency order right is the hard part.

Triggers and event-driven logic

Oracle triggers fire on data changes. Fabric does not have direct trigger equivalents. Event-driven logic needs to be redesigned as pipeline steps, change data capture patterns, or external event-driven services. The redesign often improves the architecture, but it is work.

Sequences and identity generation

Oracle sequences generate unique identifiers across transactions. Fabric uses identity columns and Snowflake-style approaches for distributed ID generation. The semantics differ. Most sequence patterns map cleanly to identity columns, but distributed sequence requirements need redesign.

Materialized views and autonomous transactions

Materialized views can be rebuilt in Fabric using stored procedures, scheduled refresh patterns, or Spark-based aggregations. Autonomous transactions, which let inner transactions commit independently of an outer transaction, do not exist in Fabric. Code that depends on autonomous transactions needs architectural changes.

Architecture pattern that usually wins

For Oracle source estates, the recommended Fabric pattern is Lakehouse-heavy with Warehouse used only for the Gold layer. Two reasons. First, the cursor refactoring work often benefits from Spark's distributed compute, which sits naturally in Lakehouse. Second, the procedural logic decomposition is easier to express as Notebook-based pipelines than as monolithic stored procedures. Teams that migrate Oracle estates into Warehouse-only Fabric architectures usually rearchitect within a year.

Plan your modernization with a fact-based blueprint

If you are working on an Oracle to Fabric migration, the next practical step is a fixed-price Modernization Assessment. Source-connected discovery, complexity scoring, target architecture, effort estimation, and bulk-converted sample code, delivered as a Modernization Canvas in 8 business days. No long discovery, no procurement cycle, Director-level signing authority.