Migrating from Synapse to Fabric collapses Synapse’s granular RBAC roles into Fabric’s four workspace roles, and Microsoft’s own Spark Migration Assistant moves only Spark pools, notebooks, job definitions and lake databases, not configs, custom libraries, Hive Metastore functions, or glossary terms. Atlan, the context layer connected to both Synapse and Fabric concurrently, closes that gap: it keeps definitions, owners and lineage visible through the cutover regardless of what the migration tooling has moved yet.
Time to complete: Varies with estate size. Allow 1-2 weeks of verification work layered onto
Microsoft's migration timeline, not a standalone project.
Difficulty level: Intermediate to advanced. Requires admin access to both platforms during the
coexistence window.
Prerequisites: Admin access to Synapse and Fabric; a Spark Migration Assistant run already scoped
or in progress; visibility into any external Hive Metastore; a list of glossary and definition
sources outside Hive Metastore (Purview Unified Catalog or elsewhere).
Tools needed: Fabric's Spark Migration Assistant, OneLake Catalog's Govern tab, Microsoft's
post-migration checklist, and a context layer connected to both platforms for cross-platform
continuity during the window.
Why does a Synapse to Fabric migration put metadata, lineage and definitions at risk?
The risk is not a Fabric defect. It is what happens when two platforms with different role systems, metadata stores and pipeline formats run side by side, confirmed by Microsoft’s own documentation at every phase of the move.
Microsoft’s migration series is thorough on mechanics but structured phase by phase: RBAC in one document, Hive Metastore in another, pipeline recreation in a third. Reading one phase at a time means cross-phase gaps are easy to miss until a job fails or a report shows the wrong owner after cutover. Naming every gap up front turns a scattered discovery process into a checklist you can run before and during the coexistence window, catching drift while it’s still reversible.
This matters most for architects and data leaders whose business definitions live partly in Purview’s Unified Catalog or a separate glossary tool, not only in Hive Metastore. Step 5 covers the deeper lineage mechanism that applies once Power BI reports sit downstream: column-level lineage for Power BI. Atlan’s comparison of Microsoft Fabric and Azure Synapse covers the architecture-level differences; what follows goes deeper on metadata, lineage and definitions specifically. The same coexistence pattern holds when the source system is Snowflake rather than Synapse: see Snowflake to Fabric migration: keeping lineage intact for the parallel case. Migrations that treat the cutover as a single event, not a coexistence period (Step 6), are the ones most likely to lose that continuity.
What you need before you start verifying continuity
A self-qualification checklist, not a project plan: verification work layered onto Microsoft’s own migration timeline.
Organizational prerequisites:
- A named owner for metadata and lineage continuity, distinct from the migration project lead.
- Executive awareness that this is a coexistence window, not a single event.
Technical prerequisites:
- Admin access to both Synapse and Fabric workspaces for the duration of the window.
- A completed or in-progress Spark Migration Assistant run to audit against.
- Knowledge of whether Synapse uses an external Hive Metastore (Azure SQL Database or MySQL), which has no Fabric equivalent, covered in Step 3.
- An inventory of where business definitions actually live: Hive Metastore column comments, Purview’s Unified Catalog, or elsewhere.
Time commitment: Budget one to two weeks of dedicated verification time, running in parallel with Microsoft’s own migration phases, more if an external Hive Metastore or a large glossary is involved. Treat this as an ongoing business context layer, not a one-time check. Skip that, and the same gaps tend to resurface weeks after cutover, feeding straight into the Microsoft Fabric governance hub this checklist supports.
Step 1: Inventory what the Spark Migration Assistant actually moves
What you’ll accomplish: A before/after list of what the Spark Migration Assistant moves automatically. Time required: one to two days for a mid-size estate.
Why this step matters: Teams that assume the assistant is comprehensive discover gaps only when a job fails post-cutover.
How to do it:
- Pull the assistant’s documented scope. Per Microsoft Learn (2026), it migrates Spark pools, notebooks, job definitions and lake databases only, not data itself; configs, custom libraries and executor settings are excluded, so reconfigure those by hand.
- Cross-check Hive Metastore functions separately. Per Microsoft Learn (2026), functions aren’t included in the current migration scripts at all.
- Flag Synapse pipelines and linked services for manual recreation; Step 5 covers the no-bulk-import rule and the rebuild process in full.
What actually moves vs. what you rebuild by hand
| Component | Migrates automatically | What you do manually | Source |
|---|---|---|---|
| Spark pools, notebooks, job definitions, lake databases | Yes (metadata and definitions only, not data) | Verify post-migration against this table | Spark Migration Assistant doc |
| Spark configs, custom libraries, executor settings | No | Reconfigure in Fabric | Spark Migration Assistant doc |
| Hive Metastore functions | No | Recreate manually | Hive Metastore migration doc |
| Managed tables (Hive Metastore) | Converted to external on import | Review table-type assumptions in downstream jobs | Hive Metastore migration doc |
| External Hive Metastore (Azure SQL DB or MySQL) | No equivalent in Fabric | Manually recreate the metadata it held | Hive Metastore migration doc |
| Synapse linked services and pipelines | No | Recreate as Fabric Connections and pipelines by hand | Fabric Community forum; security-validation-cutover doc |
Validation checklist: Everything the Spark Migration Assistant run touched, including custom libraries and executor settings needing manual recreation, matched against the table above, and confirmation of whether Synapse uses an external Hive Metastore.
Common mistakes: Assuming “migration assistant” means a full lift-and-shift. Verify against the table, not assumption, the same caution automated SQL lineage versus manual lineage mapping and DataHub’s OpenLineage support both apply.
Step 2: Map Synapse’s RBAC roles onto Fabric’s four workspace roles
What you’ll accomplish: A clear view of how Synapse’s granular roles fold into Fabric’s four workspace roles (Admin, Member, Contributor, Viewer). Time required: half a day to a day, depending on how many custom role assignments exist today.
Why this step matters: Per Microsoft Learn (2026), Synapse RBAC roles, including Synapse Administrator, Synapse SQL Administrator, and Synapse Spark Administrator, map to Fabric’s four workspace roles, and “Fabric’s model is simpler with four roles.” Simpler also means coarser.
How to do it:
- Pull checklist item 5.1 (“map Synapse RBAC roles to Fabric workspace roles”) as the starting point. Microsoft confirms the collapse happens but doesn’t publish a row-by-row mapping, so don’t improvise one. Review each account’s actual assigned role individually.
- Flag every collapse that widens access. Anyone moving into a broader Fabric tier than their narrower Synapse role held should be reviewed before cutover.
- State plainly: Atlan’s Fabric and Power BI connectors are read-only on access, and don’t write role or permission changes back to Synapse or Fabric. A context layer can surface which accounts widened or narrowed, but the access decision stays a genuinely open operational step for the team, not something it automates.
Fabric’s four workspace roles
| Fabric workspace role | What it grants in Fabric |
|---|---|
| Admin | Full control: workspace settings, permissions, connections, and all content |
| Member | Edit and publish content, manage some workspace settings |
| Contributor | Create and edit content, no workspace-level settings access |
| Viewer | Read-only access to content; general report and lineage visibility only, covered in Step 5 |
Microsoft doesn’t publish which specific Synapse role lands in which Fabric tier, so don’t infer a mapping from this table, including for roles tied to master data management workflows. Decide each account’s Fabric tier individually.
Validation checklist:
- Every Synapse role in use today has a documented Fabric-role decision, and every access widening from the collapse has been explicitly reviewed.
- Confirmed: no tool in this process writes access changes back to source systems automatically.
Common mistakes: Treating the four-role model as a 1:1 rename. Review each collapse for an access-scope change, the same discipline Reltio’s approach to definitions surviving a platform move applies on the master-data side.
Step 3: Export and validate Hive Metastore metadata before cutover
What you’ll accomplish: Confirm what the Hive Metastore export actually captured, and what it silently changed, before trusting it in Fabric. Time required: one to three days depending on catalog size.
Why this step matters: Two documented behaviors catch teams off guard: managed tables silently becoming external on import, and post-export schema changes not propagating automatically.
How to do it:
- Re-run or confirm the Hive Metastore export timestamp against the last schema change in Synapse. Per Microsoft Learn (2026), new tables or schema changes made in Synapse’s HMS after export “won’t propagate automatically”, so anything added after that point needs a fresh export or manual reconciliation.
- Check table-type assumptions downstream. Per the same guidance, all managed tables are converted to external tables during import, so anything that assumed managed-table behavior, like a
DROP TABLEdeleting underlying files, now behaves differently. - If an external Hive Metastore was in use (Azure SQL Database or Azure Database for MySQL), treat it as a from-scratch rebuild, not a migration. Fabric has no equivalent, and external Hive Metastore support in Synapse itself is deprecated after Spark 3.4.
Validation checklist: Hive Metastore export re-verified against the current Synapse schema state, managed-table-dependent logic reviewed for the external-table conversion, and any external Hive Metastore has a documented manual-rebuild plan.
Common mistakes: Trusting a single export as permanently in sync with Synapse. Re-verify it before cutover, the same point graph database versus metadata layer makes about any store that isn’t continuously read. Synapse data discovery covers what lives in Synapse before export; Airflow’s OpenLineage integration shows a comparable pattern.
Step 4: Do Purview glossary terms carry over automatically? Keep business definitions separate from the Hive Metastore move
The correction: Microsoft Purview does have a glossary-migration tool, but it solves an unrelated problem, the single most likely wrong turn a reader takes here. It moves classic glossary terms into Purview’s own Unified Catalog, a Purview-internal upgrade. Per Microsoft Learn, it’s for “migrating classic glossary terms and enabling asset curation” inside Purview itself, nothing to do with a Synapse-to-Fabric cutover. A reader searching how to keep their definitions when migrating to Fabric won’t find the answer there.
The real gap: none of Microsoft’s Synapse-to-Fabric migration scripts touch column or table descriptions, business glossary terms, or ownership metadata living in Purview’s Unified Catalog or a separate tool. That’s a different metadata surface than Hive Metastore, which Step 3 covers, and Microsoft’s migration documentation is silent on it by omission across the series. Where Purview’s own governance reach stops matters here too, since definitions sitting just outside that boundary still need their own continuity plan: see Microsoft Purview data governance coverage: where it stops.
Practical implication: if business definitions live in Hive Metastore column comments, they follow Hive Metastore’s own rules from Step 3, including the managed-to-external conversion risk. If they live in Purview or elsewhere, they need their own explicit continuity plan, run in parallel with Step 5’s pipeline rebuild, not after it. Teams still deciding whether to keep Purview running in parallel, extend it, or step back from it for this surface can work through Atlan’s coexist, extend or replace framework for Purview before committing to a plan.
A context layer connected to both platforms reads business context, ownership, descriptions and certified terms, from wherever it actually lives, regardless of which migration script has run. State plainly: this is not a migration of Purview’s glossary into Atlan or Fabric. No one-click import exists. Atlan connects through its own connectors and open APIs, reading metadata rather than moving it, the same distinction data contracts draw as the enforceable form of a definition, and the same ground business context layer, business context for AI and the context layer glossary cover. Teams whose Synapse estate carries its own business glossary can go deeper at Synapse business glossary.
Common mistakes: Assuming Purview’s glossary-migration tool answers “keeping definitions when migrating to Fabric.” Recognize it as a Purview-internal upgrade instead, and plan definition continuity as its own workstream.
Step 5: Rebuild pipelines and reconnect lineage across both platforms
What you’ll accomplish: Recreate Synapse pipelines in Fabric Data Factory manually, and confirm which lineage mechanism applies when Power BI reports sit downstream. Time required: varies by pipeline count; plan for a multi-day rebuild, not an import.
Why this step matters: Unlike some other Microsoft migration paths, a Fabric Community forum thread confirms that you cannot mount or import an entire Synapse workspace’s pipelines into Fabric, corroborated by Microsoft’s own comparison documentation listing Synapse pipelines and Fabric Data Factory pipelines as distinct, non-mapped item types.
How to do it:
- Inventory every Synapse pipeline and linked service, and rebuild each as a Fabric pipeline and Fabric Connection. There is no bulk-import path.
- Verify lineage for anything feeding Power BI using the correct mechanism; don’t conflate the two. Fabric connector lineage covers the general Semantic Model to Report to Page/Visual path and needs only Viewer with the Scanner API disabled. Power BI connector lineage reaches deeper, to column and measure level, and needs Contributor or higher; Viewer produces none. See Atlan’s proof-of-value checklist for what to test first.
- Re-run the post-migration lineage-review checklist item. Microsoft’s item 5.5 instructs teams to “verify that migrated items appear in OneLake Catalog and review their lineage,” a manual step, not a guarantee.
The two Fabric and Power BI lineage mechanisms
| Lineage type | Connector | Minimum role required | What you get |
|---|---|---|---|
| Semantic Model to Report to Page or Visual (general case) | Fabric connector | Viewer role or higher, with the Scanner API disabled | Downstream lineage from semantic models through report pages and visuals |
| Column or Measure to Report Page (deeper, column-level) | Power BI connector | Contributor role or higher; Viewer produces no lineage | Column- and measure-level lineage down to a specific report page |
Validation checklist: Every Synapse pipeline has a confirmed Fabric equivalent built manually, the correct lineage mechanism is identified for each downstream Power BI use case, and OneLake Catalog checklist item 5.5 is completed, not assumed.
Common mistakes: Expecting Power BI column-level lineage with only Viewer access. Confirm Contributor or higher for column and measure lineage specifically, a distinction MCP for data lineage and lineage root-cause analysis with MCP both treat as a first-class fact, not an implementation detail.
Step 6: Treat the migration window as a coexistence period, not a single cutover event
What you’ll accomplish: A standing process for catching metadata drift between Synapse and Fabric for as long as both run in parallel, not a one-time checklist. Time required: ongoing, for the duration of the coexistence window.
Why this step matters: Microsoft’s own Hive Metastore documentation admits new tables or schema changes made in Synapse after the export won’t propagate automatically. The window itself is a drift risk, and OneLake Catalog’s Govern tab only sees items already inside Fabric.
How to do it:
- Set a cadence for re-running Hive Metastore export and reconciliation for as long as Synapse is still live and changing.
- Complete the full post-migration checklist, including item 5.6: “review and apply sensitivity labels to migrated Lakehouse items as needed”; Purview Information Protection labels don’t carry over automatically either, a drift risk comparable to the one change data capture catches on the data side, and the same posture Synapse data compliance establishes before migration even starts.
- Keep a cross-platform view open during the window. A context layer connected to both platforms catches drift as it happens, not at the next scheduled re-export, the same reasoning behind treating a semantic layer as a living system.
Validation checklist: A defined end date (or explicit decision to keep running both platforms), sensitivity labels reviewed and reapplied per checklist item 5.6, and a standing owner assigned for metadata drift.
Common mistakes: Treating cutover day as done. Plan for an ongoing coexistence window with its own drift-monitoring cadence. The same question recurs once Fabric data agents start reading this data: see questions to ask about governing Fabric AI agents and who governs agent-created Fabric items.
What breaks most often in a Synapse to Fabric migration?
The same five failure points recur across real migrations, and no single Microsoft page assembles them into one view:
- RBAC access-scope changes from the four-role collapse (Step 2).
- Hive Metastore functions excluded, and managed-to-external table conversion (Step 3).
- The Purview-glossary red herring (Step 4).
- Pipelines and linked services with no bulk-import path (Step 5).
- Metadata drift during the coexistence window (Step 6).
Each is recoverable if caught before a report or downstream job depends on it.
Best practices for keeping continuity through the cutover
Verify, don’t assume, every automated-migration claim, against the Step 1 table.
Separate the RBAC conversation from the metadata conversation, the same separation data catalog versus master data management draws between access and definitions.
Treat business definitions as a distinct migration workstream. Whether they live in Hive Metastore column comments or Purview’s Unified Catalog, they need an explicit plan, not confidence borrowed from Purview’s glossary-migration tool.
Confirm the correct lineage mechanism before reporting lineage complete. General lineage needs only Viewer; column and measure lineage needs Contributor or higher, and MCP delivering business context to downstream agents depends on getting this right first.
Plan for an open-ended coexistence window, not a single cutover date, the same framing context layer versus data catalog versus semantic layer applies underneath it.
How does a context layer keep definitions and lineage visible across Synapse and Fabric during the migration?
Everything in Steps 1 through 6 holds regardless of vendor. A team relying only on native tooling has to assemble that continuity itself, piece by piece.
Atlan is built to connect to Synapse and Fabric side by side, so it isn’t waiting on Microsoft’s migration tooling to decide when continuity happens. It reads both platforms concurrently and keeps ownership, descriptions, certified terms and lineage visible regardless of which Spark items, pipelines or tables the native assistant has touched. A recommended crawl order, sources, then quality, then pipelines, then transformations, then BI, keeps lineage from breaking as the estate moves in phases, the same sequencing what is context engineering and how to implement an enterprise context layer for AI walk through. State plainly: this does not migrate Purview’s glossary or Synapse’s metadata into Atlan or Fabric, there is no one-click import or bulk-export utility, and Atlan reads metadata, not business data, never Spark code or pipelines, a boundary the enterprise context layer concept depends on staying explicit about.
A mid-market account mid-migration from Synapse to Fabric, described here by segment only, raised exactly this question: whether metadata enriched in Synapse could carry into Fabric instead of being rebuilt from scratch. No public, named case study exists yet, and none is implied here.
Is a Synapse to Fabric migration a single event, or a coexistence period?
For most estates, it runs as a coexistence period measured in weeks to months, not a single cutover weekend, something Microsoft’s own phased migration series assumes throughout. Once the Spark Migration Assistant run, Hive Metastore export, RBAC mapping, pipeline rebuild and definitions plan from Steps 1 through 6 are verified, the next checkpoint is re-running the lineage-review checklist item for as long as both platforms stay live.
Measure success by whether metadata drift gets caught before it reaches a report or downstream job, not by a single migration-complete date. That holds whether the estate is small enough for a context graph to cover end to end, or an AI-ready data lineage baseline is already in place. Building an AI agent harness that reads trustworthy context, not stale metadata, depends on this continuity surviving the cutover.
FAQs about Synapse to Fabric migration continuity
1. Does Microsoft Purview migrate our glossary terms when we move from Synapse to Fabric?
No. Purview’s glossary-migration tool moves classic glossary terms into Purview’s own Unified Catalog, which is a Purview-internal upgrade unrelated to a Synapse-to-Fabric cutover. Business definitions tied to Synapse need their own continuity plan, separate from that tool.
2. What does the Fabric Spark Migration Assistant actually migrate?
Spark pools, notebooks, Spark job definitions, and lake databases only. It doesn’t move data itself, and it excludes Spark configurations, custom libraries, and executor settings, which must be reconfigured manually in Fabric.
3. Does Fabric support an external Hive Metastore?
No. Synapse workspaces using Azure SQL Database or Azure Database for MySQL as an external Hive Metastore have no Fabric equivalent to connect to. That metadata must be manually recreated.
4. How do Synapse RBAC roles map to Fabric workspace roles?
Synapse’s granular roles, including Synapse Administrator, Synapse SQL Administrator, and Synapse Spark Administrator, collapse into Fabric’s four workspace roles: Admin, Member, Contributor, and Viewer. Review every collapse for access-scope widening before cutover.
5. Can Synapse pipelines be imported directly into Fabric Data Factory?
No. Unlike some other Microsoft migration paths, you cannot mount or import an entire Synapse workspace’s pipelines into Fabric. Pipelines and linked services must be recreated manually.
6. Is a Synapse to Fabric migration a one-time event?
No. It typically runs as a coexistence period where both platforms operate in parallel for weeks or months, during which metadata can drift unless it is actively reconciled.
Sources
- Overview of migrating Azure Synapse Spark to Fabric, Microsoft Learn
- Migrate Hive Metastore metadata and data paths to Fabric, Microsoft Learn
- Complete Synapse to Fabric migration with security, validation, and cutover, Microsoft Learn
- Migrate Spark workloads from Azure Synapse Analytics to Microsoft Fabric, Microsoft Learn
- Compare Fabric and Azure Synapse Spark: Key Differences, Microsoft Learn
- Migration Strategy and Planning for Azure Synapse Dedicated SQL pools to Fabric, Microsoft Learn
- OneLake catalog overview, Microsoft Learn
- Migration of pipelines from Azure Synapse to Microsoft Fabric, Microsoft Fabric Community forum
- What lineage does Atlan extract from Microsoft Fabric, docs.atlan.com
- Generate Power BI columns, measures and pages lineage, docs.atlan.com
- Migrate classic glossary terms and enable asset curation, Microsoft Purview, Microsoft Learn
