• 03 Aug 2026

Microsoft Fabric Migration Services: Assessment, Conversion, and Validation

Migrating to Fabric is not a lift-and-shift. Even Microsoft's own migration guidance frames it as an opportunity to refactor pipelines, standardize governance, and re-express workloads on a shared lake, which means the work is part conversion and part redesign. Knowing which parts are which, before you start, is what keeps a migration predictable.

Key Takeaways

• Fabric migration is refactoring, not lift-and-shift. Pipelines, code, and semantic models are re-expressed, and security is re-implemented.
• Microsoft's Fabric Migration Assistant automates many tasks for Microsoft-native sources, even using AI to fix schema compatibility errors, but non-Microsoft tools must be rebuilt by hand.
• SSAS and Azure Analysis Services offer a dedicated path for migrating to Fabric semantic models, with server redirection support during the transition.
• A newer assistant covers on-prem SQL Server specifically (in preview), distinct from the Synapse-focused warehouse assistant.
• Validation is a required phase, not a formality; running in parallel and reconciling outputs against the source is what Microsoft's own runbook centers on.

What Are Fabric Migration Services?

Fabric migration services are the assessment, conversion, and validation work required to re-platform data, pipelines, semantic models, and reports onto Microsoft Fabric: re-hosting warehouses on Microsoft Fabric Warehouse or Lakehouse, rebuilding ETL as Data Factory pipelines or notebooks, consolidating storage into OneLake, migrating semantic models off SSAS or Azure Analysis Services, and modernizing reporting on Power BI with Direct Lake.

Common source platforms include Azure Synapse Analytics, Azure Data Factory, on-premises SQL Server, SSAS, Azure Analysis Services, Alteryx, Tableau, standalone Power BI Premium, and warehouses such as Oracle and Teradata. If your priority is the broader advisory relationship, architecture decisions, ongoing governance, and capacity planning, rather than the migration event itself, see our companion page on Microsoft Fabric Consulting Services.

Why Are Organizations Migrating to Microsoft Fabric?

• Platform consolidation: Fabric unifies data engineering, integration, warehousing, real-time intelligence, and Power BI into a single platform.
• One copy of data: OneLake keeps a single copy in open Delta format, ending duplicate extracts and warehouse copies.
• Simplified licensing: a single capacity-based F-SKU replaces per-service or per-seat billing.
• Governance and lineage: one Entra ID and Purview model for access control, sensitivity labels, and lineage.
• AI readiness: Copilot and Fabric data agents sit on the same governed data.

When to consider it: you already run Power BI and Azure, costs are climbing, or governance and scale limits are becoming a problem. This holds regardless of industry: healthcare, financial services, retail, manufacturing - the mechanics don't change, though the compliance configuration on top does.

What Can You Migrate to Fabric?

Legacy Analytics Stack vs. Microsoft Fabric

How Are Source Objects Mapped to Fabric?

What Converts Automatically vs. Requires Manual Effort?

Assisted by Microsoft tooling:

• Fabric Assessment Tool: scans a Synapse workspace and inventories objects before you start.
• Data Warehouse Migration Assistant: automates schema, code, and data migration from Synapse SQL pools to Fabric Warehouse, using AI to fix schema compatibility errors.
• Fabric Migration Assistant for SQL Database (preview): moves schema and data from on-prem SQL Server into a Fabric SQL database.
• Spark Migration Assistant: moves Synapse Spark notebooks, job definitions, and Hive metadata into Fabric Data Engineering.
• Migrate to Fabric for pipelines: mounts ADF and Synapse pipelines into Fabric workspaces, with linked services mapped to connections.
• SSAS/Azure Analysis Services migration: extracts tabular/multidimensional models into semantic models, translating DAX/MDX logic. Server-redirection keeps reports working during transition, but must be explicitly disabled before decommissioning the original AAS server, a real, easy-to-miss step.

Requires manual refactoring: linked-service-to-connection mapping, hard-coded file paths, unsupported APIs, credentials, and row- and column-level security. Logic from non-Microsoft tools, Alteryx macros, Tableau calculated fields, SSIS script tasks, is rebuilt rather than converted.

Common blockers: unsupported runtimes, undocumented business logic, embedded credentials, and connectivity to non-Microsoft systems are what most often stall a migration, which is why assessment comes before conversion.

