Inherited, and Still in Service

1. At a Glance

Issue study · From the public record. None of the organisations named as a case here was an IOanyT client, and IOanyT had no part in the events described. All are far larger than the firms we write for, both cases are older, and both turn on a security event, which is not IOanyT’s kind of work. We found no public case of a mid-size logistics, travel or hotel firm that could not change, merge or retire a system it had acquired. Each case is reported as the public record gives it, and harm only in the record’s words.

Organisation type	A very large hotel group that kept in service a server it had inherited in an acquisition (an older case), set beside the position of a mid-size firm that moves goods, moves people or looks after guests, a year after buying another business
Size band	The cases: very large. Our reader: a mid-size transporter, courier, forwarder, bus or tour operator, travel seller or hotel group that has bought a business and now runs its systems
Region	The cases: large international firms. The reader: anywhere
The decision at stake	What to do with the systems that came with a deal: leave them alone, move the acquired sites onto the group’s system, replace both with something new, or write down what each does and decide keep, replace or retire for each
The public outcome	A server that had already been compromised came to the group when it bought another hotel group; 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
Why it matters to a mid-size firm	What arrives with a deal can stay in service, unexamined, for years. A group that cannot describe an inherited system cannot merge rate cards, choose between two booking systems or retire one, so it runs two of everything

2. The Business Problem, in the Buyer’s Words

“We bought the business for its routes and its customers, and they have been joined to ours. Its systems have not. A year on we run two booking systems and two billing systems. Every time I ask when they become one, I hear that the question is being studied. The person who built theirs has left, the supplier has closed, and my team will not touch it after the last change broke the invoices. I cannot tell the board what we bought, let alone what to keep.”

These words are imagined. They describe the decision as the research shows it, not a real conversation.

The group is caught between a business it bought to join to its own and systems nobody now at the firm can describe. The answer it can reach quickly, keeping both for now, is the one that never ends.

3. What We Found

Method. We went through the public record on systems that came with an acquisition: reporting on a hotel group’s inherited server, reporting on one parcel firm’s integration of another, two developers’ accounts of old code they did not write, one survey of developers, and one cross-sector survey of how firms see their old systems. The sources were published between November 2020 and November 2025. The sector research behind this study holds no case of a mid-size firm on this issue, no figure for what running two sets of systems costs, and nothing from India or the Middle East.

A server that came with a deal. A very large hotel group. This is an older case and a security event, which is not IOanyT’s kind of work.

What	Public record
How the system arrived	It came with the group’s purchase of another hotel group, already compromised
When the access began	An intrusion made before the purchase, on a server owned by the acquired hotel group
Detection	Some years passed before an internal security tool picked up the access
Effect	Hundreds of millions of guest records were affected, by the group’s later count
Penalty	A regulator’s fine of tens of millions of US dollars

We did not examine why the server was still in use, and we draw no cause from it. We use the case for one point only: what arrives with a deal can stay in service, unexamined, for years.

An acquired firm’s IT, in poor order. Two very large parcel firms: one approached the other to buy it. This is an older case, and it too turns on a security event. 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 use the case for two points: an acquired firm’s systems can be in poor order, and joining two firms’ systems is a large undertaking. The report’s account of customers lost and jobs cut adds nothing to these points and is left out.

What developers say about old code they did not write. These are cross-sector, and none concerns an acquisition or this sector. 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.

What firms say about their old systems. In one cross-sector survey of about 500 US IT professionals, which is not about this sector, more than three in five organisations still used old systems. Half said the biggest reason they had not upgraded is that the current system still works; more than two in five named budget limits and more than a third fear of disrupting operations. Among the top issues with old systems, more than two in five named security vulnerabilities and nearly two in five high maintenance or support costs.

Our reading of why inherited systems stay unexplained. These four are our reasoning from the record above. None is a finding of any source, and neither named case is said to have happened for these reasons.

1. The systems come along with the deal. A deal is about routes, customers and properties, and the systems are rarely its subject.
2. They keep running, so nobody looks. The new owner has more urgent work until the first change is needed.
3. The knowledge was in people, and people move on after a sale. Small firms rarely write their systems down.
4. Nobody decides. Without a written account of the inherited system, “keep both for now” wins every quarter.

4. The Options a Firm in This Position Had

Option	When it fits	What it risks	Our view
Leave the inherited systems alone	The acquired business will stay apart from the group, and nothing in it needs to change	The people who know the systems leave; requests queue up; every later change, merger or retirement starts from guesswork	Right only for a business the group means to run apart, unchanged
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	Right once the inherited system has been written down and the gaps ruled on
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 rebuilt at once, from guesses about one of them; choosing and installing a packaged product is the group’s decision	The group’s own decision, and not IOanyT’s kind of work; we would advise against this as the answer to an inherited system nobody has read
Write a specification of each inherited application, then decide keep, replace or retire for each, replacing module by module	The group must change, merge or retire inherited systems it cannot describe	Costs money before anything changes; the record may show unwelcome things; a staged replacement takes longer than a switch	Our recommendation

