Which systems survive an acquisition? Four tests

Four tests, applied to both estates, decide which systems survive an acquisition. Most integration plans skip all four and use a fifth rule instead: the buyer bought the company, so the buyer’s systems win.

That rule is right for most of the estate. It is rarely right for all of it, and the exceptions are expensive.

Should the acquired company always migrate into the buyer’s systems?

No. The default is correct often enough to feel like a principle, which is exactly what makes it costly. An acquired company may hold the better warehouse management system, the better product configurator, the better pricing engine, or simply cleaner master data in a domain where the buyer has struggled for years. Deciding by org chart rather than by evidence is one of the quieter ways deal value disappears.

The mechanics of moving data are the same in both directions. What changes is which estate gets profiled, and most integration programs only profile one.

Test 1: Is this data produced here, or derivable elsewhere?

Some data has exactly one origin. A production run record is created on the line that ran it and exists nowhere else in any recoverable form. Other data is a downstream representation of something already held somewhere upstream, which means it can be rebuilt rather than moved.

Classify every system in both estates on that basis. Strategic means it is the source of record for a domain, with heavy downstream dependency. Tactical means its data is derivable elsewhere, and it is therefore a candidate for consolidation. Profile every system in full rather than sampling, because a sample tells you what a system usually holds and misses the custom field that three business processes silently rely on.

Test 2: How many downstream systems and processes depend on it?

This is the blast radius question, and it is where lineage discovery earns its cost. There is a large difference between a system that can be switched off with a fortnight of rework and a system that cannot be switched off without destroying a capability nobody documented.

Map what each system feeds, which processes read from it, and what breaks if it stops. Vague risk becomes specific risk. A cutover plan built on a specific risk register survives contact with the business; one built on a vague sense that the finance team will be annoyed does not.

Test 3: Can the receiving system absorb it and run with fidelity?

Fidelity is the word doing the work here. A receiving system can usually accept the records. Whether it can run the same business logic on them, hold the same attributes, and produce the same outputs a downstream regulator or customer expects is a separate question, and it needs to be answered field by field before the direction is set.

Custom code and undocumented rules surface in this test. They should surface here, in profiling, rather than three weeks before cutover.

Test 4: What does each option cost to run and to reach?

This test needs two numbers rather than one. The cost to reach the target state is the migration project itself: mapping, remediation, testing, cutover, and the exceptions nobody budgeted for. The cost to run it is the license, the infrastructure, the support model, and the people who know how it works.

A tactical system that is cheap to retire and expensive to run is an easy call. A strategic system that is cheap to run and ruinous to leave is the one that generates the argument, and the argument is better held against four documented tests than against seniority.

What does the decision look like when all four are applied?

Direction becomes an output. In a typical transaction the pattern looks something like this.

Data domain

Buyer system

Acquired system

Target state

Finance and consolidation

Strategic

Tactical

Moves into the buyer

Customer master and CRM

Strategic

Tactical

Moves into the buyer

Procurement and vendor master

Strategic

Tactical

Moves into the buyer

Warehouse management

Tactical

Strategic

Buyer adopts the acquired system

Product configurator

Absent

Strategic

Buyer adopts the acquired system

Most rows point the same way. The two that do not are where the value sits, because those are the rows where the default answer would have been applied instead of the evidence.

Why does the trust posture matter more than the cutover?

The usual cost of a migration is not the cutover weekend. It is the year afterwards, during which nobody quite trusts the new system, and confidence gets rebuilt slowly through the same accumulation of experience that built it in the old one.

Validation and scoring at the attribute level rather than the record level changes that arithmetic. Every individual value in the destination carries its own confidence rating on the first day of go-live, so the destination does not start from zero. Migration is a moment. The trust posture is permanent.

Poor data quality already costs organizations an average of $12.9M a year according to Gartner. An integration is the single event most likely to add to that number, and the only one where the timing is entirely within the acquirer’s control.

How the estate actually moves

Phase 5 of the PolyPhaze white paper Enabling trusted outcomes covers the eleven agents that execute the move in either direction, and how the pre-close decision record survives the systems being replaced underneath it. Download the full post-merger integration ebook for the whole method.