What Are the Main Migration Challenges?

• It is not lift-and-shift. Pipelines and code need refactoring, assuming a straight copy is the most common early mistake.
• Undocumented logic. Estates built over years encode rules nobody wrote down; discovery has to capture intent, not just objects.
• Connectivity and credentials. On-prem and non-Microsoft sources need gateways and re-mapped connections and credentials.
• Security re-implementation. Row- and column-level security and permissions are re-expressed in Fabric rather than automatically carried over.
• Version control adoption. Fabric expects Git and Azure DevOps; teams need new habits around branches and deployment pipelines.
• Validation effort. Confirming outputs match is routinely underestimated; it's a required phase, not a formality. This is exactly where our Reports Conversion team's output-validation discipline applies directly.

How Do You Validate a Fabric Migration?

Validation is what earns the business's trust in the new platform. Microsoft's own runbook centers on running the two environments side by side and comparing results:

• Run in parallel. Keep the source running alongside Fabric so any drift surfaces before cutover.
• Reconcile outputs. Compare row counts, key aggregates, and value-level samples between source and target for every migrated object.
• Test the consumers. Point BI platforms and query tools at Fabric and confirm reports and queries return the same results.
• Benchmark and sign off. Benchmark query performance, review governance, and have owners sign off before switching, keeping a rollback path available.

Migration Readiness and Timing

Who should migrate now: organizations on Synapse, Azure Data Factory, or SSAS/Azure Analysis Services, where Microsoft is actively providing migration assistants, plus Power BI-heavy teams and anyone under pressure to consolidate cost and governance.

Who should wait: teams that depend on capabilities without a proven Fabric equivalent, groups without cloud or Fabric skills and no budget to build them, and estates mid-way through another major change where timing would add risk.

Fabric vs. Databricks or Snowflake: this isn't strictly an either/or in most cases; Databricks and Snowflake solve overlapping but distinct problems (deep Spark/ML flexibility and multi-cloud portability, respectively) versus Fabric's unified, SaaS-managed, single-licensing model. Organizations already invested in the Microsoft ecosystem (Synapse, ADF, Power BI, SSAS) generally see a clearer migration path and faster time-to-value when moving to Fabric specifically, since much of that estate already has a named, assisted conversion path.

When migration is not recommended: if critical workloads rely on unsupported features without a redesign plan, or if a migration is attempted without assessment, validation, and enablement, it's better to plan first than to force a move that erodes trust in the data.

What Is the Recommended Migration Approach?

• Assess: run the Fabric Assessment Tool and inventory every object, pipeline, report, semantic model, dependency, and schedule, capturing the business logic behind them.
• Plan: choose an approach, lift-and-shift, phased modernization, or parallel run - and account for rollback and synchronization constraints.
• Build the foundation: stand up Fabric capacity, OneLake/Lakehouse, connections, and governance before migrating anything.
• Migrate in waves: use the Microsoft assistants where they fit, refactor linked services, paths, and unsupported APIs, rebuild non-Microsoft logic by hand.
• Validate: reconcile outputs against the source and run in parallel until owners sign off.
• Cut over and enable: switch reporting to Fabric with a rollback path, set up Git/CI-CD and monitoring, retire redundant objects (including disabling AAS server redirection before decommissioning), and train the team.

Best practices: assess before you convert, since the inventory and scope drive every downstream decision; map linked services to connections early; refactor only what breaks, not what already works; and treat validation before cutover as a gate, not an afterthought.

Enterprise Considerations

• Security and RBAC: Entra ID with workspace roles, item permissions, and OneLake security; re-implement row/column-level security explicitly.
• Governance and lineage: Purview for sensitivity labels, cataloging, and end-to-end lineage.
• Performance: right-size capacity, use Direct Lake for Power BI, and design partitioning for large tables, the same tuning discipline our BI Products team applies once dashboards are rebuilt on the new platform.
• Scalability: scale F-SKU capacity and Spark pools to demand rather than upgrading single services.
• Monitoring: the Fabric monitoring hub and pipeline run history for observability and alerting.
• CI/CD: Git integration and deployment pipelines to promote changes across dev, test, and production.
• Disaster recovery: plan OneLake data resilience and capacity failover in line with recovery objectives.

A Typical Fabric Migration Scenario

