How to measure technical debt, when modernisation pays for itself, and how to do it without stopping the business.
In short
Modernise when technical debt costs more each quarter than paying it down would. Measure it through delivery speed, failure rates and the share of time spent on workarounds, not code quality alone. Then replace the system piece by piece, usually with the strangler fig pattern, so the business keeps running throughout.
Technical debt is the extra cost every future change carries because of shortcuts, outdated technology or design decisions that no longer fit. Ward Cunningham, who coined the metaphor in his 1992 OOPSLA experience report, described the time spent on not-quite-right code as interest on that debt. Some debt is a sensible trade-off. It becomes a business risk when the interest keeps growing and nobody owns the repayment.
This guide is written by Devies, a Gothenburg-based product and engineering consultancy, for CTOs, IT leaders and product owners at Swedish and Nordic companies who need to decide whether to keep patching a system or modernise it.
Symptoms: how technical debt shows up in the business
Technical debt rarely appears in a budget line; it shows up as slower delivery, more incidents and growing dependence on a few people.
Typical symptoms that leadership notices:
- Small changes take weeks. A new field in a form needs changes in five places and a full regression test.
- Releases are events. Deployments happen rarely, at night, with several people on standby.
- Incidents repeat. The same kind of fault returns after each fix, because the root cause sits in the design.
- Key-person risk. One or two developers understand a core component, and everyone avoids touching it.
- Integration blocks strategy. New channels, partners or AI features cannot connect without custom workarounds.
- Security patches lag. Frameworks or runtimes are out of support, so updates are risky or impossible.
The last two matter most for IT strategy. When the platform decides what the business can attempt, debt has stopped being a developer concern and become a constraint on digital transformation.
Measuring technical debt
Technical debt is measurable through a small set of delivery, quality and effort indicators that you track over time rather than through one score.
Code analysis tools give useful signals, such as complexity, duplication and outdated dependencies, but they do not tell you what the debt costs. Combine three kinds of measure:
Measure
What it tells you
How to collect it
Delivery speed
What it tells you
How much the debt slows change
How to collect it
Change lead time and deployment frequency from your pipeline
Stability
What it tells you
How much risk each change carries
How to collect it
Change fail rate and recovery time from incident records
Effort on workarounds
What it tells you
The "interest" you pay each sprint
How to collect it
Share of tickets tagged as maintenance, rework or manual fixes
Dependency health
What it tells you
Exposure to security and support gaps
How to collect it
Count of components past end of support
Knowledge concentration
What it tells you
Key-person risk
How to collect it
Areas where only one person has made changes in the last year
As of October 2026, DORA's software delivery metrics define five measures in two groups: throughput (change lead time, deployment frequency, failed deployment recovery time) and instability (change fail rate, deployment rework rate). They are a practical baseline because most teams can extract them from tools they already use.
Measure for a few weeks before deciding anything. A baseline makes the business case credible and gives you a way to show later whether modernisation worked.
The business case for modernisation
Modernisation pays for itself when the recurring cost of the debt, plus the risk it carries, exceeds the one-off cost of replacing the worst parts.
Build the case in four steps:
- Price the interest. Multiply the share of team time spent on workarounds and rework by the team's cost. As a hypothetical example, if six developers spend 30 percent of their time on workarounds, that is close to two full-time salaries a year.
- Price the risk. Estimate the cost of a serious outage, a security incident on an unsupported component, or losing the one person who understands the core.
- Price the opportunity. List the initiatives the current system blocks, such as a new customer portal, an integration or a cloud migration, and what delay costs them.
- Compare options. Weigh keeping and patching, refactoring the worst areas, moving to a new platform, or replacing with a standard product.
A cloud migration is not automatically a modernisation. The AWS migration strategies distinguish seven approaches, from retire and retain to rehost ("lift and shift") and refactor. Rehosting moves the debt to new infrastructure unchanged; only refactoring or replacing removes it. Decide which of your problems you are solving before you choose.
The strangler fig pattern: modernise without stopping the business
The strangler fig pattern is a way of replacing a legacy system gradually, routing one function at a time to new components until the old system can be switched off.
Martin Fowler named the approach after strangler fig vines that slowly grow around a host tree, in his description of the strangler fig application. Microsoft's Azure Architecture Center describes the same mechanics: a facade in front of the old system that sends each request either to legacy code or to its replacement.
How it works in practice:
- Put a facade in front. An API gateway or proxy receives all traffic, so users never notice where requests go.
- Pick the first slice. Choose a function that is valuable, fairly isolated and painful today.
- Build and route. Build the new component, run it alongside the old one, then switch traffic over gradually.
- Retire the old part. Remove the legacy code for that slice so you do not pay for two systems.
- Repeat. Each slice delivers value on its own and keeps the risk of any single release small.
The pattern trades speed for safety. A big-bang rewrite promises a clean result sooner but freezes new features for months and concentrates risk in one cut-over. The strangler approach fits when the system must keep running and the business cannot wait a year for the first result. It suits less well when the old system is so small that a direct replacement is quicker.
CTO support: who owns the decision
Modernisation needs a technology leader who can connect the debt to business goals, and that does not have to be a full-time hire.
Without clear ownership, debt reduction loses every prioritisation meeting against visible features. Someone has to hold the baseline, defend the roadmap and decide when a slice is done. In larger companies that is the CTO or head of engineering. Smaller and mid-sized companies often lack that role or have it filled by someone with little time.
A fractional CTO is a senior technology leader who works part-time for a company, typically to set IT strategy, guide architecture decisions and coach the team. It can work well for a modernisation programme: the leader sets direction and priorities, while the delivery team does the work. Whatever model you choose, agree who owns the measures, who approves each slice and how progress is reported to management. The choice of delivery model is covered in our planned guide on choosing between an IT consultant, a development team or project delivery.
Devies
Want a second opinion?
Devies, a Gothenburg-based product and engineering consultancy, works on questions like this with Nordic product and IT teams. Tell us where you are and we will suggest a sensible first step.
Frequently asked questions
What is technical debt?
Technical debt is the extra effort every future change costs because of earlier shortcuts, outdated technology or design choices that no longer fit. Like financial debt, it can be a deliberate trade-off that speeds up an early release. It becomes a problem when nobody pays it down, so the "interest" grows: slower delivery, more incidents and higher risk with each change to the system.
How do you measure technical debt?
Measure it through its effects rather than one code score. Track delivery speed (change lead time, deployment frequency), stability (change fail rate, recovery time), the share of team time spent on workarounds and rework, components past end of support, and areas only one person understands. Collect a baseline over a few weeks, so you can price the cost and later show whether modernisation worked.
When is it worth modernising a legacy system?
Modernise when the recurring cost of the debt plus its risk exceeds the cost of replacing the worst parts. Clear signals are small changes taking weeks, repeated incidents, unsupported frameworks, key-person dependency and strategic initiatives the system blocks. If only a few areas cause most of the pain, targeted refactoring is often enough; a full replacement is justified when the core design itself blocks the business.
Is cloud migration the same as modernisation?
No. Moving a system to the cloud unchanged, often called rehosting or lift and shift, keeps the same code and therefore the same technical debt on new infrastructure. It can reduce hosting work or end a data-centre contract, but it does not make changes faster or safer. Modernisation means refactoring or replacing the parts that slow you down, before, during or after the move.
What does a fractional CTO do in a modernisation?
A fractional CTO is a part-time senior technology leader who owns the direction of the programme without a full-time hire. In a modernisation, that usually means setting the baseline measures, building the business case, choosing the order of replacement, approving architecture decisions and reporting progress to management. The delivery team builds the new components, while the fractional CTO keeps the work aligned with business priorities.
Sources
- Ward Cunningham, The WyCash Portfolio Management System, OOPSLA '92 experience report
- DORA, DORA's software delivery performance metrics (last updated 5 January 2026)
- AWS Prescriptive Guidance, About the migration strategies
- Martin Fowler, Strangler Fig Application
- Microsoft, Azure Architecture Center: Strangler Fig pattern
- Devies, R&D catalogue
- Devies, Lea Bank digital platform (client case)
