Solution Atlas
EverydayUser storyConsultative playbook

Our Synapse dedicated pool is expensive and the roadmap has shifted

A large retailer's analytics platform sits on dedicated Synapse SQL pools. Pricing is opaque, the team has had several capacity surprises, and Microsoft's investment has clearly moved to Fabric. The CDO wants a phased migration without disrupting Monday-morning reporting.

Trigger
Renewal due in six months; Microsoft roadmap signals reinforced.
Good outcome
Workload-by-workload migration to Fabric, dedicated pool wound down by quarter, reporting uninterrupted.
Diagnostic discovery

Signals this story fits

Observable cues that confirm the conversation belongs here.

  • ·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

Questions to ask

Open-ended, SPIN-style — each one has a reason it matters.

  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 → target architecture

TOGAF-style gap framing — what we typically see today, and what the proposed end state looks like. The gap between them is the engagement.

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

Enabling SKUs

Resolved in the ‘Recommended cards’ section below.

Architecture decisions

Each decision is offered as explicit options with trade-offs — Hohpe's “selling options” principle. A safe default is noted where one exists.

  1. Decision 1.Migration shape — big-bang cutover vs phased per workload

    Big-bang

    When it fitsSmall estate; appetite for coordinated cutover.

    Trade-offsHigher single-point risk.

    Phased

    When it fitsMultiple 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. Decision 2.Fabric capacity sizing — F32, F64, or F128

    F32

    When it fitsSmall workload assessment; minimal PPC consolidation; trial scope.

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

    F64

    When it fitsDirect PPC migration; immediate need for Premium features.

    Trade-offsHigher initial cost if workloads not yet ready.

    F128+

    When it fitsMultiple 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. Decision 3.Synapse pool retention — keep dedicated pool for specific features vs full retirement

    Keep specific dedicated SQL pool features

    When it fitsWorkloads use features not yet in Fabric Data Warehouse.

    Trade-offsTwo platforms to operate indefinitely.

    Full retirement to Fabric

    When it fitsAll 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.

Why for this story

The legacy platform being retired. Some workload classes (dedicated SQL pools) may stay during transition; the rest migrate to Fabric.

Why for this story

The strategic successor. Capacity-based pricing absorbs Power BI Premium Per Capacity. OneLake unifies storage.

Why for this story

Storage substrate — Fabric OneLake mounts and references existing ADLS. Existing investment travels forward.

Why for this story

Governance plane that spans Synapse during migration and Fabric after. Lineage must be continuous through the cutover.

Back to Data warehouse modernisation