Skip to content
Contact Us
Migration & Integration6 min

ERP After an Add-On: When to Consolidate, When to Federate

The IT-synergy line in your value creation plan assumes one ERP. Here's the 30-day fork — consolidate, federate, or modernize — that protects year-one EBITDA.

A split-screen illustration showing a monolithic ERP system versus a federated API-connected network of systems, symbolizing the decision between consolidation and federation.
Figure 01 A split-screen illustration showing a monolithic ERP system versus a federated API-connected network of systems, symbolizing the decision between consolidation and federation.
Answer summary

The practical answer

Short answer
The IT-synergy line in your value creation plan assumes one ERP. Here's the 30-day fork — consolidate, federate, or modernize — that protects year-one EBITDA.
Best fit
Industry: Private Equity. Function: IT & Operations
Operating path
Migration & Integration -> Turnaround & Restructuring -> Transaction Advisory Services -> Transaction Execution Services
Key metric
75% Failure rate of ERP implementations (Gartner)

The synergy line that quietly eats your first year

The add-on closed Friday. By Monday someone has already pulled up the value creation plan and pointed at the line everyone agreed to in the IC meeting: "IT synergies — $2M/year by Year 2, ERP consolidation." The platform runs SAP. The target runs NetSuite, or QuickBooks with a finance lead who holds the whole month-end together with twelve spreadsheets and personal discipline. The instinct is automatic: get the small one onto the big one, fast, and book the synergy.

That instinct is how you spend the most valuable year of the hold debugging field mappings instead of growing the asset.

Gartner's work on ERP strategy and implementation puts the share of projects that miss their original objectives in the 55–75% range. In most enterprises a stalled ERP program is a budget embarrassment. In a private equity hold, where you have maybe 36 to 48 months before you're building the data room again, an 18-month migration that slips to 28 isn't a line-item overrun — it's the value creation window, gone, traded for a project the next buyer's diligence team will flag as "in flight, unproven."

"One company" never required "one ERP"

The rule that a single legal entity needs a single system is a leftover from when ERP meant servers in a closet and a perpetual license you'd amortize for a decade. Force a fast-moving services or SaaS acquisition onto a heavy manufacturing-grade platform and you don't capture velocity — you tax it. The thing you paid a premium for, the target's ability to quote, deliver, and bill faster than the platform can, gets re-engineered into the platform's slower processes the day you flip the switch.

And the timing compounds it. McKinsey's analysis of the strategic value of IT in M&A documents how integration distraction pulls leadership off the commercial plan in the months right after a deal — exactly the window you've now asked your best operators to spend in workshops arguing about chart-of-accounts structure. The question worth asking out loud in that Monday meeting isn't "how do we get everyone on one system." It's "how do we hand the CFO a clean consolidated P&L without touching how the acquired team actually runs the business."

Three forks, and the two questions that pick for you

A system integrator will walk in with a deck titled "Digital Transformation" and a number with a comma in it. You don't counter that with enthusiasm; you counter it with two questions answered before they finish the pitch. How big is the target relative to the platform's revenue, and do the two businesses actually run the same way? Those answers route you to one of three paths — and only one of them is the SI's path.

Fork 1 — Consolidate (rip and replace)

Take this fork only when the add-on is small (under roughly a fifth of platform revenue) and the operating models are near-identical — a roll-up of the same kind of business, where the target's processes are immature and adopting the platform's is itself part of the value add. Here, "their way" isn't worth preserving; it's the thing you're standardizing. The one trap: confirm there's no genuine delivery edge buried in their workflow before you flatten it. Manage the license and contract cleanup deliberately — see Vendor Rationalization Post-Merger — so you're not paying for two ecosystems while you migrate.

Fork 2 — Federate (the answer more often than people admit)

Take this fork when the add-on is material (north of ~30% of revenue) or the models genuinely differ — platform sells hardware, target sells subscriptions; platform bills on milestones, target bills monthly. Leave the target on the nimble system it already runs well. Leave the platform on its heavy lifter. Connect financial reporting through an integration layer or a shared data warehouse so the close rolls up clean. You get data consolidation for the board packet without forcing process consolidation on the operators. The CFO gets one P&L; the acquired GM keeps running the asset the way that made it worth buying. This is the path the SI rarely pitches, because there's no eight-figure program in it.

