Post-Acquisition Systems Integration: Whose Process Wins?
Post-acquisition systems integration stalls when no one decides whose process survives. Here is the order-to-cash test that answers the platform question first.
Should we migrate the acquired company onto our system or run two?
Neither, until you answer a different question first: whose process survives. The systems decision is downstream of the process decision, and running those two in the wrong order is what turns a six-month integration into a two-year one. Pick the winning process and the platform question mostly answers itself.
Why does the standard integration advice stall?
Most guidance sorts on whether the two businesses run similar processes, then leaves you to determine that yourself. That determination is the actual work. Similar enough is not a data point sitting in either company's system. It is a judgment somebody has to make out loud, with authority behind it.
What does the order-to-cash test look like?
Take one order through each company, intake to cash, and lay the two paths side by side. Not the documented versions. The real ones, described by the people who run them.
You are looking for the handful of steps where the two companies genuinely do the work differently:
- Who can approve a price exception, and above what threshold.
- How a partial shipment gets recognized and billed.
- What happens when a customer changes the order after it is released.
- Who owns the customer record when both companies already sell to them.
Which differences actually matter?
Most of them are cosmetic and will settle themselves inside whichever tool you pick. Field names, screen layouts, notification timing: none of that is worth a meeting. The differences that matter are the places where a decision gets made differently, because a decision encodes a rule, and two rules cannot both be true in one system.
Expect to find three or four. If you have fifteen, you are still comparing screens rather than decisions.
What happens if you skip the process decision?
You get the outcome nobody chooses on purpose: two systems, two processes, and people quietly maintaining both. It happens because neither side ever agreed to stop, so both keep going. The cost does not appear as a failed project. It appears as a reconciliation somebody performs every week, indefinitely, and a finance close that cannot happen without a spreadsheet in the middle of it.
Who owns this decision?
Somebody with the standing to tell one of the two companies that their way is not the way going forward. That is not an IT decision and it is rarely a committee decision. If the integration plan names a platform before it names that person, the plan is assuming a role your combined org chart may not actually have.
When is running two systems the right call?
When the two businesses genuinely operate differently, with different customers, a different fulfillment model, or different economics, keeping both and consolidating the reporting is a legitimate answer rather than a failure. The difference is that you chose it. You know which processes are staying separate and why, and you built the roll-up deliberately instead of inheriting it.
As of 2026 that two-tier arrangement is common and well supported. It only becomes a problem when it happens by default.
Curious how we think about operations work?
Our alignment framework shows where strategy, work, and systems drift apart — and how to close the gap.
Related Insights
Yes, There Is an API. Does It Carry the Numbers You Need?
The software has an API. The numbers you want may not be in it. What to ask before anyone promises an integration, and what an honest scope looks like.
Why Can't We Use the Feature the Demo Showed?
The demo showed it working. Your account does not. The three forms the demo gap takes, and the checks to run before you plan anything on a system.
