E. ERP and Core Systems Transformation

40. One ERP or multiple? Post-deal ERP strategy choices

A decision framework for choosing one ERP, multiple ERPs, or a staged model without turning ERP standardization into a value-delay program.

ERP Integrations Value creation

The investment case assumed one operating model.

The combined company would buy from common suppliers, quote customers with common pricing logic, close the books faster, report margin by product and customer, and reduce finance and operations cost. The integration team translated that into a familiar ERP answer: move everyone to one platform.

Six months later, the ERP program had become the value program. Procurement savings waited for item master cleanup. Finance synergies waited for chart-of-accounts redesign. Plant teams waited for process workshops. The business kept running on the old systems anyway, with new reporting bridges on top. The one-ERP answer was directionally right, but it was the wrong first move.

The question after close is not whether one ERP sounds cleaner. It usually does. The real decision is: should the post-deal company consolidate to one ERP, keep multiple ERPs, or sequence a hybrid path based on value gates, process fit, TSA pressure, and execution capacity?

That decision should be made before the ERP program has a name, a system integrator, or a steering committee. Once a company labels ERP standardization as the answer, every value initiative starts waiting for it.

ERP strategy is an operating model decision

ERP choices are often framed as system choices: SAP vs. Oracle, Dynamics vs. NetSuite, incumbent vs. buyer standard. That is the wrong level of debate for the executive team.

The ERP strategy should answer four operating questions:

  • Which processes must be common to capture the deal thesis?
  • Which processes can stay local without leaking EBITDA or control?
  • Which data must be standardized now, and which can be mapped for a period?
  • Which changes can the business absorb while hitting the first-year plan?

One ERP can create real value when it enables common purchasing, shared services, inventory control, faster close, and cleaner data. It can also delay value when it forces every location, country, and product line through a program that solves more than the deal requires.

Multiple ERPs can be pragmatic when business units have clean boundaries, different operating models, or low transaction overlap. They can also trap value when they block supplier consolidation, customer-level profitability, or working-capital control.

The staged answer is often the best answer: standardize the data and control layer first, move selected entities or processes next, and reserve full ERP consolidation for the point where the value case clears the execution cost.

The value at stake is timing, not just run cost

ERP standardization business cases often over-index on IT run cost. License consolidation, support reduction, and application retirement matter, but they are rarely the full prize.

The larger value usually sits in five places.

1) Procurement and supply chain savings

Common supplier terms, item rationalization, and demand aggregation require clean vendor, item, plant, and purchasing data. They do not always require one ERP on day one.

If the company can build a reliable spend cube, standard approval policies, and a common supplier master across systems, it may capture a large share of procurement value before ERP consolidation. If item codes are inconsistent, plants buy off-contract, and approvals vary by entity, one ERP becomes a value enabler, but only after the data work is funded.

2) Finance close and management reporting

One ERP can reduce reconciliations and manual reporting work. But a rushed consolidation can make the first close worse, especially when legal entities, tax structures, revenue recognition, and cost centers are redesigned at the same time.

The first value gate should be reporting confidence: revenue, gross margin, EBITDA, cash, backlog, and working capital must reconcile across the combined perimeter. A common reporting and master data layer may be enough for the first two quarters. Full ERP migration may be needed for shared services later.

3) Working capital

Inventory accuracy, purchase order discipline, credit holds, collections, and payment terms often depend on ERP configuration. The issue is not only which ERP runs the process. It is whether controls are enforced consistently enough to change cash behavior.

If two ERPs can support common inventory policies and consolidated cash reporting, immediate consolidation may not be the fastest path to cash. If separate ERPs create different item masters, duplicate safety stock, and inconsistent order promising, the company may need a stronger standardization move.

4) TSA exit and stranded cost

In carve-outs, ERP strategy is constrained by the seller’s system, data rights, service terms, and exit clock. A one-ERP ambition can collide with a nine-month TSA, especially if the target sits in a shared SAP client or relies on parent-owned interfaces.

The right answer may be a minimum viable ERP stand-up first, even if it is not the long-term platform. That can feel inefficient. It may be the only way to exit the TSA without putting order-to-cash or payroll at risk.

5) Management capacity

ERP programs consume the same people needed to run integration, close the books, serve customers, and deliver the value plan. The best ERP answer on paper can be the wrong answer if the CFO, COO, plant leaders, and process owners cannot support it.

