Microsoft Fabric
Your first Fabric pipelines worked. Keeping the rest consistent is the hard part.
A metadata-driven way to build and run Microsoft Fabric.
Most data platforms on Fabric start clean and drift fast — every new source built a little differently, onboarding slowing to a crawl, run costs creeping up. Our Fabric Data Framework takes a different route: describe your sources and rules once, and a single engine builds every pipeline the same way.
Book a Fabric Foundation AssessmentThe metadata-driven model
Inside your own OneLake, with lineage and naming built in
The pattern we see
Hand-built Fabric platforms drift — quietly and expensively.
It rarely fails loudly. The first few pipelines get built by whoever’s free, under deadline. They work. Then the next wave arrives, built slightly differently by different people, and six months in no two look alike. Here’s where that lands most teams.
No two pipelines alike
Each was built to its own pattern, so nobody can say why one differs from the next. Debugging means reading the code every time, and the people who know it become the only ones who can touch it.
New sources take weeks
Adding a data source means another build from scratch — design, code, test, document. What should be routine turns into a small project every time, and the backlog of requests keeps growing.
Run costs keep climbing
With nothing standard underneath, there’s nothing standard to tune. Compute creeps up, capacity gets over-provisioned to be safe, and the platform quietly costs more to run each quarter than anyone planned for.
How it works
Describe the platform once. Let the framework build it.
Metadata simply means configuration — a set of tables that describe your sources, your targets, and the rules for moving data between them. Instead of hand-coding each pipeline, a single engine reads that configuration and builds them for you.
Adding a source becomes a configuration change, not a new build. And because every pipeline comes from the same engine, they all behave the same way — which is what makes the platform predictable to run and cheap to extend.
Configuration, not code
Sources and processing rules live in metadata tables your team can read and change — no hunting through bespoke scripts.
One engine, every pipeline
The same engine builds and runs each pipeline, so behaviour is consistent and a fix in one place applies everywhere.
Bronze, Silver, Gold enforced
The medallion structure in OneLake is built in, not left to good intentions — raw, cleansed, and modelled layers, every time.
Lineage and naming built in
Because the engine generates everything, lineage and naming are consistent by default — which is what makes governance and audit straightforward later.
One place to see what’s running
A monitoring console shows pipeline health, failures and alerts in one view — so whoever’s responsible for the platform knows what needs attention without reading through logs.
What changes for your team
Consistency by design, not by discipline.
Standards written in a wiki get followed until the next deadline. When the standard is the engine, consistency holds whether or not anyone’s looking. That shift shows up in four places.
Consistency by design
Every pipeline built the same way, because they all come from the same engine.
Sources in days, not weeks
Onboarding a new source becomes a configuration change, not a build project.
Lower build and run cost
Less bespoke code to write, far less to maintain, and a standard pattern you can actually tune.
Governance baked in
Lineage, naming and structure enforced by the framework — ready for audit and for AI.
Two ways to build on Fabric
The same platform, built two ways.
Both get you to a working Fabric platform. The difference shows up six months in, when the platform has to grow and someone has to keep running it.
| Hand-built pipelines | Framework-led build | |
|---|---|---|
| Onboarding a new source | Weeks — design, code, test and document each time | Days — add the source to configuration |
| Consistency across pipelines | Varies by who built it and when | Identical — one engine builds them all |
| Cost to maintain and run | Creeps up — nothing standard to tune | Controlled — optimise once, applies everywhere |
| Governance and lineage | Bolted on after the fact, if at all | Built in from the first pipeline |
| Who can run it | A few key people who hold the knowledge | Your wider team — change configuration, not code |
| Readiness for AI | Hard to trust — inconsistent, unclear lineage | A reliable foundation for Copilot and Azure AI Foundry |
The framework runs on standard Microsoft Fabric underneath — your workspaces, your OneLake, your tenancy. The difference is how the platform is built and operated, not what it’s built on.
How we work with you
Start small, prove it, then run it together.
You don’t have to commit to a full rebuild to find out whether this fits. We start with a short, low-risk assessment, prove the approach on real sources, then stay on as much or as little as you want.
Fabric Foundation Assessment
We review your current Fabric estate — or your migration plan — map your sources, and show where a metadata-driven framework saves the most time and cost. You leave with a concrete plan, whether or not you build it with us.
Framework build
We stand up the framework and bring your first sources onto it, so you see real pipelines running the standard way. Existing pipelines move onto the pattern progressively — no big-bang rebuild.
Run it together
Keep growing the platform with your own team, with us on hand for the heavier work — or hand day-to-day operation to our managed service. Your call, and it can change over time.
What the relationship looks like after go-live
Most clients keep us on through our Modern Data Platform managed service: a fortnightly cadence for adding sources and enhancements, a named data lead who knows your platform, monthly reviews of cost and performance, and active monitoring so issues surface before your business does. Adding a source is a configuration change we make together — not a project you have to fund and schedule each time. When you’d rather run it in-house, our Data Team as a Service covers the busy periods. The framework is documented and yours to keep either way.
Find out what a consistent Fabric platform would take.
Start with a Fabric Foundation Assessment — a short, fixed-fee engagement that reviews where you are now, maps your sources, and shows where a metadata-driven framework would save the most time and cost. You leave with a concrete plan you can act on with us or on your own.
No obligation. A working session with our data engineers, not a sales pitch.Book your assessment
Frequently Asked Questions
Common questions about building on Microsoft Fabric.
Metadata simply means configuration. Instead of hand-coding each data pipeline, you describe your sources, targets, and the rules for moving data between them in a set of configuration tables. A single engine reads that configuration and builds and runs every pipeline from it. The result is that every pipeline is built the same way, because they all come from the same engine rather than from whoever happened to be free that week.
No. Most of the platforms we work with are already part-built. The framework can take over new source onboarding from where you are now, and existing pipelines can be brought onto the standard pattern progressively rather than rebuilt all at once. The Fabric Foundation Assessment is designed to look at what you already have and show where the framework adds the most value first.
Microsoft’s templates and FastTrack guidance help you stand up Fabric and follow good architecture. They are a starting point, not a running platform. The framework is the operating layer that sits on top: it builds and runs your pipelines from configuration day to day, enforces the medallion structure and naming, and turns adding a new source into a configuration change rather than a new build. The two work together.
The platform underneath is standard Microsoft Fabric — your workspaces, your OneLake, your pipelines, all inside your own tenancy. The framework is documented and handed over, and your own data engineers can run and extend it. Many clients move to running it themselves, with us available for the heavier work. You should be able to walk away from us and keep operating; that is the test we hold the work to.
Copilot, Copilot Studio and Azure AI Foundry are only as good as the data underneath them. An inconsistent, poorly governed data estate is the most common reason AI work stalls or produces answers no one trusts. A consistent Fabric platform with clear lineage gives those AI tools something reliable to draw on. For many organisations, the fastest route to useful AI runs through the data foundation first.
Data platform and migration work on Fabric is a Microsoft priority, and there are Microsoft co-funding programmes that can offset assessment and build costs for eligible organisations. We will tell you honestly what your engagement is likely to qualify for and handle the Microsoft-side process. We confirm the specific programmes and amounts as part of the assessment, because the available funding changes each financial year.
The framework includes a monitoring console that shows pipeline health, failures and alerts in one place, so the person responsible for the platform can see what needs attention without digging through logs. Because every pipeline runs through the same engine, monitoring is consistent across all of them rather than something that has to be wired up source by source.
Yes, if you want us to. Our Modern Data Platform managed service runs the platform with you — monitoring, incident response, capacity management, and a fortnightly cadence for adding sources and enhancements. Some clients run it entirely in-house and call on our Data Team as a Service for the busy periods. Either way, the build is the start of the relationship, not the end of it.