A Year After the Deal You Still Run Two of Everything. Here Is the Benchmark We Would Set.

The board asks a simple question. It is a year since the deal. When do the two booking systems become one?

The group’s head of technology says the group’s own system should survive. The manager of the acquired hotels says theirs handles things the group’s cannot. Asked what things, the manager gives three examples and says there are more.

Nobody can list them. So the board hears, for the fourth quarter running, that the matter is being studied, and the group goes on paying for two of everything.

What We Found

We looked at the public record on systems that stayed in service after an acquisition, and at one cross-sector survey of why firms keep old systems. It holds no case of a mid-size logistics, travel or hotel firm that ran two sets of systems after a deal.

What is inherited tends to stay in service. This is an older case, from a very large hotel group, and it turns on a security event, which is not our kind of work. 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. We did not examine why the server was still in use, and draw no cause from it. Nothing we do would detect such access. We take one narrow point: what arrives with a deal can stay in service, unexamined, for years.

Firms keep old systems because they work, and because change is feared. In one cross-sector survey of about 500 IT professionals in the US, which is not about this sector, half said the biggest reason they had not upgraded is that the current system still works. Among the other reasons, more than two in five named budget limits and more than a third named fear of disrupting operations.

Old systems are seen to carry their own exposure. In the same survey, more than two in five named security vulnerabilities among the top issues with their old systems. A written record does not answer that question; it needs a security review.

What a Decision for Each System Opens Up

A written account of an inherited system is usually seen as homework for the technology team. Our reading is that it frees more.

• The argument gets an end. With both systems written down, most of what each does usually turns out to be shared. The real choice is about the few functions only one has.
• The cost of two gets a date. Each inherited system gets a decision and a plan, so the second set of costs stops running by default.
• Nothing is dropped by accident. Each function only the inherited system has is carried across or dropped on purpose, by your own people.

This is our reading. It is not a measured market figure.

Three Ways to Settle Two of Everything, Weighed

Option	When it fits	What it risks
Keep both, for now	The two businesses will stay apart, and the cost of two is accepted	The decision is made by default each quarter; the people who know the inherited system leave; when one is finally switched off, what only it did goes with it
Switch the inherited system off and move everyone to the group’s	The group’s system is known to do everything the acquired business relies on	Nobody has listed what only the inherited system does, so the loss is found by the front desk or the depot on the first busy morning
Write an account of each inherited system, decide keep, replace or retire for each, and replace module by module where you decide to replace	Two of everything has lasted longer than planned, and nobody can say what the inherited system does	It costs money before any saving appears, the decision may go against the group’s own system, and a staged replacement takes longer than a switch, with both running until it is done

Where You Are Now, and Where You Should Be

This is the benchmark we would set before the first module is replaced, and fill in as each module is accepted.

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 your 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 your own people before its module is accepted	The traceability matrix, module by module
Whether each inherited system 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 position, 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.

A small part of the finished list might look like this.

Inherited system	Decision	Status
Booking system of the acquired hotels	Replace, module by module	Stage 1: group bookings rebuilt beside the old system; matrix accepted
Overnight job that sends invoices to the old accounts package	Retire once billing has moved	Waiting on stage 2
Packaged property management product at two hotels	Outside our work	The group’s own decision

The rows above are an illustration, not taken from a real firm.

How We Work With You, and What You Are Left With

1. We listen: a free Reliability Review. A first conversation about the two sets of systems. 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.
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 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 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 system 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 above. As each module is accepted 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.

This has a price. Writing the record costs money before any saving appears, and we promise none. The decision may go against the group’s own system. A staged replacement takes longer than a switch, and both systems run until it is done; your own team or supplier keeps them running, and moves the records. A written record does not show whether an inherited system is secure or has been broken into: we do not carry out a security review of servers, detect intrusions or respond to an attack. We do not choose which system survives, and give no acquisition or legal advice. If what you inherited is a packaged reservation, warehouse or property management product, we do not install, upgrade, move or choose one, and we do not work inside it. 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.

At the end you hold the specification of each inherited system, the decision for each, and the traceability matrix and code for every module we rebuilt. The security review, the move of records and the running of both systems until the last module is accepted are your team’s.

What changes for the business:

Role	What they gain
CEO	”When do two businesses become one?” gets an answer system by system, each with a reason the board can read.
CTO or CIO	For each pair of systems, a written account of what each does, and a replacement done one module at a time with the old one still running.
CFO	The cost of running two of everything is set out in one place, and its end is planned stage by stage, each stage approved on its own evidence.
CISO	Systems the group decides not to keep are retired on a plan, and stop sitting in service because nobody decided.
COO	Nothing the acquired business relied on is lost in the merge unless someone chose to drop it.

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; some years passed before an internal security tool picked up the access, 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, and nothing we do detects an intrusion or protects a guest’s record. For an application a group has inherited, we write down what it does, so that keeping it is a decision and not a default, and replace it one module at a time if the group decides to.
In one survey, more than two in five named security vulnerabilities among the top issues with their old systems.	We do not review security; that is for a specialist you choose. We give each inherited system a record and a decision, so what the group no longer needs is retired on a plan.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We will not choose your system for you; we can give the board a written account of both, and a decision it can read.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →