Data warehouse consultancy in the UK: what you are actually buying in 2026

A data warehouse engagement is not a warehouse. It is a decision, a build, a semantic model and a way of keeping it alive. What each part looks like in 2026.

The phrase is older than the thing

People still search for a data warehouse consultancy, and the phrase carries a picture: a big SQL database, a team of modellers, a year of work, and a reporting layer at the end. What a UK mid-market business actually buys in 2026 is different in almost every respect except the goal, which is still one governed place where the numbers agree. This post sets out what the engagement contains now, in the order it happens, so you know what you are paying for and what to ask.

Part one: the four weeks before anything is built

The first thing a good consultancy sells you is a decision, not a warehouse. We call it the Establish phase and it takes four weeks. It answers three questions. Which systems hold the data that matters, and how clean is it? Which pattern fits: a Fabric lakehouse, a Fabric warehouse, Azure SQL, or something else? And what will the first three outputs be, so the build has a finish line?

The pattern question is where 2026 differs from 2021. For most mid-market estates the starting point is now a Fabric lakehouse, with a warehouse only where the workload is SQL heavy with complex joins and strict schemas. Our posts on lakehouse or warehouse and data warehouse, data lake or lakehouse go through the trade offs. A consultancy that recommends the pattern before looking at your data is selling what it knows how to build.

Part two: getting the data in

The integration layer used to be most of the cost. It is now the part that has changed most. Business Central mirroring into OneLake was announced at FabCon Europe in October, with public preview expected in a Business Central 29.1 update, and for a Business Central estate it will replace a custom extraction with configuration. Mirroring also now covers SharePoint lists, SQL databases and several cloud sources, and change data feeds handle incremental updates. Where mirroring does not reach, Fabric Data Factory pipelines and Dataflows do, and the ETL, ELT or EtLT question is mostly about where a business rule should live rather than how to move bytes.

What you are buying here is judgement about which of these to use for each source, and the monitoring that tells you when one stops. A pipeline that ran is not the same as data that is right, as our post on pipeline trust explains, and the checks that catch a silent failure are part of the build, not an extra.

Part three: the model that makes the numbers agree

The warehouse itself is a star schema, as it was twenty years ago, because nothing better has arrived for reporting. Customers, products, dates and sites as dimensions; orders, invoices, stock movements and hours as facts; one row per thing, with the business rules for matching a customer across three systems written down and applied once. That design work is the most valuable part of the engagement and the part most often skipped by teams that go straight from source tables to a dashboard.

On top of the schema sits the semantic model, where the measure called Gross Margin is defined once and used by every report. This is where the meaning layer lives, and in 2026 it is also what AI agents read, which is why we treat it as a product rather than a by-product. Fabric IQ and the new ontology features in preview are built on exactly this layer.

Part four: the reports, and the thing after the reports

The first three outputs agreed in the Establish phase get built here, usually in Power BI, and they are deliberately few. A warehouse that goes live with forty reports has forty things nobody owns. Three that finance signs off on are worth more. Design the report before you build it is how we approach that.

Then comes the part most warehouse engagements leave out: what happens in month five. Sources change, capacity needs watching, someone wants a fourth report, a refresh starts failing at 2am. A consultancy that hands over and leaves is selling you a platform that will quietly rot. The alternative is an ongoing arrangement with named people and a monthly rhythm, which is what our Analytics Acceleration Programme is, and what an ongoing data function looks like in practice.

What it costs and how long it takes

For a mid-market business with two to five source systems, the Establish phase is four weeks and the foundational build is ten to sixteen weeks after it. Migrations from an older Synapse or on-premises warehouse add time depending on what is being moved. The platform cost is separate and, since FabCon, can start on an on-demand Fabric capacity with no reservation until you know what you use; our Fabric licensing calculator gives a first view. We quote fixed outcome based phases rather than open ended day rates, for reasons we set out in why we deliver in fixed phases.

What to ask a data warehouse consultancy

Will you decide the pattern before or after looking at our data? Which of our sources would you mirror and which would you pipeline, and why? Where will the business rules live, and who can change them? What are the first three outputs and who signs them off? And who looks after it in month five? The answers tell you whether you are buying a warehouse or a decision, a model and a service, which is what you actually need. Our data platform and warehouse page sets out how we answer each one, and build it in-house or hand it to a partner covers the honest split between the two.

Related reading

Lakehouse or warehouse? The Azure architecture patterns that actually hold up

Data warehouse, data lake or lakehouse: which one your business actually needs

Build it in-house or hand it to a partner: the honest split for a data platform

What an ongoing data function looks like, and why it beats another one-off project