Fabric Migration Guide for Legacy BI Teams

Is Your Organization Ready for Fabric?

Not every organization should migrate to Fabric today. Before committing budget, assess readiness across five dimensions:

If you score "Not Ready" on three or more dimensions, focus on foundational modernization first — move to Azure, upskill the team, establish governance — before targeting Fabric.

Data Estate Mapping: Know What You Have

Before migrating anything, document your current data estate comprehensively:

• Data sources: Every database, file share, API, SaaS connector, and manual data feed that produces data for your BI environment. Include source system owners and refresh frequencies.
• ETL/ELT pipelines: SSIS packages, Azure Data Factory pipelines, custom scripts, stored procedures, or manual processes that move and transform data. Document dependencies and scheduling.
• Data warehouse: SQL Server databases, Azure SQL, Synapse dedicated pools, or third-party warehouses. Catalog schemas, tables, views, stored procedures, and their consumers.
• Semantic models: SSAS cubes (multidimensional or tabular), Power BI datasets, Cognos Framework Manager models, or BusinessObjects universes. These are your business logic layer and the hardest to migrate.
• Reports and dashboards: SSRS reports, Power BI reports, Cognos reports, or other BI output. Document active usage — reports nobody uses should not be migrated.
• Security model: How access is controlled at each layer — database roles, SSAS roles, Power BI workspace roles, row-level security, and integration with Active Directory / Entra ID.

OneLake Strategy: What Moves, What Stays

OneLake is Fabric's unified storage layer — analogous to OneDrive for data. Every Fabric workspace gets a OneLake location. Your strategy for OneLake should follow this decision framework:

• Move to OneLake: High-value analytical data that is actively queried, data that benefits from Direct Lake mode in Power BI (dramatically faster queries), data that needs unified governance through Microsoft Purview, and data that feeds multiple downstream consumers.
• Shortcut (do not move): Data in existing Azure Data Lake Storage that is infrequently accessed, data in Amazon S3 or Google Cloud that you do not own or control, compliance-constrained data that must remain in a specific geography or storage account, and archival data kept for regulatory retention.
• Leave entirely: Operational databases (OLTP) that are not part of your analytical workload, data already served well by existing pipelines with no performance or governance issues, and data that will be decommissioned within 12 months.

Semantic Model Migration Strategy

Semantic models are the business logic layer — the measures, hierarchies, relationships, and calculations that turn raw data into business meaning. This is the most complex part of Fabric migration:

From SSAS Tabular to Fabric

SSAS tabular models migrate most cleanly to Fabric. Power BI semantic models in Fabric are effectively SSAS tabular models hosted in the cloud. Migration steps:

1. Export the tabular model as a .bim file from SSAS.
2. Import into a Power BI Desktop file or use XMLA endpoint to deploy directly to a Fabric workspace.
3. Update data source connections from on-premises SQL to Fabric Lakehouse/Warehouse.
4. Validate DAX measures, relationships, and hierarchies.
5. Enable Direct Lake mode if the data source is a Fabric Lakehouse (significant performance improvement over Import mode).

From SSAS Multidimensional (OLAP Cubes) to Fabric

This is the hardest migration path. SSAS multidimensional cubes use MDX, not DAX; they support features (writeback, parent-child hierarchies with unary operators, many-to-many dimensions) that do not have direct equivalents in Fabric semantic models. Options:

• Rebuild in DAX: The recommended long-term approach. Rebuild the cube as a Power BI semantic model with DAX measures. Requires significant effort but produces a modern, maintainable model.
• Run in parallel: Keep SSAS multidimensional running for complex cubes while migrating simpler models to Fabric. Phase out cubes as DAX equivalents are validated.
• Use Azure Analysis Services: As a transitional step, move SSAS multidimensional to Azure Analysis Services (which supports both MDX and DAX) while planning the full Fabric migration.

From Non-Microsoft BI to Fabric

Migrating from Cognos, BusinessObjects, Tableau, or Qlik requires rebuilding semantic models from scratch in Power BI/Fabric. There is no automated conversion. The approach:

• Document business logic from existing tool (calculations, filters, hierarchies, security).
• Build the Fabric data pipeline first — get the data into Lakehouse/Warehouse.
• Rebuild the semantic model in Power BI, validating calculations against the legacy system.
• Run both systems in parallel for 30-60 days with matched outputs before decommissioning.

FinOps: Controlling Fabric Costs

Fabric uses a capacity-based pricing model (CU — Capacity Units). Without FinOps discipline, costs can spiral:

• Right-size capacity: Start with F64 (the minimum production SKU at ~$5,003/mo (1-yr reserved)). Scale up only when monitoring shows sustained capacity pressure. Fabric supports capacity scaling (up and down) via API or portal.
• Use smoothing and bursting: Fabric's CU model allows short bursts above purchased capacity, smoothed over time. Optimize batch workloads to run during off-peak hours when burst capacity is available.
• Monitor CU consumption: Use the Fabric Capacity Metrics app (built-in) to track which workspaces, workloads, and users consume the most CUs. Identify and optimize expensive queries.
• Separate dev/test from production: Use lower-tier capacity (F2, F4) for development and testing. Reserve production capacity for production workloads.
• Pause unused capacity: Fabric capacity can be paused (no charges when paused). Set up automation to pause dev/test capacity outside business hours — this alone can cut non-production costs by 60-70%.
• Compare to current costs: Build a TCO comparison: sum all current costs (Synapse, ADF, ADLS, Power BI Premium, SSAS, SSIS server licensing) and compare to projected Fabric capacity costs. Most organizations save 10-25% in steady state.

Security Architecture in Fabric

Fabric security operates at multiple layers, and getting it right requires deliberate design:

• Workspace security: Fabric workspaces use roles (Admin, Member, Contributor, Viewer). Map these to your organizational structure — typically one workspace per department or domain.
• Item-level security: Individual items (lakehouses, warehouses, semantic models, reports) can have granular permissions independent of workspace roles.
• Row-Level Security (RLS): Semantic models support RLS via DAX filters. Use RLS to restrict data visibility by department, region, or business unit.
• OneLake security: Data in OneLake inherits the security model of the workspace and item. Shortcuts inherit the security of the source system — ensure source permissions are appropriate.
• Purview integration: Fabric integrates with Microsoft Purview for sensitivity labeling, data classification, and lineage tracking. Enable this from day one.

Phased Migration Approach

Do not attempt a big-bang Fabric migration. Phase the work by risk and value:

• Phase 1 (Weeks 1-4): Assessment and Architecture — Data estate mapping, readiness assessment, target architecture design, capacity sizing, FinOps baseline.
• Phase 2 (Weeks 5-8): Foundation — Fabric capacity provisioning, workspace structure, security model, Purview integration, CI/CD pipeline setup.
• Phase 3 (Weeks 9-16): Pilot Domain — Migrate one business domain end-to-end: data pipeline, lakehouse/warehouse, semantic model, reports. Validate with business users.
• Phase 4 (Weeks 17-28): Expand — Migrate remaining domains using patterns established in Phase 3. Parallel run with legacy systems.
• Phase 5 (Weeks 29-36): Optimize and Decommission — Performance tuning, FinOps optimization, user training, legacy system decommissioning.

Frequently Asked Questions