What an Operational Data Platform Costs Over Three Years

Every operational data platform proposal you receive will be wrong about the total cost, and it will be wrong in the same direction: too low. Not because vendors lie, but because the largest line item never appears on a vendor quote. It sits inside your own organisation, in the effort to fix the source data before the platform can trust it. This study builds the whole three-year picture: what you pay to build, what you pay to run, and what you pay whether or not anyone puts it in the plan.

BUILD: what you pay to stand it up

The build is the one-off cost to get from nothing to a platform that produces trusted numbers. It is the part vendors quote most confidently and, ironically, the part that varies least. Six activities make it up, and skipping any one of them just moves the cost to later.

• Discovery. Deciding what questions the platform must answer and which source systems feed them. Typically 8 to 15 percent of build. Underspend here and everything downstream costs more.
• Data modelling. Designing the semantic layer: the shared definitions of an asset, a work order, a cost, a site. This is the asset you reuse for a decade, so it earns its 15 to 20 percent.
• Pipeline development. Extracting from source systems and landing clean, conformed data. The single biggest slice, 25 to 35 percent, and the one that balloons when source data is messy.
• Report development. The dashboards and models the business actually sees. Deceptively small at 12 to 18 percent, because a good semantic model does most of the work.
• Testing. Reconciling platform numbers back to source, so finance trusts them. 10 to 15 percent, and the first thing cut under pressure, always to regret.
• Training. Getting people to use it instead of the old spreadsheet. 5 to 10 percent, and the difference between adoption and a very expensive report nobody opens.

If you are still choosing the tool that feeds this pipeline layer, my write-up on choosing an ETL tool for a one-person data team covers the trade-offs that most affect build cost.

RUN: what you pay every year after

The run cost is where three-year models diverge from launch-day thinking. A platform is not a project you finish; it is a service you operate. Four things recur.

• Cloud consumption. Compute and storage for refreshes, queries and models. On a capacity-based platform like Fabric this is a reserved capacity you size and can flex. Get sizing wrong in either direction and you either throttle users or burn budget. My Fabric capacity sizing and cost piece walks the sizing maths in detail.
• Licences. Per-user seats for the reporting layer, plus any source-connector or governance tooling. Predictable, but it scales with adoption, which is the outcome you wanted.
• Support. Someone keeps pipelines running when a source system changes a field or a refresh fails at 3am. Whether internal or retained, budget it explicitly.
• Enhancement backlog. The requests that arrive the week after launch. A platform that gets used generates demand for more. Fund a modest, continuous stream rather than pretending the build was the end.

Across three years, run cost commonly lands between 40 and 70 percent of the original build cost in total. A useful planning rule: annual run is roughly 15 to 25 percent of build, every year.

HIDDEN: what nobody puts in the plan

Here is where the model earns its keep. Three costs are real, large, and almost never in a proposal because they land on your side of the fence.

The point is not to scare you off. It is that a business case built only on the vendor quote is understated by a factor that, on messy estates, can approach two. Name these costs and you keep the CFO's trust when they surface later, because they will.

The three-year model, three estate sizes

Below is the modelled range for three representative estates. Read every figure as a range with the assumptions stated beneath, not as a quote. Your region, your data quality and your scope will move these materially.

Assumptions: blended day rates 600 to 1,200 USD; a capacity-based lakehouse platform (Fabric or equivalent); one delivery partner plus a small internal team; three to six connected source systems scaling with estate; internal time loaded at fully-costed salary. Ranges widen with poor source-data quality, regulatory scope and real-time demands. Price your own cloud and licence lines against the Azure pricing calculator and Microsoft Fabric pricing .

Worked example: the line item everyone ignores

Take the 40-building portfolio. The vendor quote for build lands at, say, 190k. Clean, defensible, and what goes into the board pack. Now look at what has to happen for that platform to produce a number finance will sign.

The asset register across those 40 buildings holds around 22,000 records. On a typical estate, 15 to 25 percent carry a defect that breaks reporting: a duplicate, a missing cost centre, a site typed as free text rather than a code, a category that means three different things in three regions. Call it 4,400 records needing a human decision. At a genuine, unhurried rate of 40 records reviewed and corrected per person-day, that is 110 person-days. At a loaded internal rate of 450 USD per day, the cleansing effort alone is roughly 50k, and that is before you count the analyst time to find the defects and the manager time to approve the fixes.

There is a silver lining worth stating plainly: the cleansing is not wasted platform money, it is a permanent improvement to the operational systems themselves. The register is cleaner in the source, not just in a dashboard. Framed that way, the CFO sees an investment in data quality that happens to be triggered by the platform, not a hidden overrun.

What actually reduces the cost

Three levers move the total more than any tooling choice or day-rate negotiation. All three are decisions about scope and discipline, not technology.

• Narrow scope to three decisions. (20 to 35 percent lower build.) Do not build a platform that answers everything. Build one that answers the three decisions the business will actually make differently: where to spend maintenance budget, which sites are underperforming, which assets to replace. Every report beyond those three is cost with no committed action behind it.
• Reuse the semantic model. (15 to 25 percent lower over three years.) The shared definitions built once should feed every new report without remodelling. Teams that rebuild the model per report pay for it repeatedly. Treat the semantic layer as the durable asset it is; my Microsoft Fabric adoption roadmap sequences this so reuse compounds instead of eroding.
• Refuse real-time nobody will act on. (10 to 20 percent lower run.) Someone always asks for live data. Ask back: what will you do in the next hour with a number that changes every minute? If the honest answer is nothing, a daily or hourly refresh is fine, and it can cut cloud consumption sharply. Real-time is a genuine requirement for a handful of operational alerts and an expensive vanity everywhere else.

The business case a CFO will sign

CFOs reject business cases built on speculative savings, and they are right to. "This platform will save us 500k a year" invites the question no one can answer: how, exactly, and who will be accountable for banking it? Anchor the case on two things a CFO already respects instead.

• Avoided cost, with an owner. Not hypothetical efficiency, but specific spend you stop: the manual reporting effort you retire, the consultant reconciliations you no longer commission, the duplicate licence you cancel once one source of truth exists. Each with a named owner who agrees to the number.
• Decision quality, made concrete. The value of replacing an asset a year later because you finally have the reliability data, or of catching an underperforming site a quarter sooner. State it as a decision made better, not a saving guaranteed.
• Full cost, honestly staged. Present build, run and hidden as three lines, with the cleansing effort visible. A CFO trusts a number that includes its own uncomfortable parts far more than a clean one that unravels in year two.

The structure that gets approved reads: here is the total three-year cost including the internal effort we will invest in our own data; here is the spend we stop; here are the three decisions we will make measurably better; here is the owner for each. That is a case about discipline, not optimism, and discipline is the language finance signs in.

Conclusion and independence

An operational data platform is not expensive because of the software. It is expensive because trustworthy data has a price, and most of that price lands inside your organisation rather than on a vendor invoice. Model all three layers, put the hidden costs on the page yourself, narrow the scope to decisions people will actually make, and anchor the CFO case on avoided cost and decision quality. Do that and the number is defensible, even when it is larger than the quote you started with.

Independence note: I sell integration and data-platform delivery, so I have an interest in these projects going ahead. I have tried to counter that here by putting the costs that damage a business case, not just the benefits, in front of you. No vendor sponsored this study, and the figures are my own modelled ranges, not anyone's price list. Verified as of 1 August 2026; day rates and cloud pricing change, so re-price before you present.