Capacity is not a soft issue. It is a timing constraint on EBITDA.

What goes wrong

ERP strategy fails when the company treats standardization as a principle instead of a sequence of value decisions.

The company chooses one ERP before defining which value requires it

The executive team agrees that one ERP is “the future state.” The program then expands to include every process, entity, report, workflow, and exception. The business case gets bigger, the timeline stretches, and the first-year value plan waits for a future go-live.

The mechanism is simple: scope follows ambition. Once the company commits to one ERP without value gates, every stakeholder tries to solve local pain inside the same program.

The team keeps multiple ERPs but builds no control layer

The opposite failure is quieter. Leadership decides ERP consolidation is too hard, so every business unit keeps its system. There is no common supplier master, no shared item taxonomy, no process owner for order-to-cash, and no reliable management reporting layer.

The result is a combined company in name only. Procurement cannot prove savings. Finance cannot compare margins. Operations cannot see inventory clearly. The deal model assumes integration; the systems preserve separation.

A temporary bridge becomes permanent architecture

Some deals start with a sensible hybrid model: keep systems stable, map data centrally, and migrate later. Then the interim layer grows. Spreadsheet mappings, custom extracts, duplicated reports, and manual reconciliations become the operating model.

The trap is that bridges feel cheap until they become control points. When finance depends on a manual mapping file to report EBITDA, or supply chain depends on one analyst to reconcile item data, the company has created a shadow ERP without governance.

TSA pressure forces the wrong ERP answer

A short TSA can push teams into a fast stand-up that is underdesigned, or a big-bang migration that should never have been tied to separation. Both create risk.

If the parent system exit is the near-term constraint, solve exit first. Do not confuse that with the long-term ERP strategy. A clean TSA exit may require a smaller ERP build, a cloned instance, or a narrow migration scope. The value program can then move with more control.

The business underestimates adoption cost

ERP standardization is process change wearing a technology label. Sales teams lose local pricing workarounds. Plant teams lose familiar production screens. Finance loses custom reports. Procurement enforces approvals that managers used to bypass.

When adoption is underfunded, the system may go live and the value may still not show up. Users find workarounds, data quality declines, and manual reporting continues.

The decision framework: value gates before platform choices

The ERP strategy should be decided through a short sequence of tests. The output is not a slogan. It is a sequenced answer.

Gate 1: What value requires common process?

List the top value initiatives and identify the process dependency behind each one.

  • Procurement savings: common supplier terms, item taxonomy, approval controls, spend visibility
  • Finance synergy: standard close calendar, chart of accounts, consolidation rules, shared service workflows
  • Working-capital improvement: inventory accuracy, purchase discipline, credit policy, collections workflow
  • Revenue synergy: customer master, pricing rules, contract terms, billing and tax treatment
  • Cost reduction: application retirement, support model, process automation, role consolidation

If the initiative requires common policy and data but not a common transaction system, do not make ERP migration the first dependency. Build the control layer and capture value sooner.

If the initiative requires common transaction enforcement, such as one purchasing workflow or one inventory reservation model, ERP consolidation or process migration becomes part of the value path.

Gate 2: Are the businesses operationally similar enough?

One ERP works best when the combined company has similar products, channels, plants, geographies, and finance controls. It gets harder when the acquired business has a different production model, regulatory regime, revenue model, or customer promise.

Use a simple test:

  • If more than 70% of transaction volume follows the same order-to-cash, procure-to-pay, and record-to-report pattern, one ERP should be tested seriously.
  • If the acquired business has materially different manufacturing, service, project accounting, or regulatory workflows, keep multiple ERPs unless the value case proves the cost of standardization.
  • If similarity exists in finance and procurement but not operations, standardize the finance and procurement layer first, then decide whether plant or industry-specific modules should move later.

This prevents a common mistake: forcing operational uniqueness into ERP standardization and then blaming the software for business complexity.

Gate 3: How hard is the data problem?

ERP consolidation is mostly a data program once the target platform is chosen. Customer, supplier, item, bill of material, chart of accounts, open orders, inventory, contracts, and history determine the clock.