Fork 3 — Modernize (both onto something new)

Reserve this for the case where both sides are on burning platforms — end-of-life, unsupported, a security or audit liability staring back from the diligence file. Only then do you migrate everyone to a new cloud ERP at once, accepting that you've now stacked technical risk on top of cultural integration risk. This is where overruns go vertical, the pattern we walked through in The Integration Synergy Trap. Justify it by the existential threat to the exit, never by tidiness.

The cost of choosing wrong isn't symmetric. Liberty Advisor Group benchmarks suggest successful consolidation can cut IT overhead by around 40% — real money. But a migration that fails and has to be remediated routinely runs several points of deal value, enough to erase the first year of EBITDA growth the thesis was counting on. You are not picking between "good" and "better." You're picking between a contained upside and a downside that shows up in the next valuation.

A matrix diagram plotting Target Revenue Size against Business Model Similarity to determine ERP integration strategy.
A matrix diagram plotting Target Revenue Size against Business Model Similarity to determine ERP integration strategy.

The first 30 days, before anyone touches a system

You don't get six months to decide. The fork has to be picked inside the first 30 days, because every week the SI's proposal sits unanswered, it gains political momentum. Three moves, in order.

Audit the data, not the demo

Ignore what the sales engineer shows you on screen. Trace the target's actual order-to-cash and procure-to-pay paths — every place data gets created, read, changed, or deleted. If a quote becomes an invoice by way of fifteen spreadsheets living outside the ERP, then "migrate them to SAP" is a fiction: you wouldn't be moving software, you'd be moving undocumented chaos into a rigid system that has no patience for it. Document the real workflow first, including the parts that only live in one person's head — that's the work in From Tribal Knowledge to Turnkey. Half the "we need one ERP" arguments evaporate once you can see how the target actually books revenue.

Ship a two-week reporting bridge first

Before anyone scopes a migration, prove you can hand the CFO a consolidated P&L through a scheduled export-and-load routine inside two weeks. Once that exists, the entire emergency justifying a rushed migration deflates — the board has its numbers, and you've bought the months you need to do the real decision properly. Solve visibility now; decide on unity later, on your timeline instead of the SI's.

Set the kill criterion before kickoff, in writing

If you do choose a migration, define the abort condition the day you start, not the day it's obviously failing. A clean rule: if the timeline slips more than 30% in the first quarter, you pause and reassess — full stop. A paused project is recoverable; a project nobody was willing to stop is the one that ends in a board apology. When a program is already wobbling, we run a structured Project Reset to triage it before sunk cost makes the call for you.

The thesis you underwrote was about cross-sell, new markets, or the team you acquired. It was never about everyone using the same invoice template. In most add-ons, a federated model with clean reporting connectivity returns more, faster, and with less risk than a multi-year consolidation — and it leaves the acquired business able to keep doing the thing you paid for. Pick the path that protects EBITDA. That is rarely the path with the biggest deck.

Continue the operating path
Topic hub Migration & Integration Post-merger integrations that hold customer and staff retention. 95% / 100% achieved on complex divestitures. Pillar Turnaround & Restructuring Integrations fail when they're run as status meetings. We run them as Integration Management Offices that own outcomes — the difference shows up in retention numbers. Service Transaction Advisory Services Operator-led buy-side and sell-side diligence for technology middle-market deals. Financial rigor, technical diligence, and integration risk in one workstream. Service Transaction Execution Services Integration management, carve-outs, system consolidation, and post-close execution for technology acquisitions that must turn thesis into EBITDA. Service Turnaround & Restructuring Services Crisis intervention, runway extension, project recovery, technical rescue, and restructuring support for technology middle-market firms.
Related intelligence
Sources
  1. Gartner. (2024). ERP Strategy and Implementation Failure Rates.
  2. McKinsey & Company. (2023). Understanding the Strategic Value of IT in M&A.
  3. Liberty Advisor Group. (2024). Post-Merger ERP Consolidation Trends.
Move on this

A 14-day operator-led diagnostic, before the gap is priced into your multiple.

No retainer until we agree on the work.

Request a Turnaround Assessment →