Nobody Left to Ask. Four Ways to Deal With an Inherited System, Weighed.

The group’s developer has been asked for a small change to the booking system that came with the acquisition: a new fuel surcharge, from the first of the month.

The developer opens the code for the first time. There are no documents. The surcharge appears in four places, and each works it out a little differently. The person who wrote it left in March, and the supplier that helped has no one left who remembers the work.

The developer changes one of the four, releases it on a Thursday evening, and spends Friday watching the invoices to see what else has moved.

What We Found

We looked at what developers say about working on old code they did not write, at one survey of developers, and at one cross-sector survey of how firms see their old systems. None of it is about logistics, travel or hospitality, and none of it is about an acquisition. The research behind this article holds no case of a mid-size firm in this sector that could not change a system it had acquired; the facts below are labelled for what they are.

Old code often stands on many things nobody chose. One developer who took on an old PHP application found that it relied on dozens of third-party packages. Each is something a change can disturb, and something the new team did not pick.

Developers say plainly what changing such code feels like. Another developer, writing about old code in several languages, said that nothing is more frightening than changing a critical old system that has no tests. It is one person’s account, and we give it as that.

Much old code has nothing around it to check a change. 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. A test is a small program that puts a known input in and checks the answer.

Old systems are seen as costly to keep. In one cross-sector survey of about 500 IT professionals in the US, which is not about this sector, nearly two in five named high maintenance or support costs among the top issues with their old systems.

What a Business You Cannot Change Holds Up

A team that will not touch an inherited system is usually seen as cautious, or short of skill. Our reading is that it has correctly noticed it has no way to see what a change will do, and that the group pays for that in three places.

The deal’s purpose waits. The business was bought to be joined to the group. Its rate card, its tax lines and its forms stay as they were, because nobody can say what changing them would touch.

Every change becomes a project. The change itself may be an hour’s work. Finding out afterwards whether anything else broke takes people, checking by hand, for days.

The largest gamble starts to look safe. When nothing can be changed, a full replacement is proposed, to escape a system nobody ever read.

This is our reading of the evidence. It is not a measured market figure, and we put no value on a frozen system here. That figure has to come from your own business.

Four Ways to Deal With an Inherited System, Weighed

Option	When it fits	What it risks
Leave it alone, and work around it	The acquired business will stay apart from the group and nothing in it needs to change	Requests from the business queue up; updates are put off; the people who know the system leave, and the next change is harder
Move the acquired sites onto the group’s own system	The group’s system is known to do what the acquired business relies on	Nobody has listed what the inherited system does, so what only it did is found out on the first busy morning after the switch
Replace both with something new	Both systems are near the end of their life and the group can carry a long change	Two sets of rules must be rebuilt at once, from guesses about one of them. If the new system is a packaged product, choosing and installing it 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	The group needs to change or merge inherited systems, and nobody left can explain them	It costs money before anything changes, and the record may show things nobody wants to hear

The honest costs. The specification costs money before any change gets easier. It records what the system does today, including its mistakes. It may show that the inherited system does things the group’s own system does not, which can be an unwelcome finding. And it changes nothing by itself: the system is exactly as it was the day before.

Where You Are Now, and Where You Should Be

Before the next change to an inherited system is planned, we would set a benchmark for the decision.

Measure	Typical starting point	Where it should be	How it is checked
Answers weighed for each inherited system	One, by default: leave it alone	Four, each weighed against what the system does	The cost comparison
What the new owner’s team holds	A login and a folder of screenshots	A written specification, confirmed by the people who still know the system	The specification
What a change would touch	Found out afterwards, by checking invoices by hand	Read from the specification before the change is made	The specification and the risk register
The cost of keeping each inherited system	Spread across budgets	Servers, licences, supplier and staff time, in one place, beside the cost of replacing it	The cost comparison
The size of one commitment	A whole replacement, or nothing	One module, with the freedom to pause after any accepted module	The staged plan

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.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about the inherited system and the changes waiting on it. 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 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. 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. 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 you need to bring: a budget for the assessment; the inherited code, with read-only access once the assessment begins (where the former owner or a supplier still holds it, getting it is your firm’s own step); a few hours from the people who still know the system; someone with the authority to decide keep, replace or retire; and your own team or supplier to run and change the inherited system before, during and after the work.

What we do not do: we do not carry out a security review of servers, detect intrusions or respond to an attack, and a written specification does not show whether a system is secure or has been broken into. We give no advice on an acquisition and no legal advice. We do not maintain the inherited system, supply staff to run it, or keep it running or secure during a replacement, and we do not 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	A change the group wants in the acquired business stops waiting for someone brave enough to make it.
CTO or CIO	A specification of the inherited system in the team’s hands, so a change is planned knowing what else it touches, and any tests the team adds start from it.
CFO	Changes to the inherited system can be estimated and planned like any other work, and stop arriving as surprises.
CISO	Fixes and updates to the inherited application are planned with a record of what each part does and connects to, so fewer are put off because nobody knows what they would touch.
COO	A new rate, tax rule or form reaches the acquired sites when the business needs it, and not when someone finally dares.

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

The case	What IOanyT does
One developer found an old application relied on dozens of third-party packages; another wrote that nothing is more frightening than changing a critical old system that has no tests.	We write a specification of an inherited application from its code, with your own people confirming it, and hand it to your team, so a change is planned knowing what else it touches.
In one survey of developers, nearly a third said they still do not write tests at all.	For each module we rebuild, a traceability matrix links every old function to its replacement. For the code you keep, the specification is what your own team checks against, and tests around it are your own team’s choice.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. When there is nobody left to ask, we write down what the system does, so your own team can change it.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →