I do systems integration after M&A: reconciling two companies’ books into one truth, migrating or bridging operational systems, and giving the acquirer the reporting visibility the deal model assumed — without breaking either business mid-merge.
The deck said synergies; operations inherited two of everything
Two ERPs. Two charts of accounts. Duplicate customer and vendor records. Two teams with different definitions of the same metric. And a finance function doing manual consolidation in Excel every month-end, which means the numbers the board sees are both late and unverifiable.
Integration limbo has a real and compounding cost. Decisions get made on stale blended figures. Staff double-enter into both systems, which is demoralising and error-prone in equal measure. The audit now covers two messy systems and the handoffs between them, which is more than twice the work. And the acquirer’s playbook — usually some version of “move them onto our stack by Q3” — meets a reality where the acquired system runs live revenue nobody dares interrupt.
What does the engagement cover?
- Systems diligence. Pre-close ideally (the delivery practice does this properly); post-close triage is the more common call.
- Consolidation layer first. One reporting truth built over both systems within weeks, so the board gets real numbers while the migration is still being planned. This is the step most integration plans skip and most integration failures needed.
- Staged migration. Masters, then history, then live cutover with parallel runs — the method that moved a factory and a financial ledger without stopping either.
- Entity and record deduplication. Matching rules with a review queue, not manual effort at scale.
- Integration scorecard. Consolidated, bridged, migrated, remaining — reported against plan, so progress is a fact rather than a feeling.
Why the bridge comes before the migration
Because the two goals compete for the same scarce resource — the attention of the few people who understand both systems — and only one of them is urgent.
Consolidated reporting is urgent. The board needs numbers, the deal model needs validating, and every month of blended-guess reporting is a month of decisions made badly. Migration is important but not urgent, and rushing it is how live revenue breaks.
So build the reader first: a layer that pulls from both systems, normalises the charts of accounts, dedupes the entities enough to be trustworthy, and produces one set of numbers. It is not elegant, it is explicitly temporary, and it takes weeks rather than quarters. What it buys is the thing every integration needs and rarely has: time to do the migration properly, with the pressure off.
Then migrate deliberately — or decide, with evidence, not to. Plenty of acquisitions are better served by permanent bridging: separate legal entities in separate tax regimes with genuinely separate operations, where forced consolidation costs more than it returns. That decision should be made from data, in month three, rather than assumed in the deck.
The part that is not technical
The acquired team’s system knowledge is an asset the deal paid for, and the fastest way to destroy it is to arrive with a migration plan that treats their work as legacy debris. I have watched integrations lose their best institutional knowledge in the first six weeks because nobody asked the acquired engineers what the undocumented cron actually did — and then discovered, expensively, that it was load-bearing.
Treating them as the experts they are is not diplomacy. It is the cheapest risk mitigation available in the entire engagement.
Related reading
/industries/series-b-onward — the scale-stage version · /work/erp-migration — staged migration, proven · /services/delivery — diligence and rescue · /products/company-os — the multi-entity owner view
If month-end consolidation is a person and a prayer
The deal model deserves real numbers, and the bridge that produces them takes weeks rather than quarters. /contact.
Questions I actually get
How fast can consolidated reporting exist?
Weeks, because the bridge layer does not wait for the migration. That is the central sequencing insight: build one reporting truth over both systems first, which buys the breathing room to plan the migration properly instead of rushing it.
Should we keep both systems long-term?
Sometimes yes, and saying so is not a failure. Different countries, different tax regimes, a UAE entity alongside an Indian one — permanent bridging with selective migration is frequently the right answer. Forced consolidation for its own sake burns goodwill and delivers little.
The acquired team is resisting.
Usually because they are being treated as a problem rather than as the only people who know how the system works. Their knowledge is the asset the deal paid for; the process treats them as experts, and that single stance saves more integrations than any tooling choice.
Can you do the diligence before we close instead?
Ideally yes — pre-close systems diligence is cheaper than post-close triage and occasionally changes the price. But post-close is the common call, and the work is the same read with less optionality.
How do you handle duplicate customers and vendors?
Matching rules with a human review queue, not interns doing it by hand. Dedup done manually at scale produces its own errors, and those errors then propagate into the consolidated reporting you were trying to trust.
What does the board actually see?
An integration scorecard: what is consolidated, what is bridged, what is migrated, what remains, against plan. Integration progress is usually reported in vibes, which is how six-month plans become two-year realities without anyone deciding that.