Modernizing a legacy system rarely fails on the technology. It fails in a meeting where a head of engineering explains that the system is in a poor state, and a board asks what that costs and what comes out of it.
At that point the phrase "technical debt" almost always turns up. It is a good image and a poor argument, because it describes a feeling, not a number. What the other side hears is: the developers would like nicer code. And from where they sit, that is not a reason for a budget.
This article describes how to write the same situation down so that it carries a decision. No rhetoric: four kinds of cost, how to measure them, and the places where you must not get the arithmetic wrong.
Why "technical debt" does not work as an argument
The term has a design flaw: it asks the listener to do the translation themselves. Debt is something you pay back. With real debt the amount is on the statement, and here it is nowhere.
On top of that, the term points inwards. It describes how work feels, not what it costs. A board is made of people who make decisions about capital and compare alternatives while doing it: this modernization against two extra sales roles, against a trade fair, against doing nothing. In that comparison, every argument without a number loses to every argument with one.
That is not ignorance, it is appropriate caution towards a project with no visible outcome. From the outside a modernization looks like a year of work after which the product looks exactly as it did before. Why it is a business risk regardless I have written up elsewhere. This is about the step after: the arithmetic.
The four kinds of cost you can put a number on
The state of a legacy system costs money in four places. Three of them sit in systems your company already runs; the fourth is an estimate, and it gets labelled as one.
Running cost. Servers, licences, maintenance contracts, external suppliers, extended security support. It is the smallest item and the only one that is often already written down in full somewhere. What matters is pulling it together: it is regularly spread across three cost centres, and nobody has ever seen the total.
Cost of change. What it costs to get a change into this system compared to a healthy one. That is the largest item and the one you can measure rather than estimate. How, in the next section.
Cost of outages. Frequency times duration times revenue or cost per hour. The frequency is in the ticket system, so is the duration, and the finance department will give you the third number in five minutes.
Work that never happened. This is the list of things somebody wanted that were not done because they were too expensive or too risky in this system. That list always exists, it is just not in any system, it is in the heads of two or three people. Collecting it is an hour of work and produces the item that moves a room the most.
Measuring the cost of change instead of estimating it
The sentence "everything takes three times as long here" is true and worthless. It becomes useful when a number hangs off it, and that number is in the ticket system.
What gets measured is lead time: from "somebody decided this will be done" to "it is running in production". Not the estimated person-days, because those measure the estimate, not the system.
-- Lead time per item, averaged over the last twelve months
SELECT
DATE_FORMAT(done_at, '%Y-%m') AS month,
COUNT(*) AS items,
ROUND(AVG(DATEDIFF(done_at, started_at))) AS avg_days
FROM work_item
WHERE kind = 'feature' AND done_at >= DATE_SUB(CURDATE(), INTERVAL 12 MONTH)
GROUP BY month
ORDER BY month;Three readings turn that into an argument.
The comparison over time. If lead time was nine days three years ago and is twenty-one today, that is the statement. It needs no benchmark against other companies, because it shows the trend inside your own, and that makes it immune to the most common objection.
The comparison between areas. If changes in the new part of the platform take four days and twenty in the old one, the difference is not the team, it is the system. That comparison is the strongest one available, because it rules out every other explanation.
The share of rework. How many items are fixes to things shipped in the same quarter. If that share rises, the work is not getting slower, it is being done twice.
The difference turns into money by multiplying it with what a developer day costs in your company. That is a number HR knows, and it does not have to be precise in this calculation, because the result delivers orders of magnitude, not decimal places.
Calculating risk instead of arguing from fear
The fourth item is where most presentations start to slide, because they argue from the worst case. "If the database fails, the company stops." That may be true and it still does not land, because everybody in the room knows it has not happened in eight years.
What lands is an expected value: probability times damage, openly labelled as an estimate.
Risk p/year Damage Expected value
Outage > 4 h caused by legacy 0.30 120,000 EUR 36,000 EUR
Security incident (EOL package) 0.10 250,000 EUR 25,000 EUR
Key person unavailable 0.20 80,000 EUR 16,000 EUR
---------
77,000 EURThree things decide whether such a table convinces or gets dismissed as a numbers game.
The probabilities come from your own history, not from a study. Two outages in five years is 0.4 per year. That is contestable but traceable, and contestable plus traceable beats uncontestable plus invented.
The damage is calculated from your own revenue, with the formula stated. Four hours of downtime on a normal working day is a fraction of daily revenue plus the working time of the people who cannot work during it.
The table says what it does not know. A column giving the origin of every number (measured, estimated, assumed) makes it more credible, not weaker. Declare the uncertainty and you get challenged on the one number that is uncertain. Hide it and you lose the whole table the moment anybody doubts a single figure.
What you leave out of the calculation
Three items turn up regularly and weaken every paper they appear in.
Productivity gains in per cent. "Thirty per cent faster development" is a number without a source. It sounds like evidence and it is a hope, and the first follow-up question exposes it. Measured lead time from your own company does the same job and holds up.
Team satisfaction. It is real and it is an outcome, not an argument. In an investment case it reads as an admission that the hard numbers are not enough.
Modern technology as a value in itself. A new language version, a new framework, a different architecture: those are means. Writing them down as the goal confirms exactly the suspicion the whole paper is arguing against.
The other side of the calculation, what the project itself costs and what the price depends on, is covered in What a modernization costs.
The one slide
At the end there is one page, and it has four lines. Everything else is an appendix for the follow-up questions.
The system costs today ~ 310,000 EUR / year
running cost 60,000 EUR (measured)
extra cost per change 140,000 EUR (measured, lead time)
risk, expected value 77,000 EUR (estimated)
work that never happened 33,000 EUR (estimated, 3 items)
The project costs ~ 380,000 EUR over 14 months
Afterwards it costs ~ 120,000 EUR / year
Payback ~ 24 months from completionThe decisive part of that slide is the right-hand column, not the left. It says which number was measured and which was estimated, and that distinction is exactly what a board does not otherwise get from a technical paper.
And one more line belongs there: the case where no decision is taken. Doing nothing is an option with a price too, and in this calculation it is the most expensive one.
Once the slide works, the shape is still missing: Twelve weeks of modernization.
The objection that always comes
"If the system is that expensive, the rebuild pays back in twenty-four months, and a lot can happen in twenty-four months."
The objection is fair, and the answer to it is not rhetoric but a different cut: the project gets shaped so that it gives something back after three months for the first time. Not one modernization with one outcome at the end, but a sequence of steps, each of which goes live on its own.
That changes the question on the table. It is no longer "fourteen months and 380,000 euros, yes or no", it is "three months and 80,000 euros for the first step, and then we decide again". That is a question a board can answer, and it is incidentally the only way of running a modernization I consider defensible: everything else is a rewrite under a different name.
If you are sitting in front of such a paper: how I cut a step-by-step modernization is on its own page. You can put the calculation above together without me, and that is the point.
This article belongs to a series about systems that already exist. The retrospective orders every article in it by situation.
