Solution Atlas
EverydayUser storyConsultative playbook

Our old Synapse data warehouse is expensive and the vendor roadmap has shifted

A large retailer's analytics platform runs on Synapse dedicated pools. The pricing is hard to predict, the team has been caught out by capacity bills, and Microsoft's investment has clearly shifted to Fabric. The CDO wants a phased move without disturbing Monday-morning reporting.

Trigger
Renewal in six months; Microsoft has signalled where the roadmap is going.
Good outcome
The retailer is off the expensive dedicated pool by the end of the quarter. Reports come out on time every Monday morning, and the new bill is predictable and lower.
Discovery — signals and questions

Signals validating this story

  • ·Synapse dedicated SQL pool renewal in 6 months
  • ·Pricing surprises on dedicated pool capacity
  • ·Microsoft roadmap signalling Fabric direction reinforced
  • ·Existing ADLS Gen2 estate
  • ·Power BI Premium Per Capacity adjacent to Synapse

Discovery questions

  1. 1.What's your dedicated pool usage profile — peak hours, idle periods?

    WhyIdentifies pause/resume opportunities and migration windows.

  2. 2.Which Synapse workload classes are live — dedicated SQL, serverless, Spark, Pipelines?

    WhySome classes migrate cleanly to Fabric; some need bridge patterns.

  3. 3.How much of your Power BI estate is on Premium Per Capacity today?

    WhyPPC + Fabric F-tier consolidation is often the headline business case.

  4. 4.What's your migration risk appetite — phased per workload or coordinated cutover?

    WhyDetermines programme shape.

  5. 5.What's your renewal date and decision deadline?

    WhySets the timing constraint.

  6. 6.Which downstream consumers depend on Synapse today, and how do they connect?

    WhyIdentifies connection-string changes and consumer-side change management.

Baseline architectureTarget architecture
Baseline architecture

Synapse dedicated SQL pools sized for peak; idle pools paused on weekends. Serverless SQL and Spark mixed in the same workspace. ADLS Gen2 as the storage substrate. Power BI Premium Per Capacity separate from Synapse. Lineage and catalogue partial.

Typical concerns

  • ·Dedicated pool cost variability
  • ·Some workloads under-utilising dedicated capacity
  • ·PPC adjacent but operationally separate
  • ·Some Synapse features (e.g. specific dedicated SQL features) not yet in Fabric
  • ·Lineage informal

Capability gaps

  • ·Capacity-based predictable cost
  • ·Unified storage substrate via OneLake
  • ·Consolidated BI + analytics platform
  • ·Cross-platform lineage
  • ·Migration runbook with phased cutover
Target architecture

Microsoft Fabric F-tier capacity (often F64 to absorb PPC). OneLake unified storage referencing existing ADLS Gen2. Synapse workloads migrated phase-by-phase. Synapse pools wound down workload-by-workload as Fabric absorbs them. Purview Data Governance providing cross-platform lineage during and after migration.

Key capabilities

  • Capacity-based predictable cost
  • OneLake unified substrate
  • Power BI on Fabric capacity
  • Phased migration with no business interruption
  • Continuous lineage through cutover
Architecture decisions
  1. 1.Migration shape — big-bang cutover vs phased per workload

    Big-bang

    Fits whenSmall estate; appetite for coordinated cutover.

    Trade-offsHigher single-point risk.

    Phased

    Fits whenMultiple workloads with different consumers; minimise risk per move.

    Trade-offsTwo platforms running in parallel for months.

    Default recommendationPhased per workload. Run Synapse and Fabric in parallel during migration.

  2. 2.Fabric capacity sizing — F32, F64, or F128

    F32

    Fits whenSmall workload assessment; minimal PPC consolidation; trial scope.

    Trade-offsNo Premium Per Capacity features; another sizing decision in 6 months.

    F64

    Fits whenDirect PPC migration; immediate need for Premium features.

    Trade-offsHigher initial cost if workloads not yet ready.

    F128+

    Fits whenMultiple PPC capacities to consolidate plus heavy Synapse workloads.

    Trade-offsSignificant commitment; size at consolidation point.

    Default recommendationF64 with reserved capacity if migrating from PPC; F32 if trialling only.

  3. 3.Synapse pool retention — keep dedicated pool for specific features vs full retirement

    Keep specific dedicated SQL pool features

    Fits whenWorkloads use features not yet in Fabric Data Warehouse.

    Trade-offsTwo platforms to operate indefinitely.

    Full retirement to Fabric

    Fits whenAll current Synapse workloads map to Fabric capabilities.

    Trade-offsSome refactoring needed for edge cases.

    Default recommendationFull retirement to Fabric unless a hard feature gap blocks a critical workload.

Low-risk trial — proof of value

60-day Fabric F64 + one-workload migration

~8 weeks

Provision Fabric F64 reserved capacity. Migrate one business-priority Synapse workload (lakehouse + Power BI semantic model). Wire Purview Data Governance across Synapse and Fabric during migration. Measure cost and time-to-first-insight before and after.

Success criteria

  • One workload live on Fabric with a certified semantic model
  • Cost delta vs Synapse + PPC modelled at 12 months
  • Lineage demonstrable end-to-end across the cutover
  • Business consumers unaffected during migration

InvestmentFabric F64 reserved capacity. Synapse dedicated pools untouched during trial. Decision on retirement deferred to month 3.

Proof metrics

  • ·Migrated workload at parity or better on response time
  • ·12-month cost projection vs current Synapse + PPC baseline
  • ·Lineage end-to-end through the cutover
  • ·Business interruption zero

Recommended cards

The SKUs and capabilities most likely to be part of the solution, with the editorial rationale for each in the context of this story. Add the ones that fit your situation.

Back to Data warehouse modernisation