Before you fund a project to modernize an aging system, find out whether the failures are coming from the software or from the hardware underneath it.
Two decays that look identical
Software decays in a specific sense. Dependencies age, assumptions stop holding, and the people who understood it move on. That decay is real and rewriting is the only cure.
Hardware decays in a physical sense. Components fail, capacity that was generous becomes tight, and a machine that ran a workload comfortably in year three struggles in year nine.
Both produce the same symptom, which is a system that breaks more than it used to. Almost every modernization proposal assumes the first cause without checking for the second.
Telling the two decays apart
Software failures cluster around behavior. A specific function fails, a particular data condition breaks something, the same error appears under the same circumstances. There is a pattern you can describe.
Hardware failures cluster around load and time. Things get slow when the machine is busy. Failures happen at no consistent place in the code. Restarting helps for a while.
When somebody describes a system as breaking all the time and being slow, without being able to say what it breaks on, that is usually the machine.
We moved it and the problem went away
We had a large business system on old hardware. It broke constantly and it was slow.
Upgrading the software was not on the table. The system was old enough that we believed touching it would break it, and that belief was reasonable given what we knew.
Working with a consultant, I proposed a different approach. Virtualize it. Put the same software, unchanged, onto a virtual machine running on modern hardware.
The theory was that the software would run faster and stop failing because the failures were coming from underneath it rather than from inside it.
We moved it, and it ran like a bat out of hell. It stopped breaking, because the hardware under it was now stable. And it stayed there, working, for about six years.
Nobody wrote a line of code. Nobody paid down a line of technical debt. The problem went away because the floor got replaced.
Buy more capacity than the job needs
When I bought the host for that project, I bought a big one. The single system did not require it.
The effort of an approval is roughly fixed. The same meetings, the same justification, the same finance conversation, whether the number is small or large. What changes is the number, not the work.
And if it gets cut, a request sized with room to spare gets cut back to something still workable. A request sized exactly to the need gets cut into the bone.
That oversized host is why one rescued system turned into a virtualized computer room. Nobody approved that outcome, because nobody could have described it at the time.
Owning hardware, twenty years later
The answer has shifted twice in twenty years. When I built that private cloud, running your own was the only real option. Then everything went to hosted infrastructure. Now a significant share of companies are moving workloads back.
The reason is unglamorous. Steady-state workloads that do not vary much never needed elastic capacity, and they look expensive once somebody measures them against owning the equivalent.
The test is variability. A workload that spikes unpredictably belongs somewhere elastic. A workload that runs at roughly the same level all year is a candidate for hardware you own, and that describes a lot of what a forty-person company runs.
Ask what is breaking before you decide what to build
Plenty of old systems do need rewriting, because the business has changed or the rules are trapped in code nobody can read.
But the diagnosis gets skipped constantly. A system breaks, somebody proposes replacing it, and the proposal is approved without anyone establishing what was breaking or why.
Six years of stability came out of moving something instead of rebuilding it.
The full article is on my site: https://thewritingking.com/moved-not-fixed/. It runs longer, carries the diagrams, and answers the questions readers ask most.
These are AI-made summaries of longer articles on my site, written with AI assistance from my own interviews and my own career. Nothing goes out that I have not read and approved.