Check whether the failures track the software or the machine, because that one question decides how much the fix costs.
I think rewriting is the most oversold fix in corporate IT. It sounds decisive, it gives a vendor a big project, and it lets everyone blame the old code without anybody checking whether the code was the problem. The people who pay are the users who live through a long migration and the budget that could have bought the real fix in a fraction of the time.
Why do old systems break more often over time?
Two separate reasons that get treated as one.
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. That’s a system that breaks more than it used to. Almost every modernization proposal assumes the first cause without checking for the second.
I blame the incentives. A rewrite is a bigger, more impressive proposal, and nobody gets promoted for saying the old software was fine and the box under it was tired.
How do you tell software problems from hardware problems?
Look at what the failures have in common.
Software failures cluster around behavior. A specific function fails, a particular data condition breaks something, the same error appears under the same circumstances. There’s 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.
The second pattern points at the floor instead of the building. When somebody describes a system as breaking all the time and being slow, without being able to say what it breaks on, that’s usually the machine.
| Attribute | Software problem | Hardware problem |
|---|---|---|
| How it decays | Dependencies age, assumptions stop holding, experts move on | Components fail, generous capacity becomes tight |
| Failures cluster around | Behavior: a specific function or data condition | Load and time |
| Pattern | Same error under the same circumstances | No consistent place in the code |
| Other signs | A pattern you can describe | Slow when busy; restarting helps for a while |
| Fix | Rewriting is the only cure | Move it to new hardware, as with virtualization |
What happens when you move an old system to new hardware?
We had a large business system on old hardware. It broke constantly and it was slow.
Upgrading the software itself wasn’t 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 and not 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. The issues stopped. 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. I still take a lot of satisfaction from that one. The expensive answer was the obvious answer, everyone expected it, and it would have been the wrong call.
Why should you buy more capacity than you need?
Because getting approval for a large purchase is no harder than getting approval for a small one.
A request scoped to one need is honest, defensible, and leaves you with exactly one solved problem.
When I bought the host for that project, I bought a big one. The single system didn’t require it. I bought it because I intended to virtualize far more if the first move worked, and because I’d learned something years earlier about how approvals work. 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. Only the number changes.
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.
I tell people who have to ask for money to stop apologizing in the request. Finance is going to push back either way, and a timid number only guarantees you’ll be back in a few months asking again, with less credibility the second time.
What does spare capacity buy you later?
Spare capacity buys the project you couldn’t have proposed at the time.
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. It became possible because the first purchase wasn’t sized to the first problem.
A request scoped to one need is honest, defensible, and leaves you with exactly one solved problem. That’s sometimes the right answer, especially when money is tight and nobody trusts the plan yet.
It’s also how a company ends up buying five things across five years, each with its own approval cycle, when one purchase would have covered all of them.
Should a small company still run its own hardware?
Sometimes, and the answer has shifted twice in twenty years.
Back when I built that private cloud, running your own was the only real option for a workload like ours. Then the market moved and everything went to hosted infrastructure. Now a significant share of companies are moving workloads back.
For a workload like ours, running your own was the only real option when I built that private cloud.Share on X
The reason for the return is unglamorous. Steady-state workloads that don’t 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.
My take
Check the hardware before you fund a rewrite. Our old system broke constantly and ran slow, and nobody touched a line of code. We virtualized it onto new hardware and the problem went away for six years. When you do buy the host, buy big. The approval takes the same effort either way, and spare capacity pays for the next project. Stop apologizing in the request. A timid number brings you back in a few months with less credibility.
When is moving a system better than rewriting it?
When the software still does its job and the problem is the environment underneath it.
That condition is narrower than most modernization proposals assume. Plenty of old systems do need rewriting, because the business has changed, the rules are trapped in code nobody can read, or nobody left understands it.
But people skip the diagnosis constantly. A system breaks, somebody proposes replacing it, and the proposal goes through without anyone establishing what was breaking or why.
I think that skipped diagnosis is negligent. Somebody signs off on a replacement without knowing what was broken, and when the new system inherits the same problem, the staff who were promised relief are the ones stuck with it.
Six years of stability came out of moving something instead of rebuilding it. The rebuild would have cost more, taken longer, and carried the risk of losing behavior nobody had documented. Ask what’s breaking before you decide what to build.
It frustrates me how often companies spend a fortune replacing software that was never the problem. A diagnosis costs a few days. Skipping it can cost years, and the vendor who sold the rewrite rarely gets asked to explain why the new system struggles under the same load the old one did.
