Why a modern data foundation takes more than a new platform

Too many data modernization efforts begin with the platform. The conversation turns to replacing the underlying data environment, moving reporting workloads to the cloud or retiring legacy tooling. Those decisions matter, but in my experience, they are rarely what makes the work hard.

What makes the work hard is everything that has built up around the platform over time.

I have seen this most often in organizations that inherited legacy architecture through acquisition, accumulated technical debt through years of deferred investment or saw reporting logic and master data evolve without enough enterprise discipline. On the surface, the environment may still appear functional. Dashboards are still refreshing. Reports still go out. Teams still find ways to get numbers. But once the business begins to scale, the weaknesses become much harder to hide.

The warning signs usually appear before the platform itself becomes the problem. Different teams start using different numbers for the same KPI, critical reporting logic begins to live outside core systems and analysts spend more time reconciling data than interpreting it. New business units take longer to onboard, reporting changes become harder than they should be and, before long, the issue is no longer just the data platform. It becomes a broader problem of trust, scalability and control.

That is why too many modernization efforts are scoped too narrowly. Replacing the platform is only one part of the challenge. The real work is untangling years of logic, definitions and integration patterns that were never designed to scale together.

The platform is only one layer of the problem

One of the clearest lessons I have learned is that legacy data environments rarely fail in an isolated way. They fail by becoming harder to trust and harder to change.

In many environments, the data platform is carrying far more than data. It is carrying years of workarounds for things that source systems were never able to handle cleanly. Reporting logic ends up split across ETL jobs, SQL transformations, scripts, spreadsheets and side databases. Some of it was built quickly to solve immediate business needs. Some of it was necessary at the time. But over time, those decisions create duplicated logic, hidden dependencies and handoffs that become harder to govern every time the business changes.

The issue is not only technical debt in the traditional sense. It is also reporting debt, where inconsistent definitions and duplicated logic across reports make data harder to trust and maintain. KPI definitions evolve differently across functions. Business logic gets embedded in too many places. Teams build local workarounds to compensate for mismatched source data. The business keeps moving, but the data foundation falls further behind.

That is why I think CIOs need to treat modernization less like a platform replacement and more like an effort to restore architectural separation and control.

In practice, that means separating ingestion, transformation and reporting instead of allowing all three to collapse into the same layer. It means reducing the number of places where business logic can live. It means establishing a clear source of truth for key metrics before they show up in executive dashboards. It also means making sure master data is defined consistently enough that teams are not comparing duplicate records or conflicting definitions and assuming the platform is to blame.

Fit matters more than feature depth

Platform decisions are often misunderstood.

On paper, most modern data platforms are capable. They all promise scale, flexibility and performance. But in practice, the decision is rarely about capability alone. It is about fit.

In recent modernization work, I have seen firsthand that the wrong decision is not always choosing an inferior technology. More often, it is choosing a platform that introduces unnecessary complexity into an environment that is already fragmented.

That complexity shows up quickly in the form of another cloud to manage, another billing model to track, another toolchain to support, another integration layer to maintain, another set of skills to build and another governance surface to control.

Those costs do not always show up clearly in vendor comparisons, but they show up immediately in execution.

That is why I have become more disciplined about asking a different question. Not what is the most powerful platform on paper, but what choice best aligns with the operating model, capabilities and simplification goals of the enterprise.

There is no one-size-fits-all answer. For some organizations, a separate cloud native warehouse may make perfect sense. For others, a more unified platform approach is the better fit because it leverages current skills, preserves momentum and avoids duplicating effort inside an ongoing modernization program.

That distinction matters.

The goal is not to build the most theoretically flexible architecture. It is to build one where the organization can actually govern, extend and operate over time.

Master data is where credibility starts

Modernization does not become credible until master data starts to improve.

That is not a side effort. It is part of the foundation.

In many enterprises, the root problem is not just the reporting layer. It is the fact that core entities such as customers, products, suppliers and locations are still defined differently across systems. When that happens, every downstream discussion about trust, reporting consistency and AI readiness becomes harder than it should be.

One area where this becomes tangible is syndication and deduplication. In most legacy environments, the same customer, product or supplier exists multiple times across systems, often with slight variations in naming, attributes or hierarchy. Over time, teams build local workarounds to compensate, which only reinforces the fragmentation.

Deduplication is not just a technical exercise. It forces alignment to what defines a unique entity. Syndication operationalizes that alignment, ensuring that once data is standardized, it is consistently distributed across systems and downstream processes. Without both, organizations end up maintaining multiple versions of the same truth and the platform becomes harder to trust regardless of how modern it is.

That is why I keep coming back to master data discipline. If important reports are not built on agreed business definitions and trusted logic, leaders end up looking at different versions of the same KPI. If customers, products and suppliers are not defined consistently across the business, the platform may look modern while the reporting remains hard to trust.

That is also why phased execution matters. Master data does not have to be fully resolved upfront, but it does need to be mature enough in the right domains to support the first releases and give the organization a foundation it can extend with confidence.

A modern foundation has to be engineered for change

What has worked best in my experience is a disciplined architecture that separates ingestion, transformation and reporting instead of mixing them together in ways that are hard to maintain.

That is where the medallion model becomes practical, giving the organization a structured way to separate raw data, standardized data and business-facing reporting. Bronze is where data first comes in from different systems. Silver is where it gets standardized, so the business is not working from conflicting definitions or duplicate records. Gold is where reporting and KPIs can sit on a more trusted foundation. That separation makes the environment easier to scale, troubleshoot and govern over time. The value is not in terminology, but in the discipline behind it.

I have seen organizations modernize into cloud data warehouses, data lakes and lakehouse architectures. The pattern is the same. If the underlying logic, master data and governance are still fragmented, the new platform inherits the same trust problems as the old one.

That same discipline has to carry through to the platform itself. If the environment is going to hold up under growth, the pipelines have to be observable, versioned and resilient enough to support change without constant rework. Environment separation, CI/CD workflows and operational monitoring are not extras. They are part of what makes the platform sustainable.

I also would not lead a modernization effort with AI, even when the pressure is high. AI raises the stakes, but it does not change the core problem. If the data foundation is still fragmented, poorly governed or inconsistent, a new AI layer will not solve it. That is increasingly showing up in the market, with Gartner warning that many generative AI efforts will stall because of poor data quality, inadequate risk controls, escalating costs or unclear business value. Foundry’s latest AI research reinforces this, identifying data storage and management as a top foundational investment for internal AI.

Final thought

The technology will continue to evolve.

The organizations that benefit most will not be the ones chasing every new platform. They will be the ones making disciplined decisions about how those platforms fit into their operating model and executing against them consistently.

Modernization does not fail because the technology is not good enough.

It struggles when the decisions behind it are not grounded in how the business actually runs.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?