Do you even know what systems you have?
Ask that question in most companies and the answer is often less certain than it should be.
Some systems are obvious. Others sit quietly in the background: old applications, internal tools, integrations, databases, spreadsheets and functions that have gradually become part of the furniture, and inside those systems there may be another layer again.
A customer application, for example, is rarely just one system. It may contain a payment module, authentication, customer records, notifications,
reporting, integrations and other subsystems.
Some may be modern and healthy, while others may be carrying years of technical debt.
They all have one thing in common – They cost money, and they carry risk.
What does this solve?
Technical debt is difficult to manage when it remains merely a technical description such as;
“Legacy payment module.”
“Old integration.”
“Needs refactoring.”
“High maintenance.”
These descriptions may all be correct, but they are difficult to compare objectively.
A simple systems register changes the conversation by attaching cost,
effort, dependency and business impact to the problem.
Instead of saying:
“The payment module is old and needs replacing.”
you can say:
“The payment module costs €3,500 a month to operate and support, consumes 20 hours of engineering time, has generated six incidents this quarter, and an outage would prevent approximately €40,000 of transactions per hour.”
That is a very different management discussion.
The practical simple solution?
Start with a simple register covering your important systems and, where appropriate, their major functional components.
Do not stop at “Customer App”.
Break out the areas that carry their own cost or risk:
- Customer App
- Payment Module
- Authentication
- Customer Database
- Notification Service
- Reporting
- External Integrations
For each one, capture a small number of meaningful measures.
The format is simple – Put it in a register that holds six fields.
Update the costs as time goes, and spread them as a cost/month.
| System / Function and Owner | Cost to retire / replace / fix | Operational cost per month | Maintenance and incidents | Dependencies | Impact if unavailable |
|---|---|---|---|---|---|
| Customer app / Digital | 80,000 | 5,000 | 20 hrs, 4 incidents | Customers, Support | 15,000/h |
| Payment module / Finance | 35,000 | 3,500 | 20 hrs, 6 incidents | Sales, Finance, Customers | 40,000/h |
| Reporting / Operations | 12,000 | 1,200 | 5 hrs / 1 incident | Management | 2,000 / day |
| … |
The numbers do not have to be perfect on day one – they need to be good enough to start making comparisons.
Update them over time and convert recurring effort into a monthly cost wherever possible.
Why does this work?
Because it exposes something that traditional system inventories usually do not:
The relationship between technical debt, cost and business impact.
A system may be expensive but stable.
Another may be cheap to operate but represent a major business risk.
A third may consume hundreds of engineering hours every year even though its direct infrastructure cost is almost negligible.
Once these factors are visible together, priorities become much clearer.
You can effectively place each system or subsystem into four broad categories:
| Lower business impact | Higher business impact | |
|---|---|---|
| Lower technical debt / cost | Maintain: Acceptable ongoing state |
Protect: Healthy but business-critical, so keep stable and well-supported |
| Higher technical debt / cost | Simplify or retire: elevated concern, usually driven by cost or technical debt |
Fix first: high debt combined with high business impact |
The colours indicate management priority, not simply system health: blue for ongoing maintenance, green for critical systems that should be protected, orange for systems that should be simplified or retired, and red for systems requiring priority remediation.
The bottom-right category is where management attention should naturally go.
High technical debt.
High operating cost.
High dependency.
High impact when unavailable.
These are the systems where doing nothing is itself an expensive decision.
From technical debt to business decisions, the register gives management a way to ask better questions.
What does this system cost us today?
What business functions depend on it?
What happens financially if it fails?
What kind and how much engineering capacity does it consume?
What would it cost to repair or replace?
What is the risk of leaving it untouched for another year?
And importantly:
Which technical debt should we actually fix first?
Not all legacy technology is bad, not all technical debt needs to be repaid, sometimes an old system is inexpensive, stable and “good enough”, carries little risk, and replacing it may create more cost than value.
The purpose of the register is not to create a campaign against legacy systems – It is to make the trade-offs visible.
Once cost, maintenance effort, dependency and outage impact are placed beside one another, technical debt stops being an abstract IT concern, and becomes measurable business exposure, and once it is measurable, management can decide objectively whether to maintain it, fix it, replace it or retire it.
It makes the risks and benefits visible and objectively understandable.