By Bala Mathivanan · July 2026 · Based on leading ERP integration through multiple acquisitions, including unifying two separate ERP estates for cross-border group reporting.
The deal closes, and within a week someone senior says it: "We need to get them onto our system." It sounds decisive. It's usually the most expensive sentence of the whole integration.
I've sat on the operator's side of this — carrying the IT budget through acquisitions, running the systems while the businesses merged around them. The pattern that works isn't a forced migration. It's a sequence. Here's the first 90 days of it.
The acquired business runs on its ERP the way a body runs on its spine. Rip it out early and you don't get integration — you get an operation that can't ship, invoice or close its books, at the exact moment leadership is watching most closely.
So the first month is read-only. Map what actually exists: which system holds customers, items, pricing, stock; who keys what in, and where the spreadsheets live that nobody mentioned in due diligence (there are always spreadsheets). You are building an honest picture of two operations — not designing the target yet.
What leadership actually needs first is not one system. It's one picture: group revenue, margin, stock and order book, on one page, from both ERPs, that everyone trusts. That's an integration and reporting problem, and it's weeks of work — not the year that a migration takes.
When we faced two separate ERP systems across borders, the move that paid off wasn't merging them — it was unifying the reporting layer first, giving leadership a single reliable view of the group while both businesses kept trading undisturbed underneath it. The pressure to "do something about the systems" evaporates once the board can see the whole group in one report.
The unglamorous work that makes this possible is master data mapping: agreeing what a customer, an item and a cost centre mean across both businesses. Skip it and every number you consolidate is quietly wrong.
Where the two businesses genuinely touch — stock moving between them, intercompany invoicing, shared suppliers — build interfaces for those specific flows. A well-built integration point between two ERPs is boring, reliable and reversible. A big-bang migration is none of those things.
This is also when the real consolidation question gets an evidence-based answer. Sometimes the right target is one ERP. Sometimes it's two ERPs with a shared integration platform on top — one enquiry-to-order workflow across every entity, with each business keeping the system that fits it. We've built exactly that across four entities in four countries — a group operating as one business, without a single risky migration on the critical path.
When those three are true, the migration that once looked terrifying becomes a project. When they're not, the merge-them-fast instinct just converts an acquisition premium into an operational outage.
The short version: visibility first, one report before one system, integrate flows before databases — and let consolidation earn its place on the roadmap.