What an acquisition does to the system landscape
The acquired business arrives with a complete operating stack that works. It has its own ERP, its own warehouse and production systems, its own reporting, and staff who know how to run all of it. None of that stops working on the day the deal closes.
What breaks is everything above it. Group finance cannot consolidate two charts of accounts that were never designed to reconcile. Procurement cannot see combined spend with a supplier both businesses use. Nobody can answer what total stock of a shared component the group holds, because each system counts it under a different part number.
These are not technical failures. Each system is internally correct and reporting accurately about its own half of the business. The problem is that the group is now one commercial entity and two data landscapes, and only the first of those is visible to the board.
Why does post-merger integration take so long?
Migration work is bounded by process differences, not by data volume. Moving the acquired business onto the parent's ERP means agreeing one chart of accounts, one part numbering scheme, one customer master, and one set of operational processes. Each of those is a negotiation between teams who both have working answers.
The timeline stretches further when the acquired business is operationally different. A parent running make-to-stock and an acquisition running make-to-order do not have a shared configuration waiting to be found. One of them changes how it works, which is a change management project rather than a data migration.
Meanwhile the business cannot pause. Orders ship, month-end closes, and customers expect service continuity through a transition they did not ask for. This is the same reason ERP modernization runs in phases rather than as a single cutover, and an acquisition adds a second organization's worth of resistance.
The cost of waiting for a single system
The default plan holds the value of the acquisition hostage to a migration date. What that costs, roughly in the order the group feels it:
- Manual consolidation every close: finance reconciles two charts of accounts by hand each quarter until the second ERP is retired
- Savings that expire unclaimed: the combined buying power of both businesses goes unused while supplier contracts renew at their old terms
- Senior people tied up: long consolidation programs consume the same operational staff the business needs for trading
- Knowledge walking out the door: attrition rises while the acquired business is neither fully independent nor fully absorbed, and the leavers understood its systems
- Board confidence draining: each quarter of reconciled-by-hand numbers makes the deal case harder to defend
Connecting first inverts the sequence. Reporting works early, the consolidation decision can be made calmly on its merits, and in some cases the group discovers the second system is worth keeping.
What post-merger integration must deliver first
Most of what the deal case promised does not actually require one system. It requires shared data across two.
- Consolidated financial reporting: mapped account structures flowing into one group view, without waiting for a single chart of accounts
- Combined supplier spend: purchase data from both entities normalized against one supplier master, which is where negotiated savings come from
- Group inventory visibility: shared components matched across two numbering schemes, so stock in one entity can serve demand in the other
- Customer overlap: a view of accounts both businesses already sell to, which is usually where cross-selling synergies were priced
- Shared master data: an agreed definition of the entities that matter, established once and applied to both landscapes
Each of these can be delivered in weeks against systems that stay exactly where they are. That matters commercially, because the synergies get measured against the deal timetable, not the IT roadmap.
How an integration platform connects multiple entities
The alternatives are worth naming, because each is used and each has a limit. A data warehouse can consolidate reporting without touching operations, which answers the board's question but does nothing for shared stock or supplier data in daily use. Point-to-point links between the two ERPs solve one flow and multiply as more are needed. Manual consolidation in spreadsheets is what most groups actually do, and it scales with headcount rather than with tooling.
An integration platform-as-a-service (iPaaS) sits between both landscapes and lets each keep running while shared data moves between them. That raises a fair objection. If two entities now share a layer, does a migration inside one put the other at risk?
The answer depends on how the layer is structured, which is what the multi-entity model exists to solve. Alumio Spaces for group holdings gives each entity its own isolated environment while the central team keeps one view across the group. On the Alumio iPaaS that shape does four things for a group mid-integration:
- Entity isolation: each business runs in its own Space with a dedicated Data Engine, so an ERP migration or replatform inside one entity cannot destabilize the others
- One definition across the group: a Transformer normalizes part numbers and supplier records in transit, so a shared component is recognizable to both entities without either system changing
- Central oversight and an audit trail: real-time status and health monitoring per Space in one dashboard, with a record of what moved between entities and when, so intercompany reconciliation stays defensible
- Phased rollout with group standards: a new entity is provisioned with its own environments and role-based access in minutes, using shared templates where entities match and local configuration where they differ
Those flows are configured rather than hand-built per system pair, with the Code Transformer available where configuration cannot express a rule. The next acquisition connects to something that already exists.
Post-merger integration that gets cheaper each time
Groups that acquire regularly stop treating consolidation as automatic. They connect the new entity quickly, get reporting and shared data working, and then decide system by system whether migration is worth its cost. Sometimes it clearly is, and sometimes an acquired business runs a system that suits its operation better than the parent's.
That reframes what the integration layer is for. It stops being a bridge to be dismantled once migration completes and becomes the permanent place where entity-level differences are reconciled into a group-level view.
What the group gets from building it is reporting that holds up to the board within the first quarter rather than the second year. Buying power lands while the supplier contracts are still worth renegotiating. And for a group growing by acquisition, each deal costs less to absorb than the last. The layer the previous entity connected to is still standing when the next one arrives.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