Consider a common scenario: A data team runs an Azure Synapse dedicated SQL pool for its warehouse, a set of ADF pipelines for ingestion, a few Synapse Spark notebooks, an SSAS tabular model that powers executive dashboards, and a large Power BI estate that imports from the warehouse. Storage sits in ADLS Gen2, and reporting refreshes are slow and duplicative.

Before: ADF loads the SQL pool nightly, Spark notebooks run transformations, SSAS serves the semantic layer, and Power BI imports the results.

After: the SQL pool is migrated to a Fabric Warehouse with the Data Warehouse Migration Assistant; ADF pipelines move to Fabric Data Factory with linked services re-mapped as connections; Spark notebooks move with the Spark Migration Assistant; the SSAS tabular model is extracted and rebuilt as a Fabric semantic model with DAX logic preserved; ADLS data is pointed at OneLake; and Power BI switches to Direct Lake against the Lakehouse. Each migrated object is reconciled with the source, and the two run in parallel for a cycle before the schedule switches to Fabric.

Case Study: Alteryx to Microsoft Fabric

A global enterprise client came to DataTerrain facing escalating Alteryx license costs that were limiting both user count and overall spend. They needed a corporate-approved alternative that could scale across the organization without that licensing burden, while keeping every existing workflow intact.

DataTerrain's automated migration tools converted the client's Alteryx workflows and Power BI reports to Microsoft Fabric Flow and Power BI, with full feature retention and no disruption to daily operations. The conversion was fully automated end-to-end, requiring minimal client input and allowing their team to stay focused on business priorities rather than managing the migration itself. Delivered under a fixed-cost model, the migration cost was recouped within the first year through reduced licensing fees alone, with all savings beyond that flowing straight to the client's bottom line. The client confirmed that all features worked post-migration correctly, and the relationship has since expanded to include additional migrations for the same organization.

See the full Alteryx to Microsoft Fabric Flow and Power BI customer story for the complete write-up. Organizations migrating from Oracle-based reporting instead can see a closely related walkthrough in our Oracle to Microsoft Fabric Migration piece.

Timeline, Cost, and Required Skills

• Timeline: driven by object count and complexity. Azure-native sources with assistant support move faster; heavy custom logic, SSAS calculation complexity, and non-Microsoft tools take longer. A phased plan delivers value in waves, and assessment sets a realistic schedule.
• Manual effort: proportional to refactoring, connections, paths, unsupported APIs, security, plus any non-Microsoft tool logic. Assistants reduce the rebuild work; validation is always hands-on.
• Prerequisites: a sized Fabric capacity and workspace, OneLake/Lakehouse set up, source connectivity or gateways, and a complete object inventory from the assessment.
• Licensing: Fabric's capacity-based F-SKU replaces per-service or per-seat costs; the TCO comparison is often a primary reason to migrate.
• Skills: SQL and Power Query, PySpark, Data Factory, Power BI and DAX modeling, and Git/DevOps. Enablement for the existing team should be built into the plan, the same enablement standard our Legacy Scripts modernization work follows.
• Risks: recurring risks include underestimating validation effort, missing undocumented business logic during discovery, and failing to plan for the AAS server-redirection cleanup step when a semantic model migration is involved.

Planning a Migration to Microsoft Fabric?

Whether you're on Synapse, SSAS, Azure Data Factory, or a mix of Microsoft and non-Microsoft tools, DataTerrain assesses your source estate, maps every object and semantic model to its Fabric equivalent, migrates in phased waves using Microsoft's assistants where they fit, and validates each output against the source before cutover. This is the same as any to-any BI automation approach that's carried us through 400+ client engagements over 17 years, handling assessment, migration planning, implementation, testing, and ongoing support as a single continuous engagement rather than a series of handoffs.

Ask about a migration assessment →

Frequently Asked Questions

Related Reading

Microsoft Fabric Consulting Services   |   Oracle to Microsoft Fabric Migration   |   Migrating from Alteryx to Microsoft Fabric   |   ETL Migration Solutions

References:

• Overview of migrating Azure Synapse Spark to Fabric
• Migrate Synapse dedicated SQL pools to Fabric Warehouse
• Migration planning: Azure Data Factory to Fabric Data Factory
• Fabric Migration Assistant for SQL database
• Fabric Assessment Tool (fabric-toolbox)
• OneLake overview