For decades, ERP systems have served as the operational backbone of the enterprise. When an order is booked, when inventory moves or when a supplier invoice is paid, that transaction typically lands inside an ERP system. For many organizations, ERP has also been the primary lens for understanding the business, serving as not only the source of record but the basis for analyzing revenue, inventory, production and financial performance. That role is changing, and the change is happening faster than most enterprises have planned for.

My view is that ERP is no longer the single center of gravity for enterprise data. It has become one of several anchor systems in a broader data ecosystem, and that shift now requires intentional architectural decisions that many enterprises have not yet made. What I continue to hear in conversations with senior technology and operations leaders is that the challenge is not ERP modernization in isolation. It is figuring out how ERP data connects to the rest of the application landscape without losing the business meaning behind it.

In a previous article I discussed why enterprise data strategies are moving from single platforms toward broader ecosystems of connected systems and data services. That change applies directly to how organizations should think about ERP data, too. The question I hear most often is not about which single platform will win. It is about how to harness ERP data alongside data from other sources, without getting mired in different definitions and governance rules. That is the real architectural problem that enterprises must address.

ERP As The Single Lens No Longer Holds

The environment where decisions are formed has expanded beyond the ERP application itself. Organizations are analyzing ERP data alongside signals from customer platforms, logistics networks, manufacturing systems and external market data. ERP still provides the structured record of what happened, but understanding why it happened and what to do next becomes clearer when the other signals are combined with ERP transactions.

This approach implies a different operating model for enterprise decision making, one that forces leaders to confront some concrete questions:

• Where should ERP data live once it leaves the transactional system?
• Which platform should define core business metrics?
• How does ERP data connect with other operational systems?
• How do governance and security hold together as ERP data moves across multiple environments?

These are not theoretical questions. They come up in every ERP modernization conversation I have.

One of the challenges organizations face is that ERP vendors and enterprise data platform vendors are both expanding into this space at the same time. SAP, Oracle and Microsoft are each building data environments designed to sit alongside or beneath their ERP applications. Meanwhile, independent data platform vendors such as Snowflake, Databricks, Cloudera and Teradata are positioning their products as the ideal neutral layer for combining ERP data with everything else. What these vendors are saying is that organizations need one place where ERP data and operational and customer data live together, so everyone is working from the same view of the business. The risk for organizations trying to rationalize these overlapping capabilities is not picking the wrong vendor. The risk is designing an ecosystem where ERP data ends up fragmented, duplicated or stripped of the semantics that make it useful.

Why ERP Data Cannot Stay In Its Own Silo

ERP systems are good at recording what happened in the business. But a financial ledger that shows margin pressure, for example, does not explain why it is happening. The cause often emerges from customer behavior patterns, supplier performance data or production system telemetry recorded in other systems. Leadership increasingly expects that context to be delivered quickly, not weeks later at the end of a reporting cycle.

This gap is especially visible in manufacturing. Consider a situation where the ERP shows that inventory for a key component is declining. On its own, that signals a problem — but where did it come from? The answer might be found in a combination of port congestion that has slowed inbound shipments at the same time that customer demand has climbed in a specific region. Connecting those signals, ideally long before the consequences show up in financial results, is exactly the kind of early visibility that modern supply chain operations require. When ERP is the only lens, that kind of signal is often invisible until the problem has already mushroomed.

I have written previously about how legacy ERP environments can limit the ability of manufacturers to operate in faster, more connected industrial environments. I continue to see this play out when manufacturers try to pull ERP data into modern planning, scheduling or shop-floor applications without a clear data architecture — and governance rules — underneath. In those cases, it’s no surprise when integration work stalls, data definitions drift and operational insight that was supposed to follow never materializes.

This also connects to how ERP itself is evolving. In a past article I described the move toward event-driven agentic ERP architectures where systems respond to operational signals as they occur. Reaching that point requires a data architecture that was designed for it.

What Is Driving This Shift In ERP Data Management

Several forces are pushing organizations in this direction. The first is the growing complexity of enterprise technology environments. Most organizations no longer operate a single application stack. It is common to see ERP from one vendor, CRM from another, HR systems from a third and specialized supply chain or industry platforms layered alongside them.

The second factor is SaaS fragmentation. Over the past decade-plus, many business units adopted specialized cloud applications rapidly. Those systems created real value, but they spread operational data across many environments. Today, large organizations routinely operate dozens, sometimes hundreds, of cloud applications running across hybrid and multi-cloud infrastructure. Some data remains on-premises, while some runs in public clouds and some resides inside SaaS platforms that operate largely independently from the rest of the technology environment. These two factors mean that no single system holds the complete picture of the business.