Use these triggers:

  • If customer, supplier, and item masters can be matched at more than 85% confidence, data should not block a first-wave migration.
  • If item or bill-of-material data has more than 15% duplicates or unresolved ownership gaps, fund data remediation before committing to a big-bang ERP move.
  • If chart-of-accounts mapping cannot support EBITDA, cash, and working-capital reporting within one close cycle, build reporting controls before transaction migration.
  • If historical data is legally constrained or poor quality, keep history in archive or reporting systems rather than loading it into the new ERP by default.

The discipline is to separate what must move from what people are used to having nearby.

Gate 4: What does the TSA force?

For carve-outs, TSA pressure can overrule the clean long-term answer.

Decision triggers:

  • If the seller ERP TSA is under nine months and the business is in a shared ERP client, choose a minimum viable separation path before a full standardization path.
  • If the parent controls master data changes, interfaces, or finance close activities, do not assume ERP consolidation can wait until year two without negotiated access and service levels.
  • If TSA fees step up after month 12 by more than 20%, compare the cost of a narrower stand-up against the cost of delay.
  • If seller support excludes project work, do not plan data cleanup, interface redesign, or reporting builds as if the TSA team will deliver them.

The executive question is: what is the cheapest reliable way to own the business before the TSA becomes a constraint?

Gate 5: Does the organization have capacity?

ERP programs fail when the same leaders own too many deal missions.

Before choosing one ERP, ask whether the company has named owners and available capacity for:

  • finance design: chart of accounts, close calendar, consolidation, controls
  • commercial design: customer master, pricing, contracts, billing, tax
  • operations design: plants, warehouses, production, quality, inventory
  • data design: ownership, cleansing, migration, reconciliation
  • cutover: test cycles, freeze windows, support, fallback decisions
  • change adoption: role mapping, training, local process changes

If the same five people own integration, synergy delivery, close, TSA exit, and ERP design, the answer is not “move faster.” The answer is to narrow scope, add capacity, or change sequence.

When one ERP is the right answer

One ERP is the right answer when standard process is directly tied to value and the business can absorb the change.

Choose one ERP early when:

  • the deal thesis depends on shared services, common procurement, or common manufacturing controls within 12-24 months
  • the businesses have high process overlap and low regulatory divergence
  • the current ERP estate has more than two systems serving the same operating model
  • reporting bridges would become permanent control risk
  • application run cost and support talent are fragmented enough to reduce EBITDA
  • the leadership team is willing to stop local exceptions, not just fund software

The right one-ERP program still needs value gates. It should not wait 18 months to produce value. The program should deliver interim releases: common vendor master, standard approval policy, close reporting, shared reporting definitions, and selected process harmonization before the final cutover.

When multiple ERPs are the right answer

Multiple ERPs are not a failure if they match the operating model.

Keep multiple ERPs when:

  • business units have distinct products, production models, channels, or regulatory requirements
  • there is limited supplier, customer, inventory, or finance process overlap
  • the cost of standardization exceeds the value available in the hold period
  • the acquired business is expected to be operated, improved, and sold as a standalone platform
  • management reporting can be controlled through a clean data layer
  • the team can retire duplicative applications without forcing full ERP migration

This answer still needs governance. Multiple ERPs require a common control model: reporting definitions, master data standards, security rules, close calendar, procurement policy, and architecture ownership. Without that, “multiple ERPs” becomes an excuse for no integration.

When a hybrid path is the best answer

Hybrid is often the highest-value choice, but only if it has an end state and decision dates.

A good hybrid sequence looks like this:

  1. Stabilize Day-1 and TSA dependencies.
  2. Build common reporting for revenue, EBITDA, cash, working capital, and backlog.
  3. Standardize master data where value depends on it: suppliers, items, customers, chart of accounts.
  4. Harmonize policies and controls: procurement approvals, credit rules, close calendar, inventory counts, access controls.
  5. Migrate the entities or processes where the value case is proven.
  6. Revisit full consolidation after the first value gates are met.

The hybrid path fails when it has no expiration date. The steering committee should set explicit review points: 90 days after close, after the first audited close, after TSA exit design, and before the next budget cycle.

At each point, ask whether the cost of keeping multiple ERPs is now higher than the cost and risk of standardizing.

Evidence asks before locking the answer

The executive team should not approve an ERP strategy from a slide with boxes and arrows. It needs evidence.

