The most dangerous words in software: it still works
A retailer came to my team a while ago with a piece of software they had trusted for years. It ran on a rugged little handheld, an old DOS device, and it managed their entire stock: orders, deliveries, price checks, transfers between branches. It was slow and it was ugly, but it worked. That was the whole reason they had never touched it. And that, not the age of the thing, was the actual problem.
Because "it still works" is only true until the day it isn't, and that day arrives without warning. The handheld goes out of production and you cannot buy another when one finally breaks. The single person who understood how it was set up moves on, and takes the knowledge with them. A supplier changes a file format, and the system that ran your warehouse for a decade quietly stops being able to read it. None of these are dramatic. Each one is the moment the bill you have been deferring for years lands on your desk, all at once, usually at the worst possible time.
Old and working is not safe. It is deferred risk.
The cheap move, when a client shows up with something like this, is to keep it limping. Patch it, prop it up, bill them a little every month to keep the lights on. Plenty of vendors are happy to do exactly that, because it is easy work and it never ends. It is also a slow way of letting a client walk toward a cliff they cannot see.
We do not treat "still running" as the same thing as "safe." When someone shows us an old system that has not failed, the question we ask is not "can we keep this alive a bit longer." It is "what happens the day this dies, and have we built for that day yet." Almost always, they have not. Almost always, nobody has even priced what that day would cost them. That is the conversation worth having, and it is the one most people are quietly avoiding.
Rebuilding without stopping the business
Deciding to modernize is the easy part. Doing it without breaking the thing that pays the bills is where the real work lives.
With that retailer, we did not stop their operation to rebuild it. The old terminal kept running the shop floor while we built its replacement on modern Android hardware they could actually buy and maintain, keeping the rugged scanning their staff already trusted. The hard, unglamorous problems were the ones that mattered. Their data came in files with a hundred thousand lines in them, and that has to move fast on a handheld in someone's palm, not choke. Their branches had to stay in sync, so a stock count in one place was not quietly contradicted somewhere else. And it all had to keep working when the connection dropped, then reconcile cleanly once it came back. We matched the workflow the staff already knew before we improved on it, because the fastest way to break an operation is to hand people something clever they have to relearn under pressure on a busy day.
That is the standard I hold my teams to on this kind of work. Respect the muscle memory first. Modernize the machinery underneath it second. The user should feel steadier, not lost.
The same pattern, with lives attached
This is not only a retail story. We ran the same play inside a hospital, where the stakes are a different order of magnitude. Their materials management, the system that tracks supplies through the building and charges them to the right patient, was running on aging Windows handhelds. When that hardware is one failure away from unavailable, you are not risking a slow afternoon at a till. You are risking a nurse unable to log a supply, or a charge landing on the wrong record.
We moved it onto current Android devices with proper barcode scanning, so a scan was accurate and the record it touched was the right one. The lesson is the same one the retailer taught, only louder. "It still works" is the most comfortable sentence in the room and the most expensive one, and the more critical the operation, the more that is true. In a hospital, old-and-working is not stability. It is a single point of failure that nobody has been forced to look at yet.
A test you can use
If you are running something important on software nobody wants to touch, here is the question I would put to you, or to any team you are paying to look after it. Not "is it working," because that tells you nothing about tomorrow. Ask instead: what happens the day this breaks, who understands it well enough to fix it, and can we still buy the parts. If the answers are vague, you do not have a stable system. You have a countdown you cannot see.
Modernizing is not chasing the newest thing for its own sake. Most of the time it is the opposite. It is buying back your options before the day they get taken away from you. Old and working is not safe. It is a bill you have not been handed yet, and the only question that matters is whether you open it on your schedule or on its.
Modernizing something critical without breaking it is a lot of what my teams do. See how ScalaCode works, or get in touch.