The five questions to ask before starting a data modernization engagement

Every data modernization project starts with good intentions — a new platform, cleaner pipelines, “finally getting our data house in order.” And every one of those projects has a version that stalls six months in, over budget, with half the org still exporting to Excel because nobody asked the hard questions up front.

Before you greenlight a modernization engagement, here are the five questions I think actually matter — not the technical checklist, but the ones that determine whether this thing succeeds or quietly becomes a cautionary tale in next year’s budget review.

1. What business objective is actually driving this?

This sounds obvious, and it’s the one people skip fastest. “Modernize our data platform” is not an objective — it’s a project name. The real objective is underneath it: are you doing this to cut infrastructure cost, to speed up reporting, to pass a compliance audit, to enable AI use cases you can’t currently support?

Each of those points to a different scope, a different sequence of work, and a different definition of success. A modernization driven by cost reduction looks nothing like one driven by “we want to run AI on this data next year.” If you can’t state the objective in one sentence that a non-technical stakeholder would nod along to, you’re not ready to scope the engagement yet — you’re ready to have that conversation first.

2. Have you actually diagnosed the problem, or are you assuming the fix?

A lot of modernization engagements start from a conclusion, not a diagnosis. Someone decided “we need a new platform” before anyone mapped out where the current pain actually lives — is it the infrastructure, the data quality, the lack of governance, or just that nobody trusts the numbers anymore?

Those are different problems with different solutions, and a new platform doesn’t fix bad data any more than a new house fixes a bad foundation. Before scoping the engagement, get honest about root cause. Sometimes the answer really is “we need modern infrastructure.” Sometimes the infrastructure is fine and the real issue is that three teams define “active customer” three different ways. Modernizing the platform won’t fix that second problem — it’ll just give you the same argument on faster hardware.

3. Is your data foundation actually ready — datasets, platform, and governance?

This is where the technical readiness question lives, and it’s really three questions in one:

Datasets — Have you identified which datasets actually need to move, and which ones are ready to move as-is versus which need cleanup first? Not everything in your current environment deserves a seat in the new one.

Platform — Is the target platform actually suited to what you’re trying to do, or is this modernization more “lift and shift” than genuine improvement? A new platform under the same old governance problems doesn’t solve anything — it just moves the mess to a nicer-looking building.

Governance — This is the one I’d push hardest on, and it’s often the one skipped. You can’t put a roof on a house without a solid foundation — it will come crashing down. Same logic here. If your data doesn’t have clear ownership, clean quality, and traceable lineage, modernizing the platform underneath it doesn’t fix any of that. It just gives the same ungoverned data a faster home. Get governance right during the engagement — not as a phase-two afterthought — and everything built on top of the new platform actually holds up.

If your answer to any of these three is “not yet, but we’ll figure it out during the project” — that’s not necessarily a dealbreaker, but it needs to be scoped and budgeted for explicitly, not assumed to happen for free alongside the “real” work.

4. Who’s going to use the modernized data, and how?

Modernization projects are often designed around the data, not the people using it. Before you start, get specific: who are the actual users — analysts running reports, data scientists training models, executives wanting a dashboard, or increasingly, AI systems querying data directly and taking action on it?

Each of those has a different bar for accuracy, access control, and oversight. A dashboard a human double-checks before presenting has a different risk profile than an AI agent making decisions off the same data with no one in the loop. If you don’t define usage up front, you tend to build a platform optimized for the use case someone happened to be thinking about, and everyone else adapts around it later — usually not well.

5. What’s the realistic timeline, budget, and organizational appetite for this?

This is where good modernization projects quietly die, and it’s rarely a technical death — it’s a patience death. Data modernization is not a quarter-long project in most organizations; it’s often 12-18 months of real work once you factor in migration, validation, and change management. If the budget and timeline in the room don’t match that reality, you’re not scoping a project — you’re setting up a future postmortem.

I’ve lived this one directly. I worked on a project scoped small on paper — a modest budget, six months, “should be straightforward.” From the start, I pushed back to the project sponsor: this was a much bigger undertaking than the scope suggested. The number of reports involved, the state of the underlying data, a data warehouse that wasn’t fully built out for consumers yet, dependencies that hadn’t been resolved — none of it lined up with a six-month estimate. I said plainly: we can’t do this in this timeframe, we need to mitigate the dependencies first.

The sponsor didn’t want to hear it. His answer was that this was really just a POC — build the one report first, worry about the rest later.

Here’s what that “one report” actually involved once we got into it: every report in scope lived in Excel, pulled from a legacy data warehouse through an Excel plugin — slow, and with zero documentation on what any of it was actually doing. The logic existed only in the heads of the business users, and there wasn’t one owner — there were multiple, each with their own way of building these reports. When I actually sat down to do the assessment, it became clear the original estimate had been done at a high level only. No one had assessed the complexity or the type of data the reports would actually need.

I raised the alarm again. The response was to ask for more budget and bring in a team to help build it — not to revisit the timeline or the assumptions underneath it. Meanwhile, the data itself wasn’t even ready. There were real gaps, and the data projects meant to fill those gaps for the sources we needed were still in flight. None of this had been planned for.

Eventually, new data leadership came in and did what should have happened at the start — introduced a real governance layer, assigned actual data owners, and put a process in place so the business had to submit requests against a roadmap instead of just asking and getting whatever, whenever.

That project, originally scoped at six months, took eight to complete — and even then, only by constantly applying band-aid fixes to keep it moving. That’s the trade-off you make when there’s no data strategy or structure going in and the plan is just “do the project, we have X budget allocated.” It gets done. But those band-aids don’t hold forever, and eventually they fall off.

The real lesson wasn’t about the timeline slipping two months — it was that nobody had the appetite to hear “this needs more time” until the alternative was throwing more budget at the same flawed plan. Modernization efforts that survive tend to have a sponsor willing to defend the disruption up front. The ones that don’t end up paying for it later, just in a less visible way.

In summary, none of these questions are about technology. They’re about clarity — on objective, on root cause, on foundation, on audience, and on what the organization is actually willing to commit to. Skip them, and you’ll still get a modernization project. You just might not get a successful one.

Vrajesh Patel

Author

Follow us on