Use case
Merging two businesses' systems after an acquisition
The deal closed and now there are two of everything. The expensive mistake is consolidating quickly onto whichever system the acquirer happens to use.
The situation
A deal completes and the operational reality arrives. Two CRMs holding overlapping customers. Two finance systems on different charts of accounts. Two ways of quoting, two product catalogues that name the same items differently, and two teams each certain their way is better.
Meanwhile the reporting obligation is immediate. Someone has to produce consolidated numbers for a board that expects them next month, and neither system can produce the other half.
The pressure is toward speed, and speed here has a specific danger. The acquired business was bought for a reason — a customer base, a capability, a way of operating — and a rapid migration onto the acquirer's systems is one of the more reliable ways to damage exactly that.
How it shows up
- Consolidated reporting is being produced by hand in a spreadsheet every month.
- Nobody can say how many customers the combined business has, because the same customer exists in both systems under different names.
- Salespeople in the two businesses have unknowingly approached the same account.
- Product and service names do not correspond, so combined revenue cannot be split by category.
- Two sets of contracts and terms exist with no view of which customer is on which.
- Key people in the acquired business are being asked to work in an unfamiliar system and are visibly disengaging.
Symptom, cause and change
The most expensive mistake in this situation is treating a symptom as a diagnosis. These are the three columns kept apart.
Why it happens
- Diligence looked at numbers, not systems
- Financial and legal diligence rarely examines operational tooling in enough depth to plan an integration.
- No integration owner was appointed
- Responsibility sits between two IT functions and two operating teams, so nothing is decided.
- Reporting pressure forces the wrong sequence
- The urgent need for consolidated numbers drives a full migration when a reporting layer would do.
- Cultural assumption that the acquirer's way wins
- Systems get chosen by who bought whom rather than by which one supports the combined business.
- Data differences were underestimated
- Two catalogues, two chart structures and two customer masters take longer to reconcile than anyone allows for.
How we approach it
Separate the reporting problem from the systems problem
The board needs consolidated numbers; it does not need a single finance system to get them. A reporting layer that reads both sources and maps them to a common structure can be built in weeks, and it removes the pressure that otherwise forces a premature migration decision.
Establish what was actually bought
If the acquisition was for a customer relationship, the CRM and the account teams are what must not be disturbed. If it was for a capability, the operational systems supporting it matter most. This determines what gets left alone, and it should be written down explicitly because it will be argued about later.
Reconcile customers before anything else
A single customer master — knowing that this account in one system is the same organisation as that account in the other — unlocks combined reporting, prevents duplicate approaches, and is a prerequisite for any later consolidation. It is also the piece that takes longest, so it should start first.
Map the catalogues to a common structure
Not necessarily merging them: a mapping layer that lets both continue while reporting into one structure is frequently enough for a year or more, and it is dramatically cheaper than harmonising two product masters under time pressure.
Consolidate only where there is a clear operating reason
Two finance systems are genuinely painful and usually worth consolidating. Two CRMs may be tolerable for a long time if the teams sell to different markets. The default should be to leave working systems alone until there is a specific reason beyond tidiness.
Sequence migrations for the lowest-risk first
When consolidation is right, start with the function where a mistake is recoverable and the teams are least central to what was acquired. Doing the highest-value customer-facing system first, at the point of maximum organisational uncertainty, is the pattern that damages deals.
What changes
- Consolidated reporting within weeks
- Delivered by a reporting layer rather than by a migration that would take a year.
- One view of the customer
- Duplicate accounts identified, so nobody approaches the same organisation twice and combined revenue is real.
- The acquired capability is preserved
- Because the systems supporting it were deliberately protected rather than absorbed by default.
- Consolidation decisions made on operating grounds
- Each one justified by a specific problem rather than by a preference for uniformity.
- Key people stay
- Retention improves markedly when the acquired team is not immediately forced into unfamiliar tooling.
- A defensible integration plan
- With sequence, owners and dates, which is what the board actually wanted when it asked for the numbers.
Where it goes wrong
The most damaging pattern is migrating the acquired business onto the acquirer's systems immediately, on the grounds of consistency. It disrupts exactly the operation that was purchased, at the moment when the people running it are already deciding whether to stay.
The second is treating the reporting deadline as a systems deadline. They are different problems with different solutions, and conflating them forces a year-long project into a two-month window.
The third is deferring the customer reconciliation because it is tedious. Everything else depends on it, and it takes longer than anyone estimates.
The fourth is consolidating for tidiness. Two systems that work and serve different markets can coexist for years, and the cost of forcing them together is frequently larger than the cost of the duplication.
The fifth is leaving integration ownership between two IT functions. Without one named owner with authority over both sides, decisions do not get made and the spreadsheet becomes permanent.
The sixth is ignoring data protection consequences. Combining two customer databases involves purposes, notices and lawful bases that may not transfer automatically, and this is worth confirming with advisers before the merge rather than after.
What else you could do instead
Full consolidation is one option among several, and the cheapest workable answer is frequently not the tidiest one.
- Leave both and build a reporting layer
- Often the right answer for the first year or two. It solves the visible problem quickly and defers the expensive decisions until the combined business understands itself better.
- Consolidate finance only
- A common middle path. Finance duplication is genuinely costly and the teams affected are usually less central to what was acquired.
- Full consolidation onto one side
- Justified where the two businesses genuinely do the same thing in the same market. Rare in practice, and frequently assumed when it is not true.
- Move both onto something new
- Occasionally sensible where neither system suits the combined business, and it avoids the political problem of one side winning. It is also the largest and slowest option and should be chosen with that understood.
How we would know it worked
Before starting, record how long consolidated reporting currently takes each month, how many duplicate customer records exist across the two systems, and how many hours per week are spent on manual reconciliation.
During the work, track the proportion of customers reconciled to a single master and the proportion of revenue mappable to a common category structure.
Afterwards, the measures worth watching are elapsed time to produce board reporting, retention among the acquired team, and whether any consolidation actually reduced running cost as projected.
How long it takes and what it costs
A reporting layer that produces consolidated numbers from both sources is typically four to ten weeks and is usually the right first deliverable.
Customer reconciliation runs in parallel and takes as long as the data quality requires — commonly two to four months for a mid-sized business, and it is consistently underestimated.
Any system consolidation should follow those, not precede them, and should be scoped one function at a time. A programme that commits to full consolidation on a fixed date before reconciliation is complete is committing to a date it does not yet understand.
Estimates are labelled as estimates. Timelines here are planning ranges from comparable work, not commitments, and not measured client outcomes. We quote against a defined scope after a discovery call.
Services involved
Systems Integration
Making the systems you already pay for talk to each other, reliably, without a person in the middle re-typing things.
Read more →Data Engineering & BI
Getting numbers out of the systems that hold them, into one place, in a state somebody can actually make a decision from.
Read more →CRM & Sales Systems
The system of record for revenue: where leads land, how they are routed, what happens next, and whether anyone can see the truth of the pipeline.
Read more →Digital Transformation Consulting
Working out what to do, in what order, before anyone spends money building it.
Read more →Business Process Automation
Removing the manual steps between systems — the copying, re-typing, chasing and exporting that consumes hours nobody counts.
Read more →Cloud, DevOps & Infrastructure
The layer everything else runs on — deployed reproducibly, monitored properly, backed up in a way that has actually been tested.
Read more →Questions
The board wants consolidated numbers next month. What is realistic?
A reporting layer reading both systems and mapping them to a common structure — typically four to ten weeks, sometimes faster if the charts of accounts are close. What is not realistic is a finance migration in that window, and attempting one is how integrations go wrong.
Should we move the acquired business onto our systems?
Only where there is a specific operating reason. Doing it by default, for consistency, disrupts the operation you bought at the point when its people are deciding whether to stay. Start by writing down what you actually acquired and protecting that.
How long does customer reconciliation take?
Longer than anyone estimates — commonly two to four months for a mid-sized business, because the same organisation appears under different names, entities and spellings. It should start first precisely because it gates everything else.
Can we run two CRMs indefinitely?
If the teams sell to different markets, frequently yes, and for longer than people expect. The cost of duplication is visible and the cost of forced consolidation is not, which biases the decision in a direction that is not always correct.
Are there data protection issues in merging the databases?
Potentially. Purposes, notices and lawful bases do not automatically transfer with an acquisition, and combining two customer datasets is a processing decision. Confirm the position with your advisers before the merge rather than after it.
Who should own the integration?
One named person with authority across both sides. Leaving it between two IT functions is the most reliable way to ensure nothing is decided and the manual spreadsheet becomes the permanent solution.
What if both systems are bad?
Then moving both onto something new is worth considering, and it has the political advantage that neither side lost. It is also the largest and slowest option, so it should be chosen with the timeline understood rather than as a way of avoiding a difficult choice.
How do we keep the acquired team?
Largely by not immediately taking away the tools they know. Retention in the first year correlates strongly with whether the acquired business feels absorbed or supported, and system decisions are one of the most visible signals of which is happening.
What does it cost?
Quoted per phase. The reporting layer is deliberately scoped as a standalone deliverable, because it relieves the immediate pressure and buys the time to make the larger decisions properly.
Other situations
- Replacing spreadsheets with a real system
- Cutting cost per qualified lead
- Launching in a new European market
- Making company knowledge searchable
- Automating quote to invoice
- Recovering from a failed migration
- Inheriting undocumented software
- Passing a customer security review
- Opening a second location
Recognise this?
Tell us what it looks like in your business. We will tell you what we would do about it, and whether it is worth doing.
Get in touch