You Bought the Business, and Its Systems Came With It. Here Is What the Public Record Shows.

The courier business was bought eight months ago. Its routes and its customers have been joined to the group.

Its booking system has not. At the integration meeting someone asks whether the acquired depots can take the group’s rate card from April. Nobody knows. The system works out its prices in a way nobody present has seen written down.

The developer who looked after it left a month after the deal. The small supplier that built it has closed. What remains is a server, a login and a folder of screenshots.

What We Found

For this article we went through the public record on systems that came with an acquisition: reporting on two very large firms, two developers’ accounts of old code they did not write, and two surveys, published between November 2020 and November 2025.

First, what we did not find: no case of a mid-size logistics, travel or hotel firm that could not change, merge or retire a system it had acquired. Both named cases below are older, far larger than our readers, and turn on a security event, which is not our kind of work.

What comes with a deal can stay in service for years. This is an older case, from a very large hotel group. By one report, a server that had already been compromised came to the group when it bought another hotel group, and some years passed before an internal security tool picked up the access. The group later found that hundreds of millions of guest records were affected, and a regulator fined it tens of millions of US dollars. We did not examine why the server was still in use, and draw no cause from it. Our point is narrow: what arrives with a deal can stay in service, unexamined, long after it.

An acquired firm’s IT can be in poor order. This is an older case, from two very large parcel firms. By one report, the acquired firm’s information technology was ageing and in disarray when the buyer approached it. An attack on the two companies’ systems during the integration cost the buyer hundreds of millions of US dollars to put right. We draw no link between the state of the acquired firm’s IT and the attack. The same report put the buyer’s expected spending on the integration at more than a billion US dollars: a projection, made before the work was finished, not a final cost. We take two narrow points: an acquired firm’s systems can be in poor order, and joining two firms’ systems is a large undertaking.

Developers say plainly what changing inherited code feels like. This is cross-sector and not about acquisitions. One developer who took on an old PHP application found that it relied on dozens of third-party packages. Another, writing about old code in several languages, said that nothing is more frightening than changing a critical old system that has no tests. In one survey of about 1,700 developers whose main language is PHP, nearly a third said they still do not write tests at all. We give them as two people’s accounts and one survey.

Old systems are common, and the fact that they still work keeps them. In one cross-sector survey of about 500 IT professionals in the US, which is not about this sector, more than three in five organisations still used old systems, and half said the biggest reason they had not upgraded is that the current system still works.

Our reading: the systems come along with a deal and keep running, so nobody looks. The people who knew them move on. When the first change is needed, the new owner has a system it runs and cannot describe.

What Waits on a System Nobody Can Describe

An inherited system that keeps running looks like the one part of the deal that needs no attention. Our reading is that it holds up more.

The rate card waits. Nobody can say whether the acquired depots or hotels can take the group’s prices.

The choice between two systems waits. Nobody can list what the inherited booking system does, so nobody knows if the group’s could take over.

Retiring anything waits. A system nobody can describe cannot be switched off with confidence, so it stays.

This is our reading of the evidence. It is not a measured market figure.

Four Ways to Handle What Came With the Deal, Weighed

There are four real options. Each one is right for somebody.

Option	When it fits	What it risks
Leave the inherited systems alone	The acquired business will run apart from the group, unchanged	The people who know the systems leave, and every later change starts from guesswork
Move the acquired sites onto the group’s own system	The group’s system is known to do everything the acquired business relies on	Nobody has listed what the inherited system does, so what only it did is found out after the switch
Replace both with something new, perhaps a packaged reservation, warehouse or property management product	Both systems are near the end of their life and the group can carry a long change	Two sets of rules must be refitted at once; choosing and installing such a product is the group’s decision, and not our kind of work
Write a specification of each inherited application, then decide keep, replace or retire for each, replacing module by module where you decide to replace	The group must change, merge or retire inherited systems it cannot describe	It costs money before anything changes, and may show unwelcome things

Where You Are Now, and Where You Should Be

Before any work begins we set a benchmark: a few measures taken from your own position, each with a target. For this issue it would look like this.

