We Acquired a Company. One System or Two?

Should we migrate an acquired company onto our systems?

Decide whose process wins before you decide whose software wins. Most advice sorts this question on whether the two businesses run similar processes, then leaves you to work out whether yours actually do. That assessment is the entire job, and it takes about a day.

The software question feels urgent because it has a price tag and a timeline. The process question has neither, which is exactly why it gets skipped and why the integration stalls six months later.

How do we tell if the two companies really run the same way?

Take one order from intake to cash in each company and lay the two paths side by side. Not the documented version. The real one, walked with the people who do it.

You are looking for the three or four steps where the two companies genuinely do it differently. Who approves credit. When a job is considered committed. What triggers an invoice. Where a change order gets recorded.

Everywhere the paths match, the system choice is mechanical. Everywhere they diverge, somebody has to lose, and that is a leadership decision rather than a technical one.

What happens if we skip that comparison?

You run both systems for two years. This is the common outcome, and it does not happen because anyone chose it.

It happens because neither side ever agreed to stop. The acquired team keeps their system for the handful of things it does better, the acquiring team keeps theirs, and people quietly maintain both. Data gets re-entered across the seam by whoever notices first.

The running cost never appears as a line item. It shows up as reconciliation time, as reporting that takes a week, and as two versions of the customer list.

Who should own the decision?

One named person with authority over process, not just technology. Post-acquisition integration needs someone who can tell a department that its way of doing things is not the way going forward.

If that person does not exist, the migration will be run by whoever is most comfortable with the software, and software people cannot make that call. They will build what they are asked to build and route around every disagreement rather than settle it.

What does a good answer actually look like?

A short written list. Here are the four steps where we differ; here is which version wins each one; here is who signed off. Everything downstream of that document is implementation.

Teams that produce it move fast, because the arguments already happened. Teams that skip it discover the same four disagreements one at a time, in the middle of a migration, with a consultant billing hourly while they get resolved.

When is running two systems the right call?

When the two businesses genuinely serve different customers with different economics, and the seam between them is thin. A holding company with independent operating units can reasonably run separate stacks.

The test is whether anybody has to move data across the seam by hand on a regular basis. If they do, you did not choose two systems. You chose one system with a person inside it.

As of 2026, the integration gap is wide across company sizes: industry surveys put the share of business applications that are actually integrated at under a third. Acquisitions make that gap visible faster than anything else does.