ERP Vendor Consolidation Isn't Making Things Simpler

Salesforce buys MuleSoft. Oracle buys NetSuite. SAP buys Concur. The ERP industry has been consolidating for years, and every acquisition is pitched as a step toward the unified platform. What it actually produces, more often than not, is two separate systems with one logo on the invoice. Buying the company doesn’t solve the data architecture problem.

The logic of ERP consolidation is seductive. If the problem is that businesses are running too many disconnected systems, and those systems are difficult to integrate because they’re built by different companies with different data models, then shouldn’t buying those companies together solve the problem? Combine the vendors, and eventually the products converge.

This is the theory. The practice is considerably messier.

The acquisition-integration gap

When Salesforce acquired MuleSoft in 2018 for $6.5 billion, the stated goal was to help customers connect everything — their clouds, their data, their applications — through a unified integration layer.¹ MuleSoft remained a largely separate product and team. It became part of the Salesforce Customer 360 narrative, positioned as the connectivity backbone of the Salesforce ecosystem. What it didn’t become was a structural change to how Salesforce’s own products share data. Salesforce Sales Cloud and Salesforce Financial Services Cloud still maintain separate object models in certain scenarios. MuleSoft is the tool customers use to connect things — including Salesforce to other Salesforce products.

Oracle’s acquisition of NetSuite in 2016 for $9.3 billion followed a similar pattern.² Oracle positioned the deal as giving it a complete cloud ERP offering for every tier of the market — Oracle Fusion at the top, NetSuite in the mid-market. Years later, the two products are maintained largely independently. NetSuite customers are not NetSuite-plus-Oracle customers. The engineering teams and product roadmaps remain largely separate. The acquisition was about market position, not architectural convergence.

Why convergence is harder than acquisition

Software products don’t merge because their parent companies do. Two products with different data models, different APIs, different UI frameworks, different deployment models, and different engineering cultures don’t become one product because one company buys the other. They become one company’s products.

Real technical convergence would require choosing one data model, migrating customers from the deprecated model to the surviving one, rebuilding the integration layer, retraining users, and managing the disruption across a customer base that bought the legacy product specifically. The business case for that kind of disruption is almost never compelling enough to execute — so it doesn’t happen. Instead, the two products are “integrated,” which means connected by API, which is exactly where we started.

The customer experience of consolidation

For customers, ERP vendor consolidation mostly produces pricing changes and product roadmap uncertainty. The vendor now has less competition for specific capabilities. The roadmap priorities reflect the parent company’s strategic interests, which may or may not align with what any given mid-market customer actually needs. And the “better together” story from the sales team often refers to integrations that are functional but not architectural — the products pass data between each other, but they remain separate systems.

This isn’t necessarily a criticism of any specific company’s strategy. Organic platform building takes decades. Acquisition is faster. But customers should be clear-eyed about what consolidation actually delivers versus what it’s sold as delivering. A unified invoice doesn’t mean a unified data model.

What genuine platform architecture looks like

The difference between a platform and a collection of acquisitions is the data model. A true platform has one underlying schema that every application reads and writes. When the CRM creates a customer, the finance module sees the same record — not a copy, not a synced replica, the same record. When a contract is executed, the commercial, financial, and operational consequences all trace to one event in one system.

That architecture doesn’t happen through acquisition. It happens through design decisions made at the foundation, before the applications are built on top. The companies that can honestly claim platform architecture are the ones who chose that path from the beginning — and who are willing to constrain what they build in service of keeping it whole.

Sources