Solution Atlas
EverydayUser storyConsultative playbook

We have data sprawl across three legacy systems and need one platform

A CDO has inherited a stack that includes legacy Synapse pools, ad-hoc Databricks workspaces, and a Power BI tenant with no governance. The board wants one platform for the next five years and a clear path from "many tools" to "one trustworthy substrate".

Trigger
Board sponsorship; consolidation budget approved.
Good outcome
Fabric as the anchor, OneLake unified storage, Purview as the governance plane, Power BI on Fabric capacity.
Diagnostic discovery

Signals this story fits

Observable cues that confirm the conversation belongs here.

  • ·Multiple analytical platforms running in parallel (Synapse + Databricks + Power BI Premium) with no shared catalogue
  • ·Data-team backlog growing; business teams building shadow analytics
  • ·Power BI capacity costs surprising; Fabric capacity not yet evaluated
  • ·A board-level analytics or AI initiative with no clear data substrate
  • ·No tenant-wide data catalogue or lineage discipline

Questions to ask

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

  1. 1.What does your current analytical landscape look like — which platforms are live where?

    WhyEstablishes the baseline. Surfaces sprawl signals (multiple compute engines, multiple catalogues).

  2. 2.Who owns the question "is this number correct?" today?

    WhySurfaces governance maturity. If nobody owns it, the platform decision is downstream of the governance decision.

  3. 3.What is your most expensive analytics workload, and what drives the cost?

    WhyOften the consolidation business case. Synapse dedicated pools, Power BI Premium Per Capacity, and idle Databricks all show up here.

  4. 4.How long does it take a new data product to land in production today?

    WhySurfaces the cost of the status quo in business terms.

    Listen for: “six weeks” · “we don't really track it” · “depends on the team”

  5. 5.Are there any non-Microsoft platform commitments you would not unwind in the next 18 months?

    WhyDetermines whether the answer is "Fabric anchor + coexistence" or "Fabric anchor + retirement plan".

  6. 6.What does board success look like for this programme — productivity, cost, AI readiness?

    WhyAnchors the North Star and determines which capabilities to prioritise in the target architecture.

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

A mix of Synapse dedicated SQL pools, ad-hoc Databricks workspaces, and a Power BI Premium tenant. Storage scattered across ADLS Gen2 buckets per team. No central catalogue; data quality signals informal. Cost allocation by subscription, not by data product.

Typical concerns

  • ·Surprising Synapse and Power BI Premium bills
  • ·Reports that contradict each other across teams
  • ·Shadow Databricks workspaces outside platform team visibility
  • ·No tenant-wide lineage or audit trail
  • ·Slow time to first insight for new business questions

Capability gaps

  • ·Unified storage substrate (OneLake)
  • ·Cross-platform data catalogue and lineage
  • ·Data products with named owners
  • ·Capacity-based cost model with predictability
  • ·Self-service governance — workspaces, certifications
Target architecture

Microsoft Fabric as the strategic anchor on top of ADLS Gen2 / OneLake. Power BI on Fabric capacity (eliminating Power BI Premium Per Capacity). Purview Data Governance as the federation catalogue across Fabric, any remaining Databricks, and any Snowflake. Synapse dedicated pools wound down workload-by-workload. Data products with named owners as the maturity threshold.

Key capabilities

  • OneLake unified storage substrate
  • Capacity-based predictable cost (Fabric F-tier with reservations)
  • Purview Data Governance — catalogue + lineage
  • Data products with named owners
  • Self-service BI on certified semantic models

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.Platform stance — Fabric anchor only vs Fabric + Databricks coexistence

    Fabric anchor only

    When it fitsMicrosoft-first estate; ML workloads modest; team is comfortable on Spark-in-Fabric.

    Trade-offsMosaic AI / Databricks ML maturity left on the table.

    Fabric + Databricks coexistence

    When it fitsSubstantial existing Databricks investment; ML/AI is strategic.

    Trade-offsTwo governance planes to federate via Purview; cost of running two platforms.

    Default recommendationCoexistence for organisations with >5 active Databricks workspaces or strategic ML investment; Fabric-only otherwise.

  2. Decision 2.Fabric capacity sizing — start F32 or F64?

    F32

    When it fitsInitial workload assessment; willing to upgrade in phase 2.

    Trade-offsPower BI Premium features unavailable; another capacity decision in six months.

    F64

    When it fitsDirect migration from Power BI Premium Per Capacity; immediate need for Premium features.

    Trade-offsHigher initial cost if workloads are not yet ready.

    Default recommendationF64 with reserved capacity when migrating from PPC; F32 if greenfield with smaller workloads.

Low-risk trial — proof of value

45-day Modern Data Platform discovery + one workload on Fabric

6 weeks

Estate assessment across Synapse / Databricks / Power BI. Cost-allocation baseline. F32 capacity provisioned. One business-priority workload migrated to Fabric (lakehouse + Power BI semantic model). Purview Data Governance enabled across the new workload.

Success criteria

  • Estate report with current and projected cost across analytics platforms
  • One workload live on Fabric with a certified semantic model
  • Purview catalogue populated for the migrated workload with lineage
  • Time-to-first-insight measured before and after for the trial workload

InvestmentF32 reserved capacity ~€1.6k / month + advisory engagement. Larger commitments deferred until estate report findings.

Proof metrics

  • ·Time-to-first-insight reduced by 50%+ on the trial workload
  • ·Power BI dataset count reduction by 30%+ via certified semantic model adoption
  • ·Lineage end-to-end demonstrable for the migrated workload
  • ·Total cost of the migrated workload modelled at 12 months

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 strategic platform anchor. OneLake unifies storage; capacity-based pricing replaces Power BI Premium Per Capacity; one commercial commitment covers Engineering, Warehouse, and BI.

Why for this story

The storage substrate beneath OneLake. Decisions here outlast every compute decision above — format, tiering, and lifecycle policy travel forward through every platform iteration.

Why for this story

The federation catalogue across Fabric, Databricks, and Snowflake. Governance must lead, not lag — without this, the migration produces a faster sprawl, not a governed estate.

Why for this story

The consumption layer. Moving Power BI workspaces onto Fabric capacity eliminates Premium Per Capacity and aligns BI cost with the rest of the data platform.

Back to Modern data platform