How Do You Combine Two Companies' Software After an Acquisition?

After an acquisition, you end up with two of everything. Two systems taking orders, two ways of pricing them, two sets of rules about which orders need a credit check before anything ships.

For a while both keep running. 

People check one system and then the other, ask which number is right, and go to the person who's been there longest when the two don't agree. It's slow, and it makes people nervous about the numbers.

Eventually someone says to pick the bigger system and move the whole company onto it. 

That's usually the sensible call, and it's the one the integration plan tends to make.

But before you turn the other one off, it's worth finding out which system actually enforces the rules your combined business runs on. 

It isn't always the bigger one, and a short look at both will tell you which it is.

‍

Why do system consolidations fail after an acquisition?

A consolidation plan usually compares the two systems on features, licensing and headcount, because that's the comparison the integration budget asks for.

That comparison answers the budget question. It won't tell you that the two systems disagree about which orders get released, what a hold actually blocks, and when a discount needs a second signature. 

Each of those was a decision made once and written into the application, and the people using it today just know that's how orders go.

UnitedHealth bought Change Healthcare for $13 billion in late 2022. In February 2024 attackers used stolen credentials to reach a Change Citrix portal with no multifactor authentication on it, and a claims platform touching one in three patient records sat down for more than a month.

That portal had been sitting there the whole time UnitedHealth owned the company. You own the way a system was set up from the day the deal closes, whether or not your team has read it yet, and integration debt adds up fast, because the two companies never had to agree on how anything worked before.

‍

How do you choose which system survives a merger?

Choose the system that already enforces more of the rules your combined business needs, then plan to carry the remaining rules over from the other one.

So read both applications for the decisions they make. 

The comparison worth building:

• Decisions made without a person. Approvals, holds, routing, anything a scheduled job acts on.
• Thresholds with a number in them. Credit limits, discount tiers, reorder points, aging windows.
• Validation and refusal. What each system declines to accept, and what it corrects on its own.
• Who can do what. Role permissions and the approvals that depend on them.
• The connections. Which partners, carriers and banks are wired in, and under whose credentials.
• The work happening outside the system. The trackers, the saved email replies, the approval checked by hand first.

Run that against both and the answer isn't always the one you expected. The company you bought could be a third your size and still hold the real credit logic, because that was their whole margin. 

We've recommended moving a larger company onto a smaller company's system more than once, and it's rarely on the table because the comparison never ran.

A third option is to keep both and connect them for a while. 

It costs money every month, and it keeps you from picking a winner in week three because the schedule said so.

‍

What happens to the business rules in the system you retire?

The rules in the retired system disappear unless they get written down first, because a migration moves data and leaves the logic behind.

A migration moves records, and a good one moves them accurately. It has no way to carry the conditional buried in the acquired application that holds any order over a certain value from an account opened in the last ninety days. 

That rule has protected the business for a decade. It has no owner on the org chart, and the migration script has no reason to go looking for it.

That's how a legacy system ends up making decisions for you long after the decision itself got forgotten. In a merger you have two systems doing it, and you're about to turn one of them off.

What has to come out before the system goes dark:

1. The rule in plain language. A sentence that makes sense outside engineering.
2. Where it lives. File, table, job or configuration.
3. The number and the reason for it, where there is one. Flag the ones the team can't defend.
4. Who owns it now. A role in the combined company that can confirm it still applies.
5. Whether it's still live, confirmed against usage data.
6. What breaks if it changes. The workflows and partners downstream.

The people who came with the deal know this, and they don't all stay. 

The one who can tell you why the ninety-day rule exists is often already fielding recruiter calls, so get that hour in month one rather than rebuilding their knowledge in month nine.

‍

How do you migrate the data without stopping orders?

You migrate in batches against a live source, which means keeping the acquired system running past the date the integration plan has for it.

A cutover puts all of the risk into one weekend, and the first hour tests every number you put in a spreadsheet months ago. On September 9, 2026, Fifth Third's Michigan regional president apologized publicly after hundreds of thousands of Comerica customers moved onto the new platform at once and ran into login failures and hours on hold. 

No money was lost, and the bank still spent its first week with its new customers apologizing to them.

You can avoid most of that, and it costs you schedule:

• Move one workflow at a time, starting with the one that would hurt least if it went wrong.
• Reconcile each batch against the old system while it's still live. Counts by category, financial totals to the cent, and a sample read by a person who knows what the records should say.
• Replay the rules. Run the same inputs through both systems and compare the decisions. This catches a status code the new system reads differently.
• Keep both running through the overlap, with every release coordinated to protect existing data.
• Get sign-off per category, in writing, with a date, from the people who work with those records daily.

Sign-off is usually the first thing to go when the date tightens. It's also the step most likely to catch a wrong balance before a customer does. 

A developer can confirm the records transferred. Whether a balance is right, or a status still means what it meant last year, is a question for the person who handles those accounts every week.

‍

How does Big Pixel approach post-acquisition system consolidation?

We go through both systems before we tell you which one to keep, because there's no way to recommend one without reading the other.

We read the code in each, pull the usage data to see what your team actually opens, and spend time with the people handling exceptions by hand, because they know the rules that were never written down. 

It all goes into one document your operations lead can read: what each system does, what depends on it, and which rules live in the code and nowhere else.

Then we come back with one of three answers: stabilize, extend or rebuild. If a smaller fix gets you there, we'll say so. 

The work happens in stages, old and new running side by side, with every release coordinated around data that's already in use.

Leland Little wanted their custom systems modernized so they could move auctions online, and in that business every second of a problem costs bids and revenue. 

We built the integrations into their proprietary software, added a new checkout process, and upgraded the suite into a complete online solution. We're the technical backbone behind all of their major systems now.

We believe that business is built on transparency and trust, and that good software is built the same way, which on an integration means you read the rule inventory yourself before the decision gets made.

‍

What should you confirm before decommissioning the acquired system?

Before the acquired system goes dark, confirm you can answer a question about its last two years using only the system you kept.

• Every data category has a written sign-off with a name and a date
• The rule register is complete, owned, and confirmed against usage
• A read-only copy or full export of the retired system is retained for a stated period
• Your team can produce an audit trail for a record that migrated
• The partners, carriers and banks connected to the old system have been moved or formally ended

An integration running under credentials a vendor set up outside IT keeps running after the system is retired, right up until it stops, and then a partner calls your team about a file that never arrived.

Hold onto that written approval even when the schedule narrows, because once the old system is off, it's the only place that could settle an argument about what a rule used to say.

If you're inside this now, start with one workflow that exists in both companies. 

Have a developer read the code behind it in each system and write down every decision it makes, then put both lists in front of the two operations leads and watch where they disagree