Ask for these artifacts in the first two weeks:

  • ERP instance map by legal entity, plant, country, business unit, and process
  • transaction volume by ERP for orders, invoices, purchase orders, production orders, inventory movements, and journal entries
  • master data quality report for customers, suppliers, items, chart of accounts, bills of material, and open orders
  • close calendar, manual journal volume, reconciliation backlog, and consolidation process
  • TSA terms for ERP access, support hours, project work, data extraction, fees, step-ups, and exit milestones
  • interface inventory, including EDI, banks, tax, WMS, MES, CRM, payroll, planning, and reporting feeds
  • customization and local extension inventory by process area
  • ERP run cost, license terms, support partners, and known upgrade deadlines
  • named process owners and realistic availability for design, testing, data cleanup, and cutover

The point is not to produce a perfect inventory. The point is to test whether the preferred answer survives the facts.

Decision triggers

Use the following triggers to force the ERP strategy discussion out of opinion mode.

Choose one ERP if:

  • more than 60% of deal value depends on common procurement, finance, inventory, or order management controls
  • more than two ERPs support the same customers, suppliers, products, or legal entities
  • reporting bridges require manual reconciliation for EBITDA, cash, or working capital beyond two close cycles
  • run cost and support fragmentation create a clear EBITDA case within the hold period
  • the business has capacity for process design, data cleanup, testing, and adoption without delaying the first-year plan

Keep multiple ERPs if:

  • business units have low process overlap and clean P&L accountability
  • the value case can be captured through reporting, master data, and policy harmonization
  • ERP migration would delay higher-return initiatives such as pricing, procurement, plant performance, or customer retention
  • regulatory or manufacturing requirements make standardization costly relative to the value available
  • the investment horizon does not support the payback period

Choose a hybrid path if:

  • TSA exit requires a near-term stand-up but the long-term platform choice needs more evidence
  • finance and procurement need standardization before operations can absorb migration
  • master data quality is too weak for a big-bang move but good enough for a controlled reporting layer
  • the company needs value in the first two quarters and cannot wait for full ERP consolidation
  • leadership wants one ERP eventually but cannot name the capacity, funding, and business owners today

How best teams handle the decision

Best teams make ERP strategy a deal governance topic, not an IT workstream.

They start with value owners. The CFO owns finance close, controls, and reporting. The COO owns supply chain, production, inventory, and service levels. The CPO or procurement lead owns supplier and spend value. The CIO owns architecture, integration, security, data migration, and technology delivery. The integration lead owns sequencing and trade-offs.

They also separate the decision into three layers:

  • Control layer: reporting definitions, master data ownership, access controls, close calendar, procurement policies
  • Process layer: order-to-cash, procure-to-pay, plan-to-produce, record-to-report, hire-to-retire
  • Platform layer: SAP, Oracle, Dynamics, NetSuite, Infor, or another system

Most value can start in the control layer. Some value requires process harmonization. Only some value requires immediate platform migration. That separation stops the company from using ERP replacement as the answer to every integration question.

Best teams then create a “no-regret” backlog for the first 90 days:

  • clean supplier, item, customer, and chart-of-accounts data
  • define common reporting and KPI rules
  • identify interfaces that must be owned post-close
  • document close dependencies and manual journals
  • lock TSA terms and exit milestones
  • name process owners and decision rights
  • stop low-value local ERP changes that create later migration debt

Those moves create value under any ERP strategy.

The Monday-morning close

On Monday morning, do not ask the CIO for an ERP recommendation. Ask the deal leadership team to make a sequenced operating decision.

In the next 10 business days:

  1. The CFO should list the finance, reporting, and control outcomes needed in the first two closes.
  2. The COO should identify which supply chain and operations processes must be common to hit the value plan.
  3. The procurement lead should separate savings that need one ERP from savings that need only common data and policy.
  4. The CIO should produce the ERP instance map, interface list, master data quality view, TSA constraints, and capacity assessment.
  5. The integration lead should bring the trade-off to the steering committee: one ERP now, multiple ERPs with a control layer, or hybrid with value gates and decision dates.

The answer should fit on one page: value at stake, constraints, first 90-day moves, next decision date, and what must be true to move to the next phase.

One ERP may be the right destination. It should not become the excuse for delaying value. Multiple ERPs may be the right operating model. They should not become the excuse for weak controls. The best post-deal ERP strategy is the one that captures value on the deal clock while leaving the company with a system path it can actually execute.

← Back