"Cloud migrations fail not because of technology. They fail because teams underestimate the complexity of what they are leaving behind, overestimate how quickly they can rebuild it, and forget that the business cannot stop while the platform changes underneath it."
The Scenario — Meridian Financial Services
Meridian Financial Services manages investment portfolios for institutional clients across four countries. Their current data platform:
- Legacy stack: SQL Server 2016 on-premises (20TB), SQL Server Analysis Services (SSAS) tabular models, Power BI Desktop files imported from SSAS, scheduled daily refreshes
- Pain points: SSAS models too large for available RAM (queries slow), daily refresh misses SLA 3 days per month, adding new data sources takes 6-8 weeks (schema change in DWH required), DR is a manual process, IT spends 40% of time on infrastructure
- Migration target: Microsoft Fabric Lakehouse with OneLake, Fabric Spark for ETL, Power BI Direct Lake, Purview governance
- Constraint: Production reports cannot be unavailable during migration. Regulatory reporting continues daily throughout.
The Four Migration Phases
PHASE 1: ASSESS (Weeks 1-4)
─────────────────────────────────────────────────────────────────
Deliverables:
✓ Data inventory: What tables exist, who uses them, how often
✓ Dependency map: Which reports use which SSAS measures/tables
✓ Data quality audit: How many nulls, duplicates, orphaned records
✓ Business criticality: Which reports are regulatory (non-negotiable)
✓ Migration complexity scoring: Simple/Medium/Complex per workload
Key insight from assessment:
- 847 tables in DWH → only 94 actively used in last 12 months
- 312 Power BI reports → only 47 opened in last 90 days
- Migrating everything would take 2x longer than migrating what matters
PHASE 2: PILOT (Weeks 5-12)
─────────────────────────────────────────────────────────────────
Scope: One business domain (portfolio performance — 8 reports, 12 tables)
Goals:
✓ Prove the Fabric architecture works for this specific workload
✓ Validate Direct Lake performance vs SSAS (must be equal or better)
✓ Train the data engineering team on Spark and Dataflow Gen2
✓ Identify governance gaps before they become production problems
✓ Get one real business user to sign off on results
Run OLD and NEW in parallel — compare report outputs row by row
PHASE 3: MIGRATE (Weeks 13-40)
─────────────────────────────────────────────────────────────────
Sequence: Move workloads in order of complexity (simple → complex)
Approach: Wave-based migration (not big-bang)
Wave 1: Simple reports, single-source tables (Weeks 13-20)
Wave 2: Multi-source joined models (Weeks 21-30)
Wave 3: Complex SSAS measures, historical data (Weeks 31-40)
For each wave:
1. Build in Fabric (new platform)
2. Run parallel (old + new) for 2 weeks
3. Business sign-off on equivalence
4. Cutover — redirect users to Fabric report
5. Keep legacy running for 4 weeks (rollback window)
6. Decommission legacy workload after rollback window
PHASE 4: OPTIMISE (Weeks 41-52)
─────────────────────────────────────────────────────────────────
✓ Right-size Fabric capacity based on actual usage data
✓ Delta table optimisation (partitioning, Z-ordering)
✓ Purview data catalogue fully populated
✓ Decommission on-premises SQL Server
✓ Document architecture and runbooks
The Critical Decision — Lift-and-Shift vs Re-Architect
The most consequential decision in any migration: do you replicate the existing architecture in the new platform, or re-architect for the new platform's strengths?
Meridian's decision: Hybrid approach. Lift-and-shift for regulatory reporting (non-negotiable accuracy, no time for re-architecture). Re-architect for operational reporting (more tolerance for change, clear benefit from Direct Lake performance).
MERIDIAN HYBRID APPROACH
LIFT AND SHIFT (regulatory reports — 12 reports)
Old: SQL Server → SSAS Tabular → Power BI Import
New: SQL Server → Fabric Pipeline → Delta table (same schema) → Power BI Direct Lake
Same star schema, same measures in semantic model
Direct Lake replaces Import — no other change
RE-ARCHITECT (operational reports — 35 reports)
Old: SQL Server (flat tables) → SSAS → Power BI Import (slow, daily only)
New: Event stream → Bronze → Silver (cleaned) → Gold (aggregated)
→ Power BI Direct Lake (live, sub-minute freshness)
Completely redesigned data model for Fabric strengths
Common Failure Modes — What Actually Goes Wrong
FAILURE MODE 1: "Big Bang" Migration
─────────────────────────────────────────────────────────────────
What happens: Team decides to migrate everything simultaneously.
All 847 tables, all 312 reports, in one go.
Legacy decommissioned before new platform proven.
Result: Unexpected issues surface only in production.
Business panics. Emergency rollback. Project credibility destroyed.
Prevention: Wave-based migration. Parallel running. Rollback window.
FAILURE MODE 2: Ignoring Data Quality
─────────────────────────────────────────────────────────────────
What happens: Team migrates data as-is from legacy DWH.
Legacy had known issues "fixed" by SSAS calculations.
New Delta tables surface the underlying dirty data.
Reports show different numbers — business rejects migration.
Result: Long forensic investigation. Trust destroyed.
Prevention: Data quality audit in Phase 1. Fix at source in Silver layer.
Run parallel comparison BEFORE cutover.
FAILURE MODE 3: Migrating Unused Workloads
─────────────────────────────────────────────────────────────────
What happens: Team migrates all 847 tables and all 312 reports.
Spends 60% of effort on tables no one has queried in a year.
Result: Timeline doubles. Budget exhausted. Key workloads rushed.
Prevention: Usage analysis in Phase 1. Migrate only active workloads.
Archive (not migrate) the rest.
FAILURE MODE 4: Governance as an Afterthought
─────────────────────────────────────────────────────────────────
What happens: Team builds the Fabric platform first.
Governance (Purview, sensitivity labels, workspace roles)
is planned for "after migration."
Result: Sensitive financial data with no access controls.
Regulatory audit finds compliance gaps.
Remediation after-the-fact is 3x harder.
Prevention: Governance configured in Phase 1, before any data lands.
Common Misconceptions
- "Migration is a one-time project that ends" — Migration is a program that transitions into operations. Phase 4 (Optimise) is ongoing — capacity right-sizing, Delta table maintenance (OPTIMIZE, VACUUM commands), and governance refinement continue for 12-18 months after go-live.
- "Direct Lake will automatically be faster than SSAS Import" — Direct Lake eliminates the refresh cycle but query performance depends on Delta table optimisation. An unpartitioned, unoptimised Delta table may initially perform similarly to SSAS Import. The performance advantage comes after OPTIMIZE and partitioning are applied in Phase 4.
- "We can migrate the schema exactly and Power BI will work the same" — Power BI semantic models built for Import mode may need adjustment for Direct Lake. Calculated tables (not supported in Direct Lake) must be converted to calculated columns or views. This is a planned re-work item, not a surprise.
- "The business will not notice the difference" — Business users notice everything. Report formatting changes, filter behaviour differences, slightly different aggregation results from rounding differences — all will be flagged. Parallel running with business sign-off before cutover is non-negotiable.
🎯 Quick Check
Q1: Meridian's assessment found 847 tables in the DWH but only 94 actively used in the last 12 months. What should happen to the other 753 tables?
Show Answer
Archive, not migrate. Migrating 753 unused tables wastes project budget and timeline. The correct approach: archive raw data to low-cost OneLake storage (cold tier) for compliance retention purposes, but do not build active Fabric pipelines or semantic models for them. If a business user requests one of these historical tables in the future, it can be reactivated from archive. Migrating unused workloads is one of the most common reasons migrations go over budget.
Q2: A financial services migration team wants to cut over regulatory reports to the new Fabric platform. What process should they follow before decommissioning the legacy SSAS model?
Show Answer
Parallel running with row-by-row comparison and business sign-off, then a 4-week rollback window. Run both old and new reports simultaneously for 2 weeks. Compare outputs — every number must match. Get written sign-off from the compliance team that results are equivalent. Cut over user access to Fabric reports. Keep legacy SSAS running (but not user-facing) for 4 weeks as rollback option. Only decommission SSAS after the rollback window with no issues reported.
Q3: After migrating to Fabric, a team notices their Direct Lake reports are not significantly faster than their old Import mode reports. What is the most likely cause?
Show Answer
Delta table not optimised — missing partitioning and OPTIMIZE/Z-ORDER. Direct Lake reads Delta tables directly from OneLake. If those tables are not partitioned by query-relevant columns and not compacted (OPTIMIZE command consolidates small files), query performance will be similar to reading unoptimised flat files. Run OPTIMIZE on the Delta tables, add appropriate partitioning by date or region, then re-test. Phase 4 (Optimise) of the migration addresses exactly this.
Key Takeaways — Part 7
- Cloud migration follows four phases: Assess, Pilot, Migrate, Optimise — skipping Phase 1 (Assess) is the most common cause of failed migrations
- Migrate only what is actively used — usage analysis in Phase 1 routinely finds 70-80% of legacy workloads unused in the last 12 months
- Lift-and-shift reduces risk but preserves technical debt; re-architecture is harder but delivers full platform benefits — a hybrid approach is often optimal
- Parallel running with business sign-off before cutover is non-negotiable — especially for regulatory reporting
- Governance must be configured before any data lands — retrofitting governance after migration is significantly more expensive and risky