If I inherited a company running several SAP environments tomorrow, my starting assumption would be that we should consolidate them. Not necessarily into one system, and certainly not at any cost, but I would expect every separate environment to justify why it should continue to exist.
That may sound like an aggressively pro-consolidation position. To an extent, it is. ERP complexity carries a permanent cost that organisations routinely underestimate. Every additional environment brings its own integrations, skills, controls, testing, data reconciliation, upgrade dependencies, security considerations and support model. Those costs continue year after year, long after whatever decision originally created the environment has been forgotten.
This is how global ERP estates become complicated. Almost nobody deliberately designs a company to operate five SAP environments. One arrives through an acquisition. Another belongs to a regional business that was never fully integrated. A factory gets its own solution because the global programme cannot accommodate an urgent requirement. An older environment survives because migration is considered too expensive or risky. Perhaps another was supposed to be temporary but something more important always came along.
Each decision can be perfectly rational at the time. Fifteen years later, however, the organisation can find itself paying to maintain an architecture that nobody would consciously design today.
My argument is therefore not that every company should have one SAP. It is that the presumption should be towards consolidation, and that the burden of proof should sit with those who want to preserve complexity. Regulation, sovereignty, materially different operating models, resilience, acquisition strategy, planned divestiture and economics can all justify separate environments. History and organisational inertia cannot.
The real cost isn't on the SAP invoice
The business case for consolidation is often framed too narrowly. Licence costs are visible, infrastructure costs can be calculated and support contracts sit conveniently in procurement systems. The larger cost of fragmentation is distributed across the organisation and is consequently much harder to see.
An ERP environment does not exist in isolation. Manufacturing applications exchange information with it. Warehouses depend upon it. Finance reconciles through it. Procurement tools integrate with it. Identity platforms control access to it. Data platforms consume from it. Reporting systems interpret it. People build processes, spreadsheets and sometimes entire careers around understanding its peculiarities.
Add another ERP and you don't simply add another application. You add another set of relationships that must be understood whenever something changes.
This is where the economics become uncomfortable. A company can negotiate a respectable reduction in SAP licensing while continuing to spend millions managing complexity elsewhere. Integration teams maintain interfaces between systems that were never designed to coexist. Finance teams reconcile information that should already agree. Security teams maintain different control environments. External specialists are retained because particular knowledge exists nowhere else. Transformation programmes become slower because every change has to account for several versions of the enterprise.
APQC's work on ERP complexity has repeatedly highlighted the consequences of fragmented environments, including difficulties obtaining consistent information, inefficient processes and the complications created when growth and acquisitions continually add systems. That aligns with what many large organisations experience in practice: the technology continues to work, but the organisational friction around it steadily increases.
That friction is the part I would put into the business case.
The objective isn't to save the maintenance cost of SAP number four. It is to remove the operational complexity that exists because SAP number four exists.
There is an equally important caveat. Consolidation itself can be phenomenally expensive. Data migration, implementation, process redesign, integration work, testing, training and organisational change can easily overwhelm a simplistic cost-reduction argument. A stable regional ERP costing relatively little to operate may quite rationally remain in place if replacing it requires a transformation whose economics don't stack up.
That does not weaken the case for consolidation. It simply means that a prettier architecture diagram isn't a business case. The comparison must be between the lifetime cost of retaining complexity and the full cost and risk of removing it.
One version of the truth matters more than one version of SAP
If I were making the case to a board, I would spend less time talking about SAP instances and considerably more time talking about data.
Multiple ERP environments have an unfortunate habit of creating multiple versions of organisational reality. Customers are represented differently. Suppliers acquire several identities. Materials use different numbering schemes. Product hierarchies diverge. Charts of accounts evolve separately. Plants classify inventory differently. Similar processes generate information that has to be translated and reconciled before anybody is comfortable comparing it.
The company still operates because people compensate.
That ability shouldn't be underestimated. People know which spreadsheet contains the number everyone actually trusts. They know that a particular field means something slightly different in Germany from what it means in America. They know which report must be adjusted before it goes upstairs. They know that the official master data is technically authoritative while another source is operationally more accurate.
Eventually this accumulated human knowledge disguises architectural failure. The business appears to work perfectly well, but only because hundreds or thousands of people have learnt how to navigate its exceptions.
Consolidation creates an opportunity to remove some of that friction, but only if the programme tackles the underlying causes. Moving five SAP instances into one while retaining five definitions of the customer, five approaches to materials and hundreds of local process variations achieves remarkably little.
This is why I would separate ERP consolidation from business harmonisation.
They are related, but they are not the same thing.
A company can run several SAP instances while maintaining disciplined master data, common controls and broadly standard processes. Another company can operate a single S/4HANA environment that has been customised and localised so extensively that its business units effectively inhabit different ERPs inside the same technical platform.
The latter may look beautifully consolidated on an architecture diagram while remaining fragmented everywhere that actually matters.
That distinction becomes important because “one SAP” can easily turn into an objective in its own right. Once that happens, the programme starts measuring success by the number of systems retired rather than by the organisational friction removed.
I think that is the wrong measure.
“We're different” is expensive
The hardest part of ERP consolidation rarely turns out to be SAP. It is usually the organisation itself.
Every business has reasons why its processes are different. Its customers are different. Its products are different. Its factories are different. Its market is different. Its regulatory environment is different. Its history is different.
Sometimes those differences genuinely matter. A highly configured industrial manufacturer should not automatically be forced into exactly the same processes as a high-volume operation simply because somebody at headquarters likes the idea of a global template. A regulated subsidiary may have obligations that other parts of the group do not. A country's legal or fiscal requirements may require local functionality. Some differences genuinely create competitive advantage.
The problem is that genuine differentiation and inherited preference tend to become indistinguishable over time.
A process designed fifteen years ago becomes familiar. Interfaces are built around it. Reports depend upon it. People are trained to use it. Eventually the difficulty involved in changing the process becomes evidence that the process itself is necessary.
This is why “we're different” can be one of the most expensive sentences in enterprise technology.
The phrase deserves challenge, not dismissal. If a factory genuinely requires a different process, preserve it. If regulation requires local treatment, support it. If a business model creates competitive advantage through a particular way of operating, the ERP should enable rather than erase that advantage.
But if the explanation eventually reduces to “this is how we've always done it”, the organisation is maintaining history and calling it architecture.
ERP consolidation can be valuable precisely because it forces those conversations. Why does one factory procure differently from another? Why are approval levels different? Why are supplier classifications inconsistent? Why are there several charts of accounts? Why does a particular process contain additional steps in one country?
Those aren't SAP questions. They are operating-model questions.
That is also why a large ERP consolidation should never be treated as an IT migration. The moment the programme starts challenging those differences, it becomes a business transformation with SAP at its centre.
Consolidation is not the same thing as moving to RISE
There is another distinction that I think has become increasingly important as SAP's operating models have changed.
A company can have S/4HANA in Germany, S/4HANA Cloud Private Edition through RISE with SAP in the United States and perhaps another SAP environment operated through a traditional hosting arrangement somewhere else. Somebody looking only at the application layer might reasonably say that the organisation has standardised on SAP or even S/4HANA.
Architecturally, however, those environments are not necessarily the same at all.
Application consolidation, process harmonisation, data harmonisation and hosting strategy are separate decisions. So is the question of who actually operates the environment.
RISE with SAP is one possible answer, and for some organisations it will be the right one. RISE can itself use hyperscaler infrastructure such as Microsoft Azure, but that doesn't make it equivalent to a customer running S/4HANA within its own Azure estate. In the RISE model, SAP manages the RISE environment and the division of responsibilities reflects the services contracted from SAP. In a customer-controlled Azure model, the organisation can retain control of the Azure environment while delegating operational responsibility to a specialist provider.
That second model is more interesting than it sometimes gets credit for.
Microsoft Azure Lighthouse allows customers to delegate management of subscriptions or resource groups to another tenant. In practical terms, an organisation can own its Azure environment while giving an authorised managed-service provider the permissions required to operate it. The underlying resources remain in the customer's environment.
That creates an important separation between where the workload lives and who operates it.
If the relationship with the managed-service provider eventually changes, the customer can remove delegated access and potentially onboard another provider without moving the SAP infrastructure simply because the operator has changed. Changing an SAP managed-service provider is obviously not frictionless: knowledge transfer, tooling, contracts, Basis responsibilities, operational processes and service management all still need attention. But the infrastructure does not necessarily need to move with the supplier.
For CIOs considering consolidation, this distinction matters because large programmes have a habit of bundling several transformations together. Three SAP environments are going to become one, so the company also changes hosting model, operating partner, integration architecture, security model, data model and business processes at the same time.
Every one of those decisions may be defensible. That doesn't mean they need to happen simultaneously.
There is considerable value in knowing what not to change.
If the business problem is ERP fragmentation, solve ERP fragmentation. If the operating model also needs changing, make that a deliberate decision with its own rationale rather than treating it as an inevitable consequence of consolidation.
One SAP can also create one enormous dependency
There is a strong architectural argument for reducing duplication, but consolidation creates a trade-off that deserves more attention than it often receives: concentration risk.
Technology leaders spend a great deal of effort designing systems around segmentation, isolation and blast radius. We don't generally want one failure to become everybody's failure. Yet a global ERP strategy can move in exactly the opposite direction, concentrating a remarkable proportion of the company's transactional capability into a single environment.
If one of four relatively independent ERP systems fails, perhaps one region or business unit loses transactional capability. If the single global ERP fails, orders, procurement, manufacturing, warehousing, shipping, invoicing and finance may all discover how much they have in common.
The same is true of cyber incidents.
This is not an argument for maintaining unnecessary ERP systems as an expensive form of disaster recovery. It is an argument for recognising that consolidation changes the consequences of failure.
As the number of platforms decreases, the resilience requirements of those that remain increase.
Recovery architecture, identity dependencies, backup integrity, cyber isolation, disaster recovery, recovery testing and manual business procedures therefore belong inside the consolidation programme, not in a technical workstream bolted onto the side of it.
A global ERP can become the transactional nervous system of the company. If so, the board should understand not only what the consolidated platform will cost and what efficiencies it will create, but also what happens to the company when that platform isn't available.
There is a similar organisational concentration risk.
Global standardisation can become bureaucracy surprisingly quickly. A factory that once made a local change in six weeks may discover that the same change now requires approval from a global process owner, enterprise architecture, security, finance, the template team and a release board.
The global organisation sees governance. The factory experiences delay.
People don't stop solving operational problems because the approved route has become slow. They find another route. A spreadsheet appears, followed by a small database, then a SaaS application and eventually an integration nobody centrally owns. Several years later, corporate IT discovers a new shadow application estate growing around the beautifully standardised ERP.
That would be a fairly hollow victory.
The answer is not to abandon standardisation. It is to design guardrails rather than gates. A global architecture should establish the boundaries within which local organisations can move quickly, not require headquarters to approve every meaningful decision.
Otherwise ERP consolidation simply moves complexity from the core into the edges.
Composable ERP doesn't provide an escape from this problem
The industry's enthusiasm for composable ERP offers a useful counterweight to the traditional monolith. Keeping the core stable while using specialist applications for capabilities that genuinely differentiate the business can be a much healthier approach than endlessly customising SAP because somebody once decided that everything should live inside the ERP.
I support that direction, but composability should not become an excuse for accumulation.
Moving functionality outside SAP doesn't make complexity disappear. Somebody still owns the process. Somebody still owns the data. A system still has to be authoritative. APIs need monitoring. Interfaces change. Security boundaries need controlling. Transactions still have to travel reliably from one end of the business process to the other.
There is a point at which “composable ERP” risks becoming a fashionable description for having lots of systems connected together.
We already know how that story ends.
The lesson from decades of ERP complexity isn't that monoliths are inherently good and composability inherently bad. It is that flexibility without lifecycle discipline eventually becomes accumulation.
Every specialist application should therefore face much the same challenge as every ERP instance: why does it exist, what value does it create, and under what circumstances would we retire it?
Without that discipline, today's beautifully composable architecture becomes tomorrow's rationalisation programme.
M&A exposes whether there is actually a strategy
Acquisitions are one of the most understandable reasons for ERP proliferation. A company buys another company and inherits its ERP, CRM, warehouse systems, data structures, integrations and controls. Everybody is focused on Day One, business continuity and capturing the strategic value of the transaction. Replacing SAP understandably isn't the first priority.
So the systems remain and interfaces are built.
The dangerous sentence comes next: we'll deal with SAP later.
Sometimes later is exactly the right answer. The problem is when later has no date, trigger or architectural intention attached to it. Temporary complexity then becomes permanent architecture.
I think technology integration needs to feature much earlier in acquisition economics. If the investment case assumes procurement synergies, integrated supply chains, shared operations or consolidated finance, the systems required to realise those benefits are part of the transaction economics. Discovering eighteen months later that ERP integration will cost €20 million and take three years doesn't turn it into an unexpected IT expense. It means part of the cost of integration wasn't properly understood when the acquisition was evaluated.
That still doesn't mean every acquired company should immediately be pushed onto the corporate ERP. Sometimes autonomy is deliberate. Sometimes integration would destroy value. Sometimes the acquired business may eventually be sold again.
The divestiture point matters because the argument works in both directions. A business deeply embedded in a global ERP can be significantly harder to separate. Data must be extracted, access disentangled, interfaces recreated, historical records preserved and transitional service arrangements established. A wonderfully integrated architecture can become a major obstacle when corporate strategy decides that part of the company should belong to somebody else.
Architecture should therefore support corporate strategy rather than assume today's organisation chart is permanent.
This is another reason I don't believe “one SAP” is a strategy. It is an architectural outcome that may or may not support what the company is trying to become.
Consolidation has to be worth the disruption
There is one final reason to resist simplistic consolidation arguments: the consolidation programme itself may create more risk than the systems it replaces.
ERP sits in the middle of how companies operate. What begins as a programme to move three SAP environments onto one S/4HANA platform quickly becomes a discussion about finance, procurement, master data, manufacturing processes, integrations, reporting, controls, roles, responsibilities and historical data. Thousands of users may need retraining. Cutover has to happen while the company continues to take orders, manufacture products, move inventory, ship goods, pay suppliers, invoice customers and close its books.
That is not an IT migration.
It is an operating-model transformation.
If the organisation genuinely wants that transformation, consolidation can be the catalyst for something far more valuable than infrastructure savings. It can simplify processes, improve data, strengthen controls and create a much cleaner foundation for analytics, automation and AI.
If the organisation doesn't want the transformation, the programme can spend an extraordinary amount of money recreating the existing organisation inside a new technical architecture.
One SAP. Five ways of working. Hundreds of exceptions. A very large invoice.
That may be the worst possible outcome because the company takes most of the transformation risk while preserving much of the complexity.
This is why I would start any consolidation programme with discovery rather than a predetermined destination. Understand which processes run where, which systems are authoritative, which integrations exist, which local applications surround them, which spreadsheets have quietly become business-critical and which regulatory requirements are genuine. Understand the customisations that still create business value and those that simply encode history.
Then make deliberate decisions.
Some environments should be consolidated because there is no compelling reason for their continued independence. Others should be harmonised because immediate migration doesn't make economic sense but their processes, controls and data need to align with the group. Some should be integrated because there is a legitimate reason for them to remain different. A smaller number should be retained because independence genuinely creates value or reduces strategic risk. And some should simply be retired because nobody designing the organisation today would choose to build them.
That gives me a much more useful definition of ERP strategy than getting to one SAP.
It is the deliberate removal of complexity that no longer earns the right to exist.
The Pragmatic View
I would begin an ERP review with a presumption towards consolidation.
Every additional SAP environment imposes a permanent tax on the enterprise through duplicated skills, controls, integrations, data reconciliation, testing, support and change. That tax may be worth paying, but the business should be able to explain why.
Regulation can justify it. Sovereignty can justify it. A genuinely different operating model can justify it. Resilience, acquisition strategy, planned divestiture and simple economics can justify it.
“We've always done it this way” cannot.
Nor would I allow the discussion to collapse into a choice between one SAP and many. Application consolidation, business harmonisation, data standardisation and hosting strategy are different decisions. Moving to RISE doesn't automatically consolidate the business. Running SAP in customer-controlled Azure doesn't prevent consolidation. Having one S/4HANA environment doesn't automatically mean the organisation operates consistently.
The number of SAP systems is therefore the wrong target.
The target should be the minimum ERP complexity the business genuinely needs.
Consolidate what exists because of history. Harmonise what needs consistency. Integrate what legitimately needs independence. Retain what genuinely creates value. Retire what nobody would choose to build again.
If that leaves a global company with three SAP environments, keep three. If the evidence takes it to one, run one.
But every environment that remains should be there because the organisation has consciously concluded that its value exceeds the permanent cost and complexity of keeping it.
Anything else isn't ERP strategy.
It's history you're still paying for.