5. Our Recommendation, and the Decision It Asks of the Board

For the applications the acquired business built or had built (booking and quotation tools, dispatch, billing, customer and agent portals, and the jobs between them; not packaged products, and not the systems that run aircraft, trains or vehicles): write down what each one does first, then decide. Read the code of each inherited application and write a specification of what it does, what it stands on and what it connects to, with the parts nobody could explain listed, confirmed by the people who still know it. Hand it to the group’s own team, so that a change is planned knowing what else it touches; tests around the code the group keeps are the team’s own choice, and the specification tells them what to test first. Then decide, system by system, whether to keep, replace or retire, with the cost of each choice set side by side. Where the group decides to replace, replace module by module beside the old system, with a traceability matrix for each module. The old system keeps working until each module is accepted.

A written record does not show whether an inherited system is secure or has been broken into. That question needs a security review by a specialist the group chooses, and it is outside this approach.

6. Benchmark: Where You Are Now, and Where You Should Be

These are targets, not results. In an engagement the starting points are replaced by the firm’s own figures, taken in the first review.

Measure	Typical starting point	Where it should be	How it is checked
Inherited systems with a written record	None, or a folder of screenshots	Every inherited application written down from its code, and confirmed by the firm’s own people	The specification
What only the inherited system does	Known by hearsay	Listed, function by function, beside the group’s own system	The specification and the risk register
A decision for each inherited system	”Keep both, for now”	Keep, replace or retire, with a reason the board can read	The cost comparison and the staged plan
The cost of running two of everything	Scattered across budgets	Servers, licences, suppliers and staff time for both, in one place	The cost comparison
The size of one commitment	A whole merger of systems, or nothing	One module, with the freedom to pause after any accepted module	The staged plan
Each function carried across or dropped	Found out after the switch	Each one ruled on by the firm’s own people before its module is accepted	The traceability matrix
A security review of each inherited system	Assumed, or unknown	Done by a security specialist the firm chooses	The firm’s own security review; outside IOanyT’s work

7. How IOanyT Would Work

1. We listen: a free Reliability Review. A first conversation about the business you bought, the systems that came with it and the decisions waiting on them. 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 study 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 former owner or a supplier still holds the code, getting it, or arranging our read-only access to it, is your firm’s own step.
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. A traceability matrix links every old function to its replacement. 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.

8. What the Client Would Own

• The map and the specification: what each inherited application does, what it stands on and what it connects to, in writing, with the parts nobody could explain listed.
• The risk register: what each inherited application puts at risk, listed before any price is set.
• The traceability matrix: for every module IOanyT rebuilds, every old function linked to its replacement, with how it was checked.
• The code: the rebuilt modules are the client’s. No runtime or platform fee.
• The filled-in benchmark: each measure, where it started and where it stands.

The decision for each system, the security review, any tests around the code the group keeps, the move of records and the running of both systems until the last module is accepted belong to the firm’s own team.

9. What This Approach Does Not Cover

• IOanyT does not carry out a security review of servers, does not detect or investigate an intrusion, and does not respond to an attack.
• A written record of what an application does does not show whether it is secure or has been broken into. The firm needs a security specialist of its own choosing for that.
• IOanyT gives no advice on an acquisition, does not examine a business before a purchase, does not value its systems and gives no legal advice.
• IOanyT does not decide which system a group keeps. The group does.
• IOanyT does not maintain the inherited system, supply staff to run it, or keep it running or secure during a replacement. The firm’s own team or supplier does.
• IOanyT does not move or clean data as a stated service. Its terms on code access cover code, not customer, guest or passenger records.
• IOanyT does not install, upgrade, move or choose a packaged reservation, warehouse, property management or ERP product, and does not work inside one.
• IOanyT does not work on the systems that run aircraft, trains or vehicles, and does not read COBOL, RPG, FoxPro or the languages of mainframe booking engines.
• IOanyT does not offer a compliance, audit or legal service, and says nothing about what any data protection rule requires of a particular firm.
• This study does not say IOanyT would have prevented the events described. IOanyT has no published case of this work for a logistics, travel or hospitality firm.

About this study: IOanyT did not work on this case. It is drawn from published findings, cited below.

10. Sources

Source	Used for
Trade press article, 2020	The hotel group: the inherited server, the time to detect, the guest records and the fine
Trade press article, 2021	The two parcel firms: the state of the acquired firm’s IT, the attack and the projected cost of the integration
A developer’s post, 2025	One developer’s account of an old application’s packages
A developer’s post, 2025	Another developer’s remark on changes without tests
A tool maker’s developer survey, 2025	Developers who do not write tests
A vendor’s survey, 2025	Use of old systems, reasons for not upgrading, top issues

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. What came with the deal can be written down while someone can still confirm it, and then decided on, system by system.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →