Perspective
Modernise in the Order of What Each System Costs to Leave Alone
The useful question is which system costs most to leave alone. We review the whole portfolio, record a decision on each application, and modernise in stages your team can maintain.
4-minute read4 November 2026
In Brief
- Age is a weak basis for sequencing. A stable old system can be left alone on purpose, while a recent one that delays every pricing change may be the costliest in the estate.
- We see four costs of leaving a system as it stands: running cost, risk, blocked change and dependency. Rank on all four, and keep an owner after go-live so the new system does not drift.
- Thinqmesh reviews your portfolio, gives each application a keep, modernise, replace or retire decision, and delivers the first application or integration in stages.
Application portfolios tend to be modernised in the order that attracts the strongest advocate. The system that has just failed goes first, or the one with the loudest department, or the oldest, because age is easy to explain to a board. The result is a programme that works hard on what is conspicuous and leaves the more expensive problems where they are. We start from a different question: what does it cost to leave this system alone for another three years?
The Costliest System Is Often Not the Oldest
Asked honestly, that question changes both the list and the budget. A very old payroll engine with stable rules may rightly stay where it is, while a five-year-old pricing application that delays every commercial decision comes first. The cost of the second is blocked change, which is large and seldom measured.
It also leads to a second question that many plans ignore: what will stop the replacement drifting into the same condition? Programmes budget for delivery and a spell of intensive support, then the team disperses. The business carries on changing, staff fill the gap with a spreadsheet, and a modern system becomes the next legacy problem. A named owner and a continuing budget are the inexpensive remedy.
Four Actions That Put the Portfolio in the Right Order
Each one adds evidence to the sequence, so the first system modernised is the one whose delay costs you most.
Map What You Run, What It Costs and What It Connects To
A clear view of dependencies lets one system be improved without surprising the others.
We list every application with its running cost, its owner, the data it shares and the systems that rely on it. A system that feeds several others may need to move before a more visible one, and the map shows which. It also shows the applications that carry licences for features no one uses.
Get started
- List your applications with the cost and the named owner of each.
- Mark which ones feed data to others.
Cost the Four Ways of Leaving a System Alone
Running cost, risk, blocked change and dependency each count, and blocked change is often the largest.
Only running cost usually appears in a budget. Risk covers unsupported components and dependence on one person who understands the code. Blocked change is what the business cannot do or can do only slowly, and its estimate must come from a business sponsor. Dependency is what else is held up.
Get started
- Ask a business sponsor for the last three changes that took too long.
- Name the one person each system depends on.
Record a Decision on Each Application
Keep, modernise, replace or retire, each with a reason and a review date.
Leaving a system alone is a legitimate outcome when it is a stated decision. A stable payroll engine may stay, a pricing application that delays every commercial change may come first, and some systems should be retired. We record the call and the reason, so that the portfolio is steered and not left to drift.
Get started
- Take your five largest systems and write one decision for each.
- Set a review date for every system you decide to leave alone.
Keep an Owner After Go-Live
A named business owner with a small continuing budget keeps the new system fitting the business.
The business keeps changing after the project team leaves, and each new rule opens a small gap that staff close with a spreadsheet. A named owner with authority to decide what changes keeps the gap small. We hand over every application with documentation and a support model that has named owners.
Get started
- Choose an owner for your next go-live before the project starts.
- Set aside a small continuing budget for changes after launch.
How Thinqmesh Solves This
We begin by mapping what you run, what it costs and what it connects to. One application or integration of defined scope reaches a first working version within four weeks, once the review has set the order.
- Week 1
The Portfolio Mapped
We map your applications, their costs, their owners and their connections, and bring a clear view of dependencies to the first review.
- Week 2
A Decision on Each Application
Each application gets a keep, modernise, replace or retire call, with costs and risks stated, and the order of work is agreed.
- Week 3
The First Application or Integration Built
The first application or integration of defined scope is built in stages, with the rest of the estate running as before.
- Week 4
A First Working Version, Documented
A first working version is running and documented so your team can maintain it. The full engagement runs to eight weeks, and modernisation across many systems follows its own plan.
You finish with a reviewed portfolio, a sequenced plan with costs and risks stated, the first application or integration running, and a support model with named owners.