Measure	Typical starting point	Where it should be	How it is checked
Inherited applications listed	A list of servers and logins	Each application named, with who uses it	The map of the system as it stands
What each inherited application does	Known by its users’ accounts, or not at all	Written down, rule by rule, from the code, and confirmed by your own people	The specification
What each connects to	Found when something stops	Every file and message that passes in or out, listed	The specification
Parts nobody can explain	Not admitted	Listed openly, with the risk each carries	The risk register
Whether each has had a security review	Assumed, or unknown	Reviewed by a security specialist you choose; outside our work	Your own security review

The starting points above are what we expect to find; in an engagement they are replaced by your own figures, taken in the first review. The targets are what we would work towards with you. They are not results we have already achieved for a logistics, travel or hospitality firm.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about the systems that came with the deal. You leave with a short written note of what we found. You can start with a conversation about the system; we ask for read-only code access only when the assessment begins.
2. We research. We research your sector, the regulator’s position and what the public record says about firms in your situation. This article is an example of that work.
3. We read the system and propose: the Legacy System Specification Assessment. Here the system is each application the acquired business built or had built. It produces a map of the system as it stands, a written specification of what it does, a risk register, a cost comparison between keeping and replacing the system, and a staged plan with a fixed quote. AI does a first pass, our senior engineers review it and trace it to the code, and your own experts confirm it. Code access is read-only and logged, never used for training, and deleted within 30 days of the evaluation ending unless we engage. Where the code is still held by the former owner or a supplier, getting it, or arranging our read-only access to it, is your firm’s own step. You get the options and our recommendation.
4. If you approve, we build. We replace a system one module at a time while the old one keeps running. Here that means an inherited application you decide to replace, rebuilt beside the old one. We never do a single cutover. Each module has a traceability matrix. The work is billed by milestone, each milestone tied to a module you accept, and you can pause after any accepted module.
5. We review against the benchmark. Before work starts we set the benchmark. After each module we show you where each measure stands, and the filled-in benchmark is yours at the end.

The Review is free. Every paid step is fixed price, agreed at scoping. Stop after any step. The findings are yours. The assessment fee is credited in full against the first build stage if it starts within 90 days of the report.

What we do not do: we do not carry out a security review of servers, detect or investigate intrusions, or respond to an attack. A written record of what an application does does not show whether it is secure or has been broken into. We give no advice on an acquisition, do not examine a business before a purchase, and give no legal advice. We do not keep the inherited system running or secure, or move its data. We do not work inside a packaged reservation, warehouse or property management product, and we do not install, upgrade, move or choose one. We do not work on the systems that run aircraft, trains or vehicles. We have no published case of this work for a logistics, travel or hospitality firm.

What changes for the business:

Role	What they gain
CEO	The business that was bought can be run and changed on knowledge the group holds, and not on the memory of people who are leaving.
CTO or CIO	A written specification of each inherited application: what it does, what it stands on and what it connects to, with the parts nobody could explain listed.
CFO	The inherited systems stop being an unknown in the integration budget, because what is there was written down before the plans were priced.
CISO	A list of every inherited application, what it holds and what it connects to, which the firm’s own security review can start from.
COO	The acquired sites can be asked to change how they work by people who know what their system does today.

The cases in this article, and what IOanyT does about that kind of problem:

The case	What IOanyT does
A very large hotel group inherited an already compromised server when it bought another hotel group, and hundreds of millions of guest records were later found to be affected. An older case.	Our part is far narrower, and we do not say what would have helped. We do no security work. For an application a group has acquired, we write down what it does and what it connects to, so that keeping it is a decision and not a default.
An acquired parcel firm’s IT was ageing and in disarray when the buyer approached it; an attack during the integration cost the buyer hundreds of millions of US dollars to put right. An older case.	Our part is far narrower: no acquisition advice and no security work. For an application a firm has acquired, we write a specification from its code, so that plans to change, join or replace it start from a record.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We write down what came with the deal while there is still someone to confirm it; whether it is secure is a question for a security specialist.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →