Every acquisition arrives with a synergy number attached, and a surprising share of that number depends on a decision nobody in the deal team wanted to own: what happens to the two ERP systems. Procurement savings require a consolidated view of spend. Headcount savings in finance require a single close process. Cross-selling requires a shared customer master. Working capital improvements require common terms and one collections function. None of that is available while the acquired business runs on its own platform with its own chart of accounts. There are three honest options, and the mistake most groups make is not choosing the wrong one — it is failing to choose deliberately, then discovering eighteen months later that the default has quietly become permanent.
The three options
Absorb. Migrate the acquired business onto the acquirer's platform. Fastest route to synergy capture, cleanest end state, hardest execution. The acquired organisation carries the entire disruption: new processes, new system, new reporting, all while being expected to hit the numbers that justified the purchase. Absorption works when the acquirer's platform genuinely fits the acquired business model, when the acquired entity is materially smaller, and when the acquirer has implementation capability that is not already committed elsewhere. Coexist. Leave both platforms running and integrate at the reporting layer — consolidated financials, a mapped chart of accounts, group-level dashboards. Lowest disruption, fastest to a reportable result, and the option that preserves optionality if the business might be sold again. The cost is that most operational synergies stay unavailable: you cannot net inventory across two systems that do not share item masters, and you cannot run one payables team efficiently against two sets of approval workflows. Coexistence also has a well-documented failure mode — the temporary state becomes structural, and five years later the group is running four ERP systems because every acquisition chose coexistence on the same reasoning. Replatform. Move both businesses to something new. Defensible when the acquirer's own system was already at end of life, when the combined business is materially different in shape from either predecessor, or when the deal itself was the trigger for a transformation the board had been deferring. It is also the option most likely to consume the entire synergy case in programme cost and management attention, and it converts an integration problem into an implementation problem with its own failure modes.
| Choice | Reason to evaluate it | Risk to test |
|---|---|---|
| Absorb | The acquirer's platform fits the acquired operating model. | Disruption, migration capacity and statutory continuity. |
| Coexist | The value can be captured through governed shared information. | Master-data/workflow boundaries and an explicit review date. |
| Replatform | Both legacy platforms or the combined model justify replacement. | Programme cost, management capacity and the binding exit dates. |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
Choosing on evidence rather than preference
Four tests separate the options, and they should be run in the first sixty days rather than debated for six months. Where does the synergy actually come from? If most of the value is procurement leverage and finance headcount, absorb or replatform. If it is product, geography or licences, coexistence may capture almost everything without touching either system. How different are the operating models? A distribution business and a project-based services business have genuinely different transaction shapes. Forcing one onto the other's configuration produces workarounds that persist for a decade. What is the deadline that actually binds? Transitional service agreements with a seller expire. Licence and support arrangements lapse. Regulatory reporting obligations for the combined group start on a date. Those dates, not the integration plan, determine what is feasible. Who is going to do the work? The single most common cause of failed integrations is assuming the finance and IT teams can run the integration alongside a close cycle and a new reporting regime. If there is no dedicated team with backfill for their day jobs, the plan is decorative. A useful discipline: whichever option is chosen, write down the date at which it will be reviewed and what evidence would change the decision. Coexistence chosen deliberately with a two-year review is a strategy. Coexistence chosen by inaction is technical debt with a synergy shortfall attached.
Practical Guidance for Post-Merger Integration Planning
- Map synergy sources to the systems required to capture them. If the value does not require a shared platform, do not buy one.
- Decide the chart of accounts before anything else. It determines consolidation, reporting, migration scope and how much of the acquired entity's history remains usable.
- Fix the transitional service agreement exit dates early and plan backwards. These are the only genuinely immovable deadlines in most integrations.
- Treat master data as the critical path. Customer, supplier and item master reconciliation takes longer than anyone estimates and blocks everything downstream.
- Staff a dedicated integration team with backfill. Integration performed in evenings and weekends by the people also running the close will slip and will burn the team you just acquired.
- Keep one statutory reporting path working at all times. No integration timeline justifies missing a filing in any jurisdiction.
- Decide what history migrates and what stays in an archive. Full historical migration is expensive, rarely necessary beyond statutory retention, and a frequent source of scope creep.
- Write a review date into whichever option you choose. Deliberate coexistence is a strategy; accidental coexistence is how groups end up with five ERP systems.
The Regional Dimension
Mergers and acquisitions in the Gulf carry structural features that change the arithmetic, and a template integration plan written for a single-country group will mislead you. The entity structure is the first complication. Regional groups are rarely one company — they are a set of mainland companies, free-zone entities, a Saudi subsidiary, sometimes a DIFC or ADGM vehicle, and occasionally an offshore holding company. Acquiring a regional business usually means acquiring several legal entities with different licences, different statutory reporting and different functional currencies. Absorption is therefore not one migration but a sequence of them, each with its own trade licence, tax registration and audit implications. Free-zone entities in particular can have restrictions on the activities they may perform, which sometimes means the operational consolidation the synergy case assumed is not legally available without a licensing change. Compliance timing is the second. Any integration touching payroll must keep wage protection submissions working continuously, because a missed or malformed submission has immediate consequences. Saudi e-invoicing clearance runs against the authority's specification in real time, so a cut-over that breaks invoice clearance stops the acquired business from invoicing at all. UAE VAT groupings, corporate tax registration and transfer pricing documentation all change when entities combine, and the finance calendar for those changes is set externally. Workforce factors are the third and are routinely underestimated. Employment is tied to the sponsoring entity, so moving people between group entities is a visa and labour file exercise rather than an HR system change, with real lead times. End-of-service gratuity accruals are entity-specific liabilities that must be carried correctly through any migration. Nationalisation targets — Emiratisation and Saudisation — are measured per entity, so consolidation changes the denominator and can create an unexpected compliance gap. And regional turnover is high enough that the knowledge of how the acquired company's system was configured may leave during the integration; interviewing and documenting that configuration in the first month is cheap insurance. One further note on partners: both businesses are likely to be supported by implementation partners, sometimes the same one, and the partner has a commercial interest in the option chosen. Independent facilitation of the decision is worth the cost.
The objection worth taking seriously
The case against early, decisive integration is stronger than integration specialists usually admit. Migrating an acquired business onto the acquirer's platform destroys operating knowledge that lived in the old configuration, disrupts the customer-facing processes the acquirer paid for, and consumes the attention of exactly the managers who are supposed to deliver the growth case. A number of acquisitions have underperformed not because the thesis was wrong but because the acquired business spent its first two years in a system migration. Where the acquisition was made for capability, culture or a growth trajectory, imposing the acquirer's platform can be the single most value-destructive act available. There is also a real argument that consolidated systems are over-valued relative to consolidated information. Modern integration and consolidation tooling makes it possible to get group reporting, shared analytics and even common approval workflows without a single ERP, and the cost of that approach is frequently lower than a migration — particularly for groups that acquire regularly and would otherwise be permanently mid-integration. The balanced conclusion: the integration decision should follow the synergy case rather than an architectural preference. Where the value requires shared transactional data, consolidate and commit the resources. Where it does not, integrate the reporting layer, leave the operating systems alone, and be explicit that this is a choice with a review date rather than a deferral. What is indefensible is the common middle path — a half-completed absorption that runs out of budget, leaving two systems, a partial migration, and a reconciliation process nobody owns.
Common Questions
How quickly should the decision be made?
Within the first sixty to ninety days. The decision drives resourcing, the transitional service agreement exit plan and the finance operating model, and delaying it means coexistence becomes the default before anyone has evaluated it.
Can the acquired business keep its own chart of accounts?
Only with a maintained mapping to the group structure, and the mapping needs an owner. Two charts without a governed mapping produce consolidation that is rebuilt manually every month and a group reporting function that spends its life reconciling rather than analysing.
Is replatforming both businesses ever the right answer?
Yes, when the acquirer's own system was already failing, when the combined business is genuinely different in shape, or when a regulatory change forces a rebuild anyway. It is the highest-risk option, and it should be funded as a transformation programme rather than hidden inside an integration budget.
Where does AI help in post-merger integration?
Mostly in the least glamorous and most time-consuming work. Master data reconciliation — matching customer and supplier records across two systems where names are spelled differently, transliterated inconsistently, or entered with different legal suffixes — is well suited to modern matching tools and is usually the critical path. The same applies to mapping two charts of accounts, classifying historical transactions, and extracting terms from the acquired company's contract population so that procurement synergies can actually be quantified. The caution is that every one of these outputs needs a human review step and an audit trail, because an incorrectly merged supplier record becomes a payment to the wrong bank account, and a mis-mapped account becomes a restatement.
Post-Merger Integration Planning — absorb, coexist or replatform are all defensible; what destroys the synergy case is letting the default win by never deciding.