A Quickstart for Measuring the ROI of a Data Lake Build Out

Key Takeaways

• Most data lake business cases lean on the one number nobody can check. "Enables AI" is usually the biggest line on the page and the softest.
• Fund the lake on what you can count. Spend you stop paying, plus hours your team actually gets back, should carry the base case on their own.
• Treat AI use cases as upside. Count them at zero until someone ships one on the lake. If the base case pays back, every one of them is a free option.
• Parallel running is the cost nobody budgets. Every month the old warehouse stays on, you pay twice and your savings line reads zero.
• Write the baseline down before you build. Four numbers, one page, signed by finance. Without them, ROI is a story you tell after the fact.

Every data lake business case I've read has the same line near the bottom. Some version of "enables AI." It's usually the biggest number on the page. It's also the only one nobody can check.

I understand why it's there. The honest case for a lake is boring: you turn some systems off, your analysts stop rebuilding the same extract every Monday, and the platform costs roughly what you planned. The exciting case is that the lake becomes the foundation for every agent and model on the roadmap. Leaders believe the exciting case, and they're mostly right to. IBM's 2025 CEO study found 72% of surveyed CEOs see their organization's proprietary data as key to getting value from generative AI. The same study found those CEOs say only 25% of their AI initiatives delivered the expected ROI over the last few years.

Put those two numbers side by side and you have the problem. Everyone agrees the data is the asset. Very few can show the return on the thing that holds it.

So this is a quickstart. One formula, a one-page worksheet, a worked example with made-up numbers, and a schedule for checking your math after go-live. It's meant for the moment a company decides whether to fund a build, or the moment someone asks whether the build they already funded was worth it. Which metrics to report every month once the lake is running is a separate question. This one is about the investment decision.

The Business Case Should Survive Without AI

A data lake should pay for itself on boring numbers alone.

That sounds like I'm bearish on AI. I'm the opposite. The way I think about it, the AI use cases a lake supports are options. If the base case breaks even without them, every agent and model you ship later is pure upside on a platform that already paid for itself. If the base case only works once you count three AI projects that haven't started, you're betting the whole build on work with no owner, no budget and no date.

The first business case gets funded either way. The second one is the one that gets cut 18 months later, when the AI projects slip and someone asks what the lake actually returned.

Sort every benefit into A, B or C

Before you put a number on anything, sort each expected benefit into one of three buckets.

Bucket A is money that leaves the general ledger. Bucket B is time that gets spent on something else. Bucket C is the reason most people want the lake in the first place, and it stays out of the go/no-go math on purpose.

Write Down the Baseline Before the First File Lands

You can't measure a return against a "before" nobody wrote down. Once the lake is live, memory rewrites history fast. The old warehouse was always slow. The extracts never took that long. Nobody remembers the reconciliation meetings.

Capture four numbers before the build starts. A week is enough.

• What you pay for what the lake replaces. Every system, license, server and data contract, with its annual cost and its renewal date. The renewal date matters because the saving starts when the contract ends, not when the lake goes live.
• Hours spent on data plumbing. Ask your five to ten heaviest data users to log one normal week: time pulling extracts, fixing joins, reconciling numbers between systems. Rough is fine. Consistent is what matters.
• The loaded hourly rate for those people. Salary plus benefits and overhead. Get it from finance so nobody argues about it later.
• The use cases waiting on data. Just the list, with an owner next to each one. No dollar values yet.

If you're running an AI & data readiness assessment before the build, most of this falls out of that work anyway.

Get finance to sign the baseline

Put the four numbers on one page and have someone in finance sign it before the build starts. It feels bureaucratic. It's the cheapest insurance you'll buy on the project, because a year from now nobody can argue about what "before" looked like.

Hours Returned Only Count If Someone Spends Them

This is where most ROI math inflates.

The usual move is to say an analyst saves eight hours a week, multiply by their rate, and call it savings. But those hours never show up on the P&L. Nobody's salary went down. The value is real only if the time goes into something the business would otherwise pay for or go without: a model built in-house instead of contracted out, a forecast that gets refreshed weekly instead of quarterly, a hire you don't need to make.

So I cut the number in half. Hours × loaded rate × 50%. That 50% is a rule of thumb, and I'd rather be honest that it's a judgment call than pretend it's science. Some teams will earn more than half. Some will earn almost none. Pick a haircut, write it down next to the baseline, and keep it the same when you re-measure.