At the same time, as touched on earlier, expectations for operational insight have increased significantly. Yet ERP systems were not designed for cross-system, near-real-time analysis. Data platforms have emerged as the layer that bridges that gap, allowing organizations to handle signals across many systems at once. As AI becomes more embedded in operations, these platforms are also where AI tools connect to both ERP and non-ERP data.

How ERP Vendors Are Repositioning Their Data Platforms

ERP vendors have responded to this shift by expanding well beyond transaction processing. I see these vendors making ERP data easier to access, analyze and combine with other operational signals. They are building curated data layers aligned to core business processes such as order-to-cash and procure-to-pay, so organizations do not have to navigate complex ERP schemas to get usable data out. They are embedding semantic models that define how key metrics such as revenue, backlog, margin and working capital should be interpreted across analytics and planning environments. Integration capabilities are expanding as well, with APIs, connectors and event streams making it easier for ERP data to flow into data platforms and AI services. The underlying goal across all of this is to package ERP data as a product: contextually defined and ready for downstream consumption.

We can take a quick look at what specific vendors are doing in this area. SAP is positioning its Business Data Cloud to unify SAP operational data and connect it with external sources. Oracle is expanding the role of its Fusion AI Data Platform to combine SaaS application data with analytics and infrastructure. Microsoft is positioning Dynamics 365 data to flow into Microsoft Fabric and OneLake, with Purview intended to manage governance, data policies and lineage across that environment. (At FabCon 2026 earlier this month, Microsoft presenters made it clear that the company wants databases, analytics, governance and AI to operate as one platform, not a collection of separate products.) Meanwhile, industry-specific and mid-market vendors including Infor, IFS, Epicor, QAD, Sage, Acumatica and Odoo are moving in a similar direction, typically with a stronger emphasis on embedded operational insight rather than broad ecosystem connectivity.

Adjacent enterprise platforms are also shaping how this ecosystem forms. Workday’s Prism Analytics, for example, allows organizations to combine external datasets with HR and finance data. Salesforce Data Cloud focuses on unifying customer data across sales, service and marketing systems. In many enterprises, these platforms operate alongside ERP and contribute additional context to operational decisions that ERP alone cannot provide.

The architectural conversation that technology and operations leaders need to have with their ERP vendors must go beyond product roadmaps. The right discussion is about how these ERP-adjacent data environments will coexist with current enterprise data platforms and what happens to data definitions, governance and lineage as ERP data moves across those layers.

Where Should ERP Data Products Actually Live?

As ERP vendors expand their data capabilities and enterprise data platforms continue to mature, organizations face a practical architectural decision. Where should ERP data products actually be created and managed? This is not an abstract question. It comes with tradeoffs that affect cost, flexibility and the ability to support AI workloads.

Some organizations favor the ERP vendor platform because the data models are pre-defined and the core processes are already modeled. The time-to-value is faster, but the dependency on that vendor’s ecosystem increases. Others move ERP data into a neutral enterprise data platform first, then build analytics, automation and AI services on top of it. That model provides more flexibility, especially for organizations running multiple ERP systems or absorbing acquisitions, but it also requires more internal data engineering to recreate the semantic models and integration pipelines that ERP vendors may already provide. In reality, most enterprises end up somewhere in between, keeping application-aligned analytics close to the ERP platform while moving cross-system AI workloads and broader reporting into an enterprise data platform.

The organizations that handle this well make it an explicit architectural decision rather than letting it emerge through project-by-project integrations. They define which platform owns the authoritative version of key ERP-derived metrics, and document how those definitions are exposed and governed across downstream systems. The ones that do not tend to discover the problem later, when different teams are working from slightly different versions of the same number and no one can easily trace why.

What Enterprises Need To Get Right With Their ERP Data

ERP systems are not going away. They remain the system of record for the transactions that run the business. What is changing is how that transactional record connects to everything else. ERP now functions as one of several anchor systems in a signal-driven ecosystem. As event-driven architectures and AI services become more common, the ability to connect ERP events with operational signals in near-real time will separate enterprises that operate proactively from those still reacting to last month’s results.

The execution risk is concrete. Most organizations still lack clear data ownership across ERP and non-ERP environments, consistent semantic definitions that survive as data moves across platforms, and the organizational alignment to treat ERP data products, ERP vendor data platforms and enterprise data platforms as a single architectural domain. I see this as one of the most underestimated implementation challenges in enterprise data strategy today.

Operations and technology leaders should be deliberate about where each workload belongs, set clear rules for how ERP semantics are preserved as data moves and resist the temptation to allow every team to build its own slightly different version of the truth. That last point matters more than most organizations acknowledge. When ERP-derived metrics mean different things in different systems, teams spend time debating numbers instead of acting on them.

Enterprises that solve this ERP data ecosystem design problem will be in a stronger position to use AI and advanced analytics in their day-to-day operations. Those that keep treating ERP as an isolated system of record will continue to struggle with fragmented data and the slower, less-informed decisions that follow.