Most integration plans are written during diligence by people who have seen the target's system inventory but not its operations. They tend to treat consolidation as the goal and reduce the open questions to order and timing. That is the assumption that makes them wrong. Consolidation is expensive, disruptive, and in several categories of system it damages the thing the acquisition was supposed to buy.
A more useful plan starts from the opposite default: nothing merges unless there is a reason that survives contact with the acquired business. Some reasons are strong and immediate. Most are weaker than they look on a slide. What follows is how to tell them apart, in the order the decisions have to be made.
What actually has to be consolidated, and when
Urgency comes from obligation, risk, or a dependency that blocks something else, not from the discomfort of running two of something. Reporting obligations are real and dated. Access control is a live exposure from the moment the deal closes. Almost everything else can wait long enough for you to learn how the acquired business operates, and that learning changes the answer often enough to be worth the delay.
| System category | Typical urgency | Default decision | Risk if forced early |
|---|---|---|---|
| Identity, email, and access control | High, on day one | Consolidate directory and access management | Departed staff keep access; new managers cannot grant or revoke it |
| Financial consolidation and reporting | High, at the first close after the deal | Consolidate the reporting layer; keep the acquired ledger running beneath it | A close that cannot be completed, and numbers nobody can defend |
| Core operational systems (dispatch, production, service delivery) | Low, evidence-driven | Leave alone until the two operating models are shown to match | Throughput and margin fall in the business you just bought |
| Customer-facing systems (ordering, portal, support) | Low | Leave alone; unify branding and contact routes only | Churn during the period you can least afford it |
| CRM and sales pipeline | Medium, before any joint selling | Absorb once stage definitions and pipeline maths are reconciled | The combined forecast becomes unusable and reps stop entering data |
| Payroll, HR, and benefits administration | Medium, driven by contract and plan dates | Sequence with your HR, legal, and finance advisors rather than with IT | Pay and benefits errors, which are unrecoverable trust events |
| Procurement and vendor management | Medium, at contract renewal | Absorb opportunistically as agreements come up for renewal | Terms renegotiated from a weaker position for no operational gain |
| Data warehouse and analytics | Medium | Consolidate definitions and the reporting layer, not the source systems | Two different definitions of the same metric get averaged into nonsense |
These are defaults, not answers. Stating them as defaults means someone has to argue a specific system out of its category, in writing, with a reason. That is a better conversation than a backlog where every system is equally in scope.
Adopt, absorb, or leave alone
For every system in the acquired estate there are three honest outcomes. Naming which one applies, and why, is most of the work. The failure mode is a fourth outcome nobody chooses on purpose: both systems stay live, both are half-integrated, and neither has an owner.
Adopt: their system becomes the standard
Choose this when the acquired system is materially better at the job, when the acquired business is the larger user of that capability, or when their process is the one you intend to spread. Buyers resist adopting because it feels like losing, but it is common in acquisitions made specifically to obtain an operating capability. The test is simple: if you would have built what they have, adopt it.
Absorb: their system retires into yours
Choose this when the capability is genuinely undifferentiated, your system already handles their volume and variation, and the migration cost is knowable. Absorption is the right call less often than integration plans assume, and it is the option most likely to be justified by licence savings smaller than the migration budget.
Leave alone: two systems, one interface
Choose this when the businesses run differently, when the system is close to revenue, or when you do not yet know enough to decide. Leaving a system alone is not indecision if you pair it with two things: a reporting bridge so the parent can see the numbers, and a review date. Most operational systems should sit here for at least the first year.
Identity and access is the day-one work
Identity is the one area where moving fast is the low-risk option. On the day the deal closes you inherit an access estate you did not build: shared logins, administrator accounts belonging to former staff, vendor accounts with standing access, and personal cloud storage holding operational data. None of that improves with time.
- An inventory of every system with a login, including the ones IT does not manage
- A named owner and an administrator list for each, reconciled against current payroll
- Removal of accounts for people who have already left, done before anything else
- Elimination of shared logins on any system that touches money, customer data, or safety
- Multi-factor authentication on email, remote access, and financial systems first
- A single directory as the source of truth for joiners, movers, and leavers, even while the underlying applications stay separate
- A short list of the systems where the acquired team's access to your environment is required, and the minimum grant that achieves it
Federating identity does not require consolidating applications. Putting both estates behind one directory with single sign-on gives you control, an audit trail, and a clean offboarding path while leaving every operational system exactly where it is. It is the highest-return integration work available in the first month.
The data questions that decide the schedule
Every consolidation program is eventually a data reconciliation program. Three questions come up in nearly all of them, and each is a business decision wearing a technical costume.
Customer overlap is the first. Two companies in adjacent markets will share customers, and the shared ones are usually the largest. Deduplication needs matching rules, a survivorship rule for which record wins, and a named person who adjudicates the ambiguous cases. It also needs a commercial answer to a question engineering cannot settle: when both businesses have a contract with the same customer at different prices, which one applies, and who tells the customer.
The chart of accounts is the second. Two ledgers built independently will not map cleanly, and the mapping changes how the combined business measures itself. Work it with your finance team and their advisors, publish the mapping, and expect to keep a translation layer for more than one reporting cycle.
Product and pricing catalogues are the third, and usually the worst. Different SKU schemes, different units of measure, different discount and bundle logic, and rules that live in the heads of two sales teams rather than in either system. Reconciling catalogues is the work that quietly consumes quarters, so scope it early even if you plan to leave both operational systems alone.
The acquired team is a dependency, not a redundancy
The engineers who built and maintain the acquired systems are usually the only people who understand them. Documentation, where it exists, describes an earlier version. They are also the people with the most transferable skills, the least attachment to the new owner, and the clearest view that a consolidation plan may end their role. That combination means the knowledge you need most is held by the people most likely to leave first.
- Treat knowledge capture as delivery work with named owners and dates, not as documentation someone will get to
- Record walkthroughs of each critical workflow, including the manual steps and workarounds that never made it into a diagram
- Have your engineers pair on real production work rather than sit through presentations
- Ask what the system does that nobody outside the team knows about, and write the answers down
- Identify single points of knowledge explicitly and reduce them in priority order
- Discuss retention arrangements with your HR and legal advisors early, because the useful window is short
The first ninety days
The first quarter should buy you information and reduce risk. It should not attempt a migration. This is the order we work in.
- 1
Close the access gaps: remove departed accounts, enforce multi-factor authentication on email and financial systems, and inventory administrator access.
- 2
Build the system inventory the diligence pack did not contain, including the spreadsheets, shared mailboxes, and personal tools that carry real process.
- 3
Map how the acquired business actually earns money, end to end, by watching the work rather than reading the process documents.
- 4
Stand up the reporting bridge so the parent can see financial and operational numbers without touching the source systems.
- 5
Start knowledge capture with the acquired engineers while they are still there.
- 6
Federate identity behind one directory, leaving applications where they are.
- 7
Reconcile the metric definitions the two businesses use before anyone compares them in a board pack.
- 8
Classify every system as adopt, absorb, or leave alone, with the reason and a review date recorded.
- 9
Quantify the customer overlap and agree who owns the commercial answer for shared accounts.
- 10
Publish a consolidation sequence with dependencies and a stated horizon, and name the person accountable for each item.
Setting a horizon you can defend
Integration models tend to assume consolidation completes inside a year, because that is the period the returns are modelled over. These programs routinely run considerably longer, and the overrun is rarely engineering. It is the decisions: which price list survives, whose process wins, who owns the combined customer.
Give the program a horizon that reflects that. State which consolidations are committed and dated, which are conditional on evidence, and which are explicitly not happening. Sequence the committed work so that revenue-generating systems move last and only after the operating models have been shown to match. A plan that says two systems will keep running for three years, with a bridge and an owner, is more credible than one that promises a single platform by year end and quietly slips every quarter.
Common questions
- Should we move the acquired company onto our ERP?
- Only if the two businesses genuinely operate the same way, which is less common than integration plans assume. Where the acquired business runs a different model (different customers, different fulfilment, different margin structure), forcing a shared ERP replaces the process that produced the results you bought. A reporting bridge gives you visibility without that risk, and it can stay in place for years.
- What should we consolidate first after an acquisition?
- Identity and access control, then financial reporting. Access is a live security exposure from the day the deal closes and gets no better with time, and reporting has dates attached to it. Operational and customer-facing systems should wait until you understand how the acquired business actually works.
- How long does post-acquisition systems consolidation take?
- Longer than the deal model says. Access and reporting work lands in the first quarter, but full consolidation of operational systems commonly runs two to four years, and some systems never merge because merging them was never worth it. The delays are decision-making rather than engineering, so the schedule tracks how quickly the business settles questions about process ownership.
- How do we handle duplicate customer records across both businesses?
- Start by measuring the overlap rather than estimating it, because the shared accounts are usually your largest. Deduplication needs matching rules, a survivorship rule for which record wins, and a named person to adjudicate the ambiguous cases. The harder part is commercial: when both entities hold a contract with the same customer at different prices, someone has to decide which applies and who tells the customer.
- What happens if the acquired company's engineers leave?
- You lose the only reliable description of how their systems work, and everything downstream slows down. Treat knowledge capture as scheduled delivery work in the first ninety days, with recorded workflow walkthroughs and your engineers pairing on real production tasks. Retention arrangements are worth discussing with your HR and legal advisors early, because the window in which they are effective is short.
- Is it acceptable to run two systems permanently?
- Yes, when each has an owner, a support path, and a bridge that feeds consistent numbers to the parent. Permanent coexistence is a legitimate outcome for operational systems in businesses that run differently. What is not acceptable is drift into that state by default, with two half-integrated systems and no decision on record.