Perspective
Understand and Contain the Old System Before You Fund Its Replacement
An old government system is often the fullest statement of how a scheme really runs. We map it, decide the future of each application, and modernise in stages while service continues.
4-minute read5 November 2026
In Brief
- A replacement specification written from the official procedure describes a simpler service than the one running, and the gaps surface late in testing, or after go-live when a payment is wrong.
- We see four actions: map what the system does and what depends on it, count the full running cost, contain known exposure now, and decide the end of the old system before the new one starts.
- Thinqmesh reviews the whole portfolio, records a keep, modernise, replace or retire decision on each application, and delivers the first modernised application in stages.
When a government system becomes old enough to worry its owners, the natural response is a replacement programme: a business case, a tender and a new platform. That response fixes the scope before anyone can say with confidence what the old system does. Our view is that the first funded work should be understanding and containing the existing system, and that a replacement contract should follow once the department can state what the system does, what depends on it and what will happen to it at the end.
The Old System Is the Fullest Record of How the Scheme Runs
Years of circulars, court orders and exceptions have been written into the code, sometimes by people who have retired. A specification written from the official procedure describes a simpler service than the one running, and the omissions surface late in testing or after go-live, when a pension or a payment comes out wrong.
The running cost is hidden too. A system can look cheap because the cost sits in a district office where staff re-key its output. A contract signed before discovery fixes price and scope when knowledge is lowest, and every later finding becomes a change request.
Four Pieces of Work That Come Before a Replacement Contract
They can run in parallel, and each has value even if the replacement is later reshaped.
Map What the System Does and What Depends on It
Years of circulars, court orders and exceptions have been written into the code, sometimes by people who have since retired.
We map what you run, what it costs and what it connects to, and we write down the rules that the code applies in practice. A clear view of dependencies is what allows one system to be improved well, and it gives any later specification the real behaviour to start from.
Get started
- Name the application that attracts the most complaints.
- List every system it sends data to or receives data from.
Count the Full Cost of Running It
A system can look cheap because the cost sits in a district office where staff re-key its output.
The cost includes manual processes that make up for missing functions, extra interfaces, third-party support agreements and licences for unused features. We record each one against the application, so a replacement business case starts from a complete baseline.
Get started
- Ask one office how many hours a month go on re-keying output.
- List the support and licence contracts attached to the application.
Contain the Exposure Now
Known vulnerabilities and unsupported components are operational work with their own budget, and they do not wait for a modernisation decision.
We identify unsupported hardware and software, outdated languages and known weaknesses, then plan the smallest changes that reduce the exposure and keep service running. This track continues whatever is later decided about replacement.
Get started
- List components that no longer receive vendor support.
- Name one owner and one budget line for containment.
Decide How the Old System Ends Before the New One Begins
Without a planned end date for the old system, an organisation can finish with two systems and the cost of keeping them in step.
Each application gets a recorded decision: keep, modernise, replace or retire. For those to be replaced, we write the end of the old system into the plan, with milestones, a description of what is done and who owns the decision, so that disposal gets the attention that building does.
Get started
- Write the date and condition on which the old system will be switched off.
- Assign an owner to that decision.
How Thinqmesh Solves This
One application or integration of defined scope reaches a first working version within four weeks, once the portfolio review has set the order. The full engagement runs to eight weeks.
- Week 1
Your Applications, Mapped
We map what you run, what each application costs and what it connects to, and note who understands each one.
- Week 2
A Decision on Each Application
Each application receives a keep, modernise, replace or retire decision, and a sequenced plan states costs and risks.
- Week 3
The First Application or Integration Under Way
Work begins on the first application or integration, chosen by the cost of leaving it as it stands.
- Week 4
A First Working Version, Documented
A first working version runs. Everything we touch is documented, and a support model names the owners.
You finish with a recorded decision on every application, a sequenced plan with costs and risks, a first application or integration running, and documentation your own team can maintain.
