The migrator reads your Synapse workspace, classifies every object, and converts what can be converted. Where a construct has no Fabric equivalent, it says so and hands that piece back to a human with the original definition intact. You get a defensible object list and a wave plan before anyone commits to a date.
Dedicated SQL pools go to Warehouse, serverless views over ADLS go to shortcuts and the SQL analytics endpoint, Spark pools and notebooks go to Fabric notebooks and environments, and Synapse pipelines go to Fabric Data Factory. Each has its own set of things that translate cleanly, things that translate with a rewrite, and things that have no equivalent at all. Most teams find out which is which halfway through, after the plan and the budget are fixed.
A four-year-old Synapse workspace holds hundreds of tables, views, stored procedures, notebooks, linked services and pipelines, and a meaningful share of them are dead. Walking sys.objects, the git-backed artifact folders and the trigger list by hand takes days, and it gets redone every time scope moves.
Dedicated SQL pool DDL is full of constructs Fabric Warehouse does not have: distribution clauses, clustered columnstore declarations, table partitioning, identity columns, materialized views, resource classes. Legacy types like money, text, image, sql_variant and xml have to be mapped or dropped, and the default collation changes sort and comparison behaviour. Each one is a silent failure waiting at deployment.
Synapse pipeline JSON is close enough to ADF that people assume copy-paste works. Then Mapping Data Flows have no target, self-hosted integration runtimes become gateway connections, global parameters have no home, tumbling window and storage event triggers need rethinking, and half the linked services point at credentials that must be re-established as Fabric connections.
Input is a Synapse workspace, either its git-backed artifact repository or a live read through the Synapse REST API plus a metadata read against the SQL pools. Output is two things: a classified inventory where every object carries a verdict of auto-convert, convert with review, rebuild by hand or drop, and a set of Fabric-ready artifacts. Every verdict cites the rule that produced it, so the result is auditable rather than a black box.
Enumerates tables, views, stored procedures, functions, external tables, notebooks, Spark job definitions, pipelines, datasets, linked services and triggers, then resolves what depends on what so migration waves can be ordered instead of guessed.
Each object is checked against a rule set covering Fabric Warehouse T-SQL gaps, unsupported data types, collation behaviour, Spark runtime and utility differences, and the Fabric Data Factory activity and connector surface. Every finding names its rule.
DDL and procedural code are rewritten through an abstract syntax tree, not string replacement. Distribution and index clauses are stripped and logged, type mappings are applied with precision loss flagged, and identity and partitioning patterns are replaced with a documented alternative.
mssparkutils calls become notebookutils, ABFSS and mount paths become OneLake paths, linked-service credential lookups become workspace connections, and Spark pool configuration is mapped onto a Fabric environment definition.
Synapse pipeline JSON is re-emitted in Fabric Data Factory shape. Unsupported activities are preserved as annotated stubs carrying the original definition, and integration runtime dependencies are surfaced as gateway or connection decisions rather than dropped.
A per-object breakdown of auto-convert, review and manual-rebuild counts, grouped into waves, that feeds straight into a scoped estimate and a runbook. What stays with a human: the target modelling decision, the security model, orchestration design, Mapping Data Flow rebuilds and performance validation.
Source side is the Synapse REST and workspace git artifact formats plus a metadata read against the SQL pools. Target side is native Fabric, deployed through the Fabric REST API and CLI. T-SQL is parsed with ScriptDom rather than regex, and an LLM pass only drafts the genuinely ambiguous rewrites, which are always marked for review.
Give us a git-backed artifact export or read access to the Synapse workspace. We run the inventory and the compatibility scan and walk through the results with you. You keep the classified object list and the migration wave plan whether or not the engagement goes further.