Name where the hours go

For every team that claims time back, write one sentence about what they'll do with it. "The pricing team builds the monthly margin model in-house instead of paying a contractor" counts. "More strategic work" does not. If a team can't write the sentence, give their hours a bigger haircut, or leave them out.

Parallel Running Is the Cost Nobody Budgets

Every migration has an overlap. The new lake is live, and the old warehouse is still on because one board report depends on it, or a team doesn't trust the new numbers yet, or nobody wants to be the person who turned it off. During that overlap you pay for both, and your bucket A savings are zero.

This is the most common way a sound business case goes sideways. McKinsey's survey of nearly 450 CIOs found migration missteps cost the average company 14% more than planned each year, and 38% of companies saw their migrations delayed by more than a quarter. That research covers cloud migrations broadly, not data lakes specifically, and it's from 2021. The mechanics haven't changed. The same report found the companies that hit their timelines were more willing to pull the plug on old data-center funding, even when it meant paying early termination fees.

There's a second cost to letting old systems linger. The IBM study found half of surveyed CEOs say the pace of recent investment left them with disconnected, piecemeal technology. A lake that doesn't turn anything off is just one more piece.

Put a shutoff date on every line in bucket A

Give every system in bucket A a target off date, tied to its renewal. In the worksheet, savings start on that date, not on go-live. When a date slips, the ROI slips with it, and everyone can see it. That visibility is the whole point.

Run the Numbers on One Page

Here's the formula.

Base-case ROI = (A + B − total cost) ÷ total cost

Total cost is the build (design, migration and setup, whether internal or with a partner) plus the run cost over the same period: storage, compute, catalog and tooling, and the time of whoever owns the platform. Payback is the month when cumulative A + B passes cumulative cost.

Use a three-year horizon. A one-year view of a build almost always comes out negative, and that's normal. It tells you nothing except that building things costs money up front.

Try a worked example

These numbers are illustrative. Say a company replaces a legacy warehouse and two data tool licenses that cost $180,000 a year combined, and the contracts end four months after go-live. Six analysts each spend about eight hours a week on plumbing that the lake removes, at a loaded rate of $85 an hour. Hours start counting halfway through year one, once people trust the curated tables. The build costs $350,000 and the platform costs $100,000 a year to run.

Payback lands around month 31. On its own, that's a fine investment. Not an exciting one. That's the point: the lake covers its cost without counting a single AI use case.

Now look at what parallel running does. If the old warehouse stays on eight months longer than planned, bucket A loses $120,000, and the same build comes out around −7% over three years. Same lake, same team, same architecture. One missed shutoff date.

And if the base case had come out at −40%? Then I'd want to know exactly which use case in bucket C was supposed to close the gap, who owns it, and when it ships. Sometimes there's a good answer. Usually there isn't one yet.

Check the Math at 90 Days, Six Months and a Year

An ROI estimate is a forecast. Treat it like one and check it.

• 90 days after go-live: Are the bucket A shutoff dates holding? What's still running in parallel, and why?
• Six months: Ask the same analysts to log the same kind of week. Are plumbing hours actually down? Can each team point to where the time went?
• Twelve months: Re-run the whole worksheet with actuals in place of estimates. Compare it to the signed baseline.

Move use cases from C into actuals only when they ship

A use case counts when it's in production with real users. A pilot demo doesn't count. Neither does a roadmap slide. When one ships, value it from its own measurement and add it to the actuals column. That's the moment the lake starts paying back faster than the base case promised, and it's a much better conversation to have with a board than defending a projection.

Honest Numbers Get Lakes Funded

I'm bullish on data lakes, more so now that nearly every AI project depends on having data in one governed place. A company that gets this right will move faster on whatever comes next.

But I don't have a clean way to value the option a lake creates. The agent you'd never have tried without the documents indexed. The forecast that only became possible once three systems sat side by side. I don't think anyone has a good method for that yet, and I'd be skeptical of a business case that puts a precise figure on it.

What I do trust: a base case that pays back on its own, a baseline signed before the build, and a shutoff date next to every line in bucket A.

If you're scoping a build, start with the four baseline numbers. It takes about a week. We build that worksheet into every Data Lake Build Out, and if you want a second set of eyes on your own numbers, Book a Discovery Call.

FAQ