The question comes up in every first conversation, and the honest answer to it is also the most useless one: it depends. That is true, it helps nobody, and it is why many modernizations never get past the first conversation.
The question becomes answerable when it is asked differently. Not "what does it cost" but: what does the price depend on, and which of those can we establish in a week? The answer to the second one is: almost all of them.
This article describes the five quantities that make the price, how to turn them into a range you can plan with, and which items are routinely missing from such calculations.
Why the amount of code says nothing
The usual first attempt is an estimate based on size: so many lines, so many tables, so many screens. That produces a number, and the number is wrong, because size is not the driver.
Two applications of two hundred thousand lines each can differ by a factor of five in effort. One has tests, clear boundaries and a single writer per table. The other has none of that, plus four applications on the same database and one single person who knows why billing behaves differently on Mondays.
Effort does not come from volume. It comes from the question of how expensive it is to demonstrate that a change is correct. Everything else follows from that.
The five quantities that make the price
Each of these can be captured with a question that is answered in an hour. Together they explain most of the spread between two quotes.
Verifiability. Can you establish whether a change altered behaviour? This is the largest multiplier of them all. With no way to do it, every change is an investigation, and the investigation costs more than the change. Building a net is therefore not a prelude but the first block of cost, and the only one that cannot be negotiated away.
Number of writers on the same data. How many applications, scripts and batch jobs write to the same tables? With one, a rebuild is a question of code. With four it is a question of coordination, and coordination is the most expensive item in any project, because it does not parallelize.
Outside dependencies. Which third-party systems have to move along, and how quickly can they? A partner with one change window per quarter determines the duration of the project more than the size of the code does.
Knowledge. How many people can explain why a particular place is the way it is? At a bus factor of one, a substantial share of the effort is archaeology, and it happens before the first line of code.
Deployment frequency. How often can this system be shipped, and what does a way back cost? Shipping once a month in a maintenance window means batching changes, and batched changes make every investigation more expensive. Improving deliverability is therefore often the cheapest single measure, even though it delivers nothing to the business.
How to establish these five quantities in a week is covered in Technical due diligence.
From a range to a number
Those five quantities produce not a number but a range, and that is not a shortcoming, it is an honest statement about what is known. At the start it is typically one to five: this may take three months or fifteen.
That range is too wide for a decision. Narrowing it is the actual work of the first weeks, and it happens not through thinking but through doing:
A small, paid run-up of two weeks, in which one real, small change is taken from idea to production. Not as a proof of concept but as a measurement: afterwards it is known how long one pass through this system actually takes.
After those two weeks the range is regularly one to one and a half, and that is where its value sits. They cost a fraction of the project and turn a number nobody believes into one you can plan with.
Anyone unwilling to pay for that run-up gets a price with a risk premium instead of a range. The premium is uncertainty, paid for, and it costs more than the two weeks.
The items missing from every quote
Four items appear in almost no first quote, and together they routinely account for a third of the project.
The existing system keeps running. While the rebuild is underway, bug reports, business requests and legal changes keep arriving. Planning as if the team were freed up for the duration is planning past reality. A share of thirty to forty percent for running the shop is normal and belongs visibly in the plan.
The data migration. It gets treated as a technical sideshow and is the largest single item in every second project. The reason is never the copying, it is what surfaces along the way: rows that contradict the model, values that do not exist according to the documentation, and two truths about the same customer.
Acceptance. Who checks whether the new thing calculates correctly, and how much time do they have for it? That is rarely a technical bottleneck and frequently the reason a finished project sits for another two months.
Running both in parallel. In every stepwise replacement both paths run side by side for a while. That costs infrastructure, attention and duplicate investigation, and that period is always longer than planned.
What the cut into delivering blocks looks like in practice is covered in Twelve weeks of modernization.
When a fixed price works
The question about a fixed price is legitimate and has a clear answer, independent of the size of the project.
A fixed price works when the result can be described without knowing the system. An analysis, a report, an upgrade to a specific version with unchanged behaviour: those are closed things with a verifiable end.
It does not work when the scope only becomes visible while working. Offering a two-year replacement at a fixed price means either pricing in a large premium or arguing about every change later. Both are worse for both sides than time and materials cut into delivering blocks.
So the usable middle is the usual one: a fixed price for what can be established up front, then blocks of six to twelve weeks, each with a result you keep even if it stops after that.
The second number nobody asks for
Finally the point at which a quote turns into a project, and it does not sit in the price.
A modernization is not compared against zero, it is compared against carrying on. As long as only the price is on the table, the comparison is unfair: one side shows a concrete sum, the other apparently none.
So the second number is not optional. It consists of what the current state costs every year: extra effort per change, outages, projects lost, a team delivering slower than it could, and the premium at the next security review. How to put that calculation together is covered in a separate article on technical debt as a business risk.
Both numbers next to each other turn "can we afford this" into "which is cheaper", and that is the only form in which decisions like this actually get made. How a project like this runs with me is described on its own page.
This article belongs to a series about systems that already exist. The retrospective orders every article in it by situation.
