Your Company Was Acquired. Now Your Software Has to Work With Theirs.

The deal is done. The announcements are out. Someone has ordered new business cards.

Your software has not read the announcement.

It still talks to the same equipment, follows the same business rules, and expects the same data it did before the acquisition. Meanwhile, the acquiring company has its own systems—and a growing list of things that need to connect.

Customers need to appear in a shared reporting platform. Products need to work with another family of instruments. Orders need to move between systems that use different definitions of “complete.”

At Art+Logic, we’ve encountered versions of this problem repeatedly over the years. The business has changed faster than the software around it.

The answer may involve integration, modernization, replacement, or a combination of all three. The useful starting question is more specific:

What needs to work together now, and what must keep working while we make that happen?

Start with the business requirement behind “integrate everything”

“Integrate the acquired company’s systems” sounds like a project description. It is usually the beginning of a discovery conversation.

Does the parent company need consolidated reporting? Must both businesses share customer records? Does an existing application need to support the acquiring company’s hardware? Are employees entering the same information twice?

Each requirement creates a different engineering problem.

A reporting connection might leave the operational application largely intact. Supporting new equipment might require changes to communication libraries, device identification, configuration, or the way measurements are interpreted. Moving order processing into another platform could affect workflows throughout the business.

Before choosing an architecture, identify the outcomes people actually need:

• Which information must move between systems?
• Which users need a different workflow?
• Which equipment and product versions must remain supported?
• Which changes have a real deadline?
• What happens if a particular connection is unavailable?

Those answers turn a broad integration mandate into work that can be scoped, tested, and prioritized.

The old software may be carrying more of the business than anyone realizes

An application can look outdated while doing a remarkably specific job.

It may contain years of customer exceptions, equipment-specific behavior, pricing rules, or operational workarounds. Some of those details are essential. Others are accidents that became familiar.

An acquisition does not make the distinction any easier.

The incoming team may see an awkward screen and reasonably want to replace it. The people using that screen may know that its peculiar sequence prevents an expensive mistake.

Both perspectives matter.

Source code, database structures, logs, tests, and documentation help explain what the system does. Conversations with the people who operate it help establish which behavior is required and why.

AI tools can help engineers analyze unfamiliar code, draft documentation, write integration code, and develop tests. Engineers still need to review those outputs and confirm the business assumptions behind them.

The goal is to preserve necessary behavior while making deliberate decisions about what should change.

Adding new hardware support should not quietly abandon existing customers

For businesses selling instruments, connected products, or other equipment, an acquisition can introduce another complication: the software now needs to support a broader product family.

The new hardware may use different protocols, drivers, commands, units, or data formats. Even devices that perform similar functions can behave differently when a connection drops or a measurement fails.

Meanwhile, customers may still depend on the original equipment.

That makes compatibility an explicit project requirement. Build a picture of the combinations that matter: application versions, operating systems, device models, firmware, and communication methods. Decide which combinations will be supported and how each will be tested.

Some differences can be handled through an adapter or a separate integration component. Others require deeper application changes. Occasionally, an unsupported dependency makes continued compatibility impractical.

Those decisions should follow evidence about the equipment and its use. Our article on modernizing industrial software without replacing the equipment explores those dependencies in more detail.

Connecting databases is easier than agreeing on what their records mean

Two systems can successfully exchange data and still disagree about the business.

A customer might have several account numbers. One application may consider an order complete when it ships; another may wait until installation. Equipment readings might use different units or timestamps.

The integration needs rules for those differences.

For each important record, establish which system owns it, how identifiers map, when updates travel, and what happens when information conflicts. Plan for delayed messages, duplicate updates, and failed connections—not just the successful exchange.

Historical data deserves its own decisions. Some records need to migrate. Others may remain accessible in the original system. Keeping history usable can matter more than putting every record into one database immediately.

These questions are often where the real integration work lives.

Choose what to connect, what to modernize, and what to replace

A company-wide technology standard can be a useful direction. It does not automatically determine the best first step for every acquired application.

A stable system may need a new interface. An application with useful business logic but unsupported infrastructure may need selective modernization. A component that duplicates the parent company’s capabilities may eventually be retired.

Often, several approaches belong in the same plan.

Compare them against the required business outcome, ongoing maintenance, operational risk, and the cost of transition. Include the effort needed to move data, retrain users, support existing customers, and verify behavior.

Our guide to rebuilding versus modernizing provides a broader framework for that decision.

Make the transition testable

A phased approach is useful when each phase has a clear outcome and a way to verify it.

That might mean introducing a reporting integration before changing transaction processing, or validating support for one equipment family before expanding to others.

Define acceptance criteria with the people who depend on the system. Test normal workflows and failure conditions. Make integration failures visible, assign responsibility for resolving them, and establish a feasible recovery plan.

Running old and new systems in parallel can help in some situations, but it also creates questions about duplicate processing and conflicting records. It needs a plan of its own.

The first release should be bounded enough that the team can understand what changed, demonstrate that it works, and respond if it does not.

The acquisition is complete. The software transition needs its own plan.

You do not need to settle the future of every application before making useful progress.

You do need a clear understanding of the first business outcome, the dependencies involved, and the behavior that must survive the change.

That gives the team a practical starting point—and gives the business something more useful than a vague promise to “integrate everything.”

Has an acquisition left you with software that needs to work with new systems or equipment? Talk with Art+Logic about what needs to connect—and what needs to keep working. Talk with Art+Logic about what needs to connect—and what needs to keep working.