Modernization Costs You Can Measure in Four Weeks
Benchmarks do not fund modernization. Eight legacy system costs you can measure inside your own company in four weeks, with the protocol for each.
Modernization business cases rarely die in architecture review. They die in finance, and they usually die for the same reason: the evidence presented is somebody else's. A slide reporting that enterprises spend some percentage of IT budget maintaining legacy systems, or that modernization delivers an average productivity uplift, invites exactly one response from a competent CFO — *none of that is a measurement of this company*. They are right, and the meeting ends.
The fix is not a better benchmark. It is eight numbers measured inside your own business, in four weeks, by people you already employ. We call the exercise the Four-Week Cost Count. Every category below comes with a measurement protocol rather than a definition, because a definition produces agreement and a protocol produces a number.
This is written for CIOs, engineering leaders and finance partners who have to fund — or refuse — a modernization programme.
Why borrowed numbers fail in the room
Two mechanisms, both worth naming before you build the case.
**A benchmark cannot be falsified inside your company, so it cannot be trusted inside your company.** A CFO's job is to distinguish claims from measurements. An industry average is a claim about a population you have not been shown you belong to.
**Benchmarks average away the thing you are arguing about.** The cost of a legacy system is dominated by its specific pathologies: the one integration nobody can replace, the reconciliation somebody does by hand every Thursday. Averaging across a thousand companies deletes precisely the detail that makes your case.
The counter-move is to argue from mechanism and measure locally. Mechanism explains *why* a cost exists; local measurement establishes *how large it is here*. Neither works alone.
The Four-Week Cost Count
Eight categories. Each is measurable without a vendor, a tool purchase or a discovery workshop. Run them concurrently; four weeks is enough for a signal, and it is short enough that nobody has to protect the exercise politically.
Unplanned engineering time keeping it alive
**Protocol.** For four weeks, tag every ticket that touches the system as *feature*, *defect*, or *operational toil* — restarts, manual data fixes, chasing failed jobs. Count hours, not tickets; ticket counts flatter toil, because toil arrives in small pieces. Convert to money at fully loaded cost.
The number you are looking for is the toil share. Anything you carry indefinitely is a recurring line, not a project cost.
Salaried hours spent reconciling by hand
**Protocol.** Ask each operations team one question: what do you do in a spreadsheet that the system should do? Then time one full cycle with a stopwatch, once, in person.
This is the category almost every modernization case omits and the one finance believes fastest, because it is already on the payroll. It is also where the largest numbers usually are. Somebody exporting two reports and matching them every month is not an inefficiency; it is an undocumented integration being run by a person.
Deals lost or delayed at the security questionnaire
**Protocol.** Pull the last twelve months of lost or stalled opportunities from the CRM and count how many stalled after a security or compliance review. Then ask the sales team which questions they cannot answer honestly.
Unsupported runtimes are where this bites. PHP, for example, publishes a fixed lifecycle — roughly two years of active support followed by two years of security fixes only, after which a branch is end of life (PHP supported versions). Every major platform publishes something similar. An end-of-life runtime is not an abstract risk posture; it is a specific question on a specific form that costs you a specific deal, and that deal has a value already recorded in your CRM.
Change lead time
**Protocol.** For the last ten changes, measure elapsed calendar days from *approved* to *in production*. Elapsed, not effort. Do not average away the outliers — the tail is the finding.
This is the interest payment in the original sense of the metaphor. Ward Cunningham's framing, as Martin Fowler documents it, is that cruft charges you interest in the form of extra time on every subsequent change (Technical Debt, martinfowler.com). Lead time is the observable form of that interest, and unlike a code-quality score it is a number the commercial side of the business already cares about.
The single-person dependency
**Protocol.** For each of your top five systems, name the individual who can safely make a non-trivial change. Write the names down. Count how many appear more than once.
You cannot buy insurance against this, which is what makes it a board-level number rather than an engineering complaint. Measure it as delay: what happened to the change queue the last time that person took two weeks' leave.
Infrastructure and licensing pinned by the old stack
**Protocol.** List every recurring line item that exists *only* because the system cannot move. Extended support contracts for an unsupported operating system, a database edition bought for a compatibility reason nobody remembers, a physical machine that cannot be virtualised, a vendor support renewal signed because nobody dares upgrade.
Each line has an invoice, which makes this the easiest category to evidence and the one to lead with.
Time for a new engineer to become useful
**Protocol.** For the last three joiners, find the date of their first merged non-trivial change. Three data points is enough to see the shape.
This converts directly into hiring economics, and it is the number that tells you whether the constraint is the system or the market.
Integration work you have paid for more than once
**Protocol.** Count how many times in the last three years somebody built a new export, scrape, report or sync because the system has no usable API.
Every one of those is a cost you have already paid repeatedly and will pay again. The count is the argument; you do not need to price it precisely to make the point.
What the eight numbers actually buy you
They convert a technical argument into a recurring cost line that sits next to the proposed modernization spend, in the same units, on the same page. That is a comparison a CFO can make.
They are also re-measurable. Run the same eight protocols twelve months after the work and the business case becomes falsifiable — which is unusual enough in technology investment that it is worth saying out loud when you present it. A number you promise to re-measure is treated differently from a number you promise to deliver.
One discipline matters here: publish the protocol alongside each figure. A cost figure without its method is the same species of claim as the industry benchmark you replaced. The modernization strategy piece covers what happens after the funding decision; this exercise is what gets you to it.
The harder half: when the answer is to leave it alone
A business case honest enough to be believed has to be capable of concluding *do nothing*, and often should.
If the product is stable, the change rate is low, the runtime is still receiving security fixes and the eight numbers come back small, the correct decision is usually to keep paying the interest and put the system on the roadmap rather than in the budget. Rewrites are rarer than rewrite requests. The common failure is not that the code is bad — it is that the code contains business rules nobody wrote down, and a rewrite silently drops them.
The four honest destinations for any legacy system are rewrite, strangle, wrap, or leave alone, and the eight numbers are inputs to that choice rather than an argument for one of them. Our decision guide for legacy systems sets out the checks that separate the four.
What to do in week five
Take the eight numbers to finance as a single page: category, measurement protocol, number, and whether it recurs. Do not annualise anything you measured over four weeks without saying so — the credibility of the whole exercise rests on the arithmetic being visible.
Then attach the decision, not the project. Finance is not being asked to approve a modernization; it is being asked to choose between continuing to pay a measured recurring cost and paying a one-off cost to reduce it. Framed that way, some systems get funded and some correctly do not.
Frequently asked questions
Four weeks seems short. Is the number reliable?
It is a signal, not an audit, and it should be presented as one. Four weeks is chosen because it is long enough to catch a monthly cycle and short enough that the exercise finishes. Where a category looks decisive, extend the measurement for that one only.
Our teams will not have time for this.
Seven of the eight protocols are lookups against records you already hold — CRM, ticketing, invoices, version control. Only the reconciliation timing needs anyone to stop and observe, and that is a few hours.
Do we need a consultant to run it?
No, and there is an argument for not using one: the numbers are more persuasive internally when the people who produced them still work there. Bring in help for the decision that follows, not the counting.
What if the numbers come back small?
Then you have a cheap, defensible answer to the modernization question and you can stop. That is a successful outcome of the exercise, not a failed one.
How does this relate to a technical debt register?
The register is the instrument inside this exercise. Add a recurring-cost column to it and populate that column with these measurements; a register without costs is a wish list.
Where to take this next
If you are preparing a modernization case — or defending a decision not to modernize — run the Four-Week Cost Count before you build the deck. The categories are deliberately unglamorous because unglamorous costs are the ones finance can verify.
Moweb takes on legacy estates that nobody has documented, and a meaningful share of that work ends in a recommendation to change less than the client expected. If you want a second opinion on where a system actually costs you money, speak to our team, see how we approach digital transformation and modernization, or read what we have delivered.