Translate SQL Server tables and queries to Spark SQL, and move stored procedures and functions into PySpark for Fabric Lakehouse.
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 SQL Server schemas, T-SQL, built-ins, dependencies, procedures, functions, and triggers. and producing Spark SQL for relational objects and Python or PySpark for procedural logic.. 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
SQL Server tables and queries can move toward Spark SQL, but stored procedures, functions, triggers, and procedural workflows cannot simply be copied into a Fabric Lakehouse. A T-SQL rewrite alone leaves the execution model unresolved.
How the work gets done
SQL Tran separates the workload into Spark SQL for relational objects and PySpark for procedural behavior. It translates both from the same SQL Server model, keeping dependencies and findings connected across the two output planes.
Where it helps
This fits SQL Server estates moving reporting or transformation workloads into Fabric Lakehouse, where the target team needs Delta-ready data objects and executable PySpark rather than an incomplete T-SQL dump.
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.
SQL Server tables, views, and queries become Spark SQL for the Fabric Lakehouse relational plane. T-SQL procedures, functions, triggers, and procedural workflows become PySpark code for the Spark execution plane.
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.
Translate relational DDL, views, and queries into Spark SQL for the Fabric Lakehouse data plane, with dependencies preserved for deployment and review.
Move stored procedures, functions, triggers, and transformation logic into PySpark where the Spark runtime can execute it and the target team can maintain it.
Adapt SQL Server built-ins, date and string functions, casts, joins, and null behavior to Spark-compatible output instead of leaving semantic cleanup to hand edits.
Show how PySpark workflows depend on Spark SQL tables and views, so the migration produces an executable plan rather than separate SQL and Python folders.
Compare source results with Spark output and exercise procedural paths before promotion, while keeping performance observations visible for the target workload.
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 SQL Server code. The parser reads every object, builds dependencies, scores complexity, and shows where Fabric Lakehouse needs a different construct.
Relational and procedural objects are translated together, with source semantics kept in context. Where Fabric Lakehouse 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.
SQL Server schemas, T-SQL, built-ins, dependencies, procedures, functions, and triggers.
Spark SQL for relational objects and Python or PySpark for procedural logic.
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