Dataracity
Telecommunications · USA · Microsoft Fabric

Designing a modern Microsoft Fabric architecture and an executive adoption plan

A blueprint leadership could act on: how the move off on-prem SQL would work, what it would cost, and why Fabric was the right platform to build on.

IndustryTelecommunications
Company51–200 employees
CountryUnited States
FrameworkSTEAM
Results
3Platforms comparedFabric, Synapse, Azure Data Lake
GovernedMedallion designBronze, Silver, and Gold layers
3Adoption phasesReadiness, POV, scale
ApprovedExecutive decisionLeadership backed the move to Fabric
Software used
Microsoft FabricTarget platformSQL Server (on-prem)Source estatePower BISemantic and reporting layer
Related services
The engagement, move by move

From an aging estate to an approved blueprint.

Five design moves, framed by the problem they answered, took the organization from open questions about cost and platform choice to an architecture leadership signed off on. Follow the pipe.

Scroll to walk the design
Where it startedAging on-prem SQL, no blueprint
01
01The challenge · Nothing to build against

An aging on-prem estate, and no architecture to replace it with.

The client needed a clear architectural blueprint for moving from an aging on-prem SQL environment to Microsoft Fabric. The legacy BI estate could not scale for growing data volumes, self-service, or executive reporting.

No modern architecture for cloud scaleLegacy systems past their data-volume ceilingNo self-service environment for analysts
Before · the legacy estateAt its ceiling
On-prem SQL, aging
Data volumes still climbing
No self-service for analysts
TargetA cloud-scale platform
Architecture definedNone yet

The on-prem estate still ran, but it had nowhere left to grow.

02
02The context · What was still unresolved

Nobody could answer what Fabric would cost, or whether it was even the right choice.

Licensing, pricing, and long-term utility usage were unknowns, and it was unclear whether to adopt Fabric or stay with traditional Azure data tools. There was no executive-ready view of a future-state platform to decide against.

Uncertainty on Fabric cost and long-term pricingFabric or traditional Azure tooling — undecidedNo executive-ready future-state picture
Before · open questionsUnresolved
Licensing
Utility usage
Long-term pricing
Fabric or Synapse
Self-service model
Executive view
No future-state picture to approve or reject

Every one of these had to be answered before leadership could commit.

03
03The approach · Designing the target

A Fabric architecture that ingests the on-prem estate at volume.

We led an architecture design engagement aligned to our STEAM framework, defining a future-proof path from on-prem SQL into Fabric — ingestion and processing sized for their big-data volumes rather than their current ones.

Ingestion and processing designed for big-data volumesA defined path from on-prem SQL to FabricSTEAM framework guiding the design
Approach · the Fabric blueprintDesigned for volume
01On-prem SQLSource estate, as it stands
02IngestBig-data volumes, scheduled
03ProcessTransformed inside Fabric
04ServeSemantic layer and Power BI
STEAM framework guiding the design

A defined path from on-prem SQL into a governed Fabric platform.

04
04The approach · An honest comparison

Fabric set side by side with Synapse and Azure Data Lake.

A direct comparison against Azure-based alternatives — Synapse and Azure Data Lake — with the trade-offs stated plainly rather than argued away, so the recommendation could be tested instead of taken on trust.

Fabric, Synapse, and Azure Data Lake compared directlyTrade-offs named, not glossed overA recommendation the BI team could challenge
Approach · platform comparisonTrade-offs named
Option A
Microsoft FabricOne platform, unified governance and self-service
Option B
Azure SynapseFamiliar, but more parts to run and integrate
Option C
Azure Data LakeStorage-first, semantic layer still to build

A recommendation the BI team could test rather than trust.

05
05The approach · Cost, modelled

Compute, storage, and capacity — estimated before committing.

A pricing and utility model set out expected compute, storage, and capacity consumption across pipeline and analytics workloads, turning the largest open question of the engagement into a number leadership could plan against.

Compute, storage, and capacity expectations modelledPipeline and analytics workloads costed separatelyLong-term pricing behaviour made explicit
Approach · pricing and utility modelModelled
Compute capacity expectationsmodelled
Storage growth over timemodelled
Pipeline workloadscosted
Analytics workloadscosted
Long-term pricing behaviour made explicit

Figures are illustrative — the model gave leadership a base to plan against.

06
06The approach · Structure and control

A medallion structure underneath governed self-service.

Bronze, Silver, and Gold layers were mapped to governance and scale, with centralized Power BI semantic models carrying governed self-service on top — alongside security, workspace structure, and CI/CD readiness.

Medallion layers mapped to governance and scaleCentral semantic models for enterprise self-serviceSecurity, workspaces, and CI/CD readiness defined
Approach · medallion and governanceStructured
Bronze
Raw landingOn-prem data as captured
Silver
ConformedCleansed, reconciled, governed
Gold
Semantic modelsCentral Power BI layer for self-service
Security groups, workspace structure, and CI/CD readiness defined

Governed layers underneath, self-service on top.

07
07The solution · Built for the boardroom

An executive presentation and a phased roadmap.

A full executive deck summarized ROI, readiness, and Fabric's long-term value, paired with a phased roadmap — readiness, proof of value, then scale — covering immediate next steps, risks, and expected outcomes.

Executive deck on ROI, readiness, and long-term valuePhased roadmap: readiness, proof of value, scaleRisks and next steps stated up front
Solution · the executive caseBoard ready
Phase 01ReadinessSkills, governance, and platform setup
Phase 02Proof of valueA first workload, measured
Phase 03ScaleWorkloads migrated in sequence
Executive deck: ROI, readiness, long-term value
Risks and next steps stated up front

One picture of the transition, shared by leadership and the BI team.

Where it landedAn approved Fabric architecture and roadmap
We engaged Dataracity to lead the design and recommendation phase of one of our client's enterprise data architecture projects on the Microsoft platform. From the outset their expertise was evident — they introduced us to Microsoft Fabric and provided a robust framework rooted in industry best practices. Beyond high-level strategy, they delivered tangible assets including detailed system architecture diagrams, data flow charts, and comprehensive price modeling. Their technical execution is just as impressive as their strategic planning. I highly recommend Dataracity for any organisation looking to modernise their data stack with precision and clarity.
Shelly JantzenShelly JantzenFounder · E2 Consulting
The people who built it

Team responsible.

A small delivery team, named and accountable from kickoff to go-live.

  • Luke Matthews, Co-Founder, Head of Project Delivery & Data Architecture at Dataracity

    Luke Matthews

    Co-Founder, Head of Project Delivery & Data Architecture

  • Amanda Buthelezi, Co-Founder, Project Lead (BI & Data Strategy) at Dataracity

    Amanda Buthelezi

    Co-Founder, Project Lead (BI & Data Strategy)

How we run architecture engagementsArchitecture leadership, without the full-time hire
Deciding whether Fabric is the right move?

A modernization case is won on the architecture.

Bring us your current estate and the questions leadership keeps asking. We'll come back with the target architecture, the cost model behind it, and the roadmap to get there.

30 minutes No obligation Microsoft Fabric partners