A company has a piece of software their operation depends on. It works. It's also eight or twelve or twenty years old, and every year it gets harder to find anyone willing to open it. They ask three firms for a quote. One declines, one never replies, and one comes back with a number so large it reads as a polite no.
This gets read as a technical judgment — the system must be beyond saving. It usually isn't. It's a pricing problem.
Why the quote comes back strange
To price work you have to know what's in there. With a legacy system nobody does, including the people who own it. The documentation is a folder of Word files from two IT managers ago. The person who wrote the original retired. The behavior everyone depends on isn't written down anywhere; it's just what the software does.
Faced with that, a firm has three moves. Decline. Pad the estimate until the unknowns are covered, which produces the polite-no number. Or spend real time reading the thing before saying anything, which costs money they haven't been paid for yet. The third is the only one that produces a useful answer, and it's the one that most sales processes are not built to allow.
An unreadable system isn't unfixable. It's unpriceable — and those get treated the same way.
The rewrite that looks obvious
The reflex, once someone does take the work, is a clean rewrite. Modern stack, fresh architecture, drop the accumulated strangeness, do it properly this time. It's genuinely appealing. It's also where these projects go to die, for two reasons that have nothing to do with engineering skill.
The first is that the strangeness is the product. Two decades of edge cases are sitting in that codebase — the customer with the different tax treatment, the branch that closes early, the report a regulator asked for in 2014. Nobody remembers them. Nobody can list them for you. They surface one at a time, in production, each one arriving as somebody saying "it used to do this."
The second is that a rewrite pays nothing until it's finished. For eight months there are two systems, one of which does no work, and every week is a request to keep believing. Any change in budget, priorities, or leadership during that window kills it, and the company is left exactly where it started with less money.
The version that works
Read first. Before promising anything, go through the code and the database and find out what actually runs. Modern tooling has made this dramatically cheaper than it was five years ago — you can get oriented in an unfamiliar codebase in days rather than weeks, which changes which projects are worth taking at all.
Then move in pieces, and pick the first piece for its risk profile rather than its importance. Something real, ideally something that already causes pain, small enough that being wrong about it costs a week. Get that into daily use, learn how wrong the original assumptions were, and let the next piece be shaped by that.
And hold the interface still. This is the part clients don't ask for and care about most. The people using the system built their working day around it years ago. Every screen they have to relearn is a week of degraded output across the whole team, and that cost lands on the business, not on the project plan. Behavior can stay identical while everything behind it is replaced.
A manufacturer's iPad app
A machinery manufacturer came to us with exactly this. Their operation ran on an internal iPad application built on technology that had become hard to support, and several firms had already passed on the project. It needed to keep working for the people using it every day, connect to their accounting system, and run on current Apple devices.
We rebuilt it on modern foundations and kept the behavior the same. Not similar — the same, deliberately, including habits that a fresh design would have improved away. What the VP of Operations said afterwards was: "the new app works as great as the old one, which was the main goal for us."
That's a strange sentence to put on a portfolio. It's also the correct outcome. Nobody's week got worse, the business kept running, and the platform underneath is now something that can be extended. (Full case study here.)
When to rewrite anyway
"Never rewrite" is advice-shaped rather than true. Sometimes it's right, and the honest markers are these. The platform itself is gone — a runtime with no security patches, a dependency whose vendor no longer exists, hardware you can't buy. The data model is wrong at the root, not merely messy, so every new feature costs three times what it should. Or the system is small enough that a rewrite is a six-week job, in which case most of the argument above simply doesn't apply.
Worth noticing what isn't on that list: the language is unfashionable, the code is ugly, or the last engineer made choices we wouldn't have. Those are reasons to dislike a codebase. They aren't reasons to spend a year of somebody's budget.
If you have a system in this category, the useful first step is smaller than a project. Have somebody read it and tell you what's actually there. Most of the fear around legacy software is fear of the unknown, and that's the cheapest part to fix.