How the work gets done
Translate the relational and procedural layers together, then apply the Oracle-to-Fabric profile. The assessment reports target limitations early, while there is still time to price and sequence the redesign work.
Move Oracle database code toward Microsoft Fabric Warehouse with semantic translation and explicit limitation reporting.
The job to be done
A migration becomes expensive when every object arrives as a separate mystery. Start with the workload as a whole, then sort the result into three useful categories: what can move directly, what needs adaptation, and what deserves a deliberate engineering decision.
For this path, that means understanding Oracle schemas, built-ins, data types, dependencies, packages, procedures, functions, and triggers. and producing Fabric Warehouse T-SQL, supported object types, and native alternatives for platform gaps.. The differences that could affect production behavior are surfaced while the team can still act on them, not after they have become deployment surprises.
Why this path is difficult
Oracle code often assumes database features that do not have a direct Fabric Warehouse equivalent. Manual search and replace can produce valid-looking T-SQL while losing behavior, and teams may not discover the missing feature until deployment or a late test cycle.
How the work gets done
Translate the relational and procedural layers together, then apply the Oracle-to-Fabric profile. The assessment reports target limitations early, while there is still time to price and sequence the redesign work.
Where it helps
Use the scenario for Oracle reporting or operational schemas moving into a Microsoft analytics estate where the target team needs a clean T-SQL baseline and an explicit list of exceptions.
The payoff
The translation runs up front, then becomes an object inventory, coverage view, complexity signal, and findings list. You see the work before you plan it.
Oracle tables, views, types, and queries are translated into the T-SQL surface supported by Fabric Warehouse. PL/SQL objects are translated where Fabric has a viable equivalent; unsupported target behavior is tagged for review instead of hidden.
Generated tests compare source and target behavior for tables, views, functions, and procedures. Performance is recorded alongside correctness, so a passing translation is not mistaken for a fast one.
Where the work happens
These are the source patterns that usually create rework. Each card explains the target-aware treatment, so your team can see what is being adapted and where a decision is still required instead of discovering a mismatch during deployment.
Convert tables, views, constraints, and data types into the Fabric Warehouse surface while identifying definitions that need a target-native shape.
Rewrite Oracle-specific expressions and conversions into supported T-SQL patterns, keeping behavior changes attached to the translated object.
Translate procedural objects where Fabric has a viable equivalent and preserve a reviewable finding where the target needs redesign.
Use the object graph to produce target code in a usable order, reducing the common failure mode where a valid object is deployed before the object it calls.
Turn Fabric feature gaps into named findings before deployment, so the team can estimate remediation instead of discovering it through a failed release.
The path to confidence
Assessment, translation, and testing stay connected, so your team can see what the software handled automatically, what it changed to fit the target, and which decisions still need a human owner.
Connect or upload Oracle code. The parser reads every object, builds dependencies, scores complexity, and shows where Fabric Warehouse needs a different construct.
Relational and procedural objects are translated together, with source semantics kept in context. Where Fabric Warehouse has no direct equivalent, the engine uses a supported rewrite or names the gap clearly.
Deploy the generated target objects to staging, inspect the differences, run generated tests, and use the results to focus engineering time on the exceptions that matter.
The source and target
A script that runs is not proof that a migration worked. The real question is what the target needed in order to preserve the workload’s intent, and whether those changes have been tested. SQL Tran keeps that answer visible at the object level.
Oracle schemas, built-ins, data types, dependencies, packages, procedures, functions, and triggers.
Fabric Warehouse T-SQL, supported object types, and native alternatives for platform gaps.
Evidence you can use
This is not a black box. Findings stay attached to the translated workload, so engineers can inspect the change while decision-makers can see what remains before they approve the move.
Your review list
Every migration has a boundary. Surface it early, and reviewers can spend their time on the few decisions that shape the result instead of rereading thousands of generated lines.
Your working set
Take the next step
Run the assessment against your objects, dependencies, and target version. We do that by running full translation and exposing the real result. That tells you exactly what translates cleanly, what changes, and what needs your attention.
Start the assessment