Shimira IT
Every established business eventually runs on software that's too important to replace and too old to trust. It still works — mostly — but every change takes longer than it should, the original developers are long gone, and a quiet dread surrounds the idea of touching it. The hosting runs an OS version that stopped getting security patches two years ago. One person understands the payment module, and they're retiring.
This is legacy software, and the decision of what to do about it is one of the most expensive calls a business makes — expensive whether you act or not. Here's how to think about it clearly.
"Legacy" Isn't About Age
A ten-year-old system that's documented, maintained, and still serving the business well is not a legacy problem. A three-year-old system built in a rush, undocumented, and understood by nobody still employed is. Legacy is defined by risk and friction, not birthday:
- Security risk — unpatched dependencies, unsupported runtimes, known vulnerabilities you can't close
- Knowledge risk — the system's logic lives in people's heads, not documentation, and those people are leaving
- Change friction — every new feature takes weeks because the codebase fights you
- Integration walls — it can't talk to modern tools, so your team bridges the gap manually
- Platform decay — it depends on something being sunset: an OS, a framework, a vendor going out of business
If two or more of these describe a system you depend on, you have a modernization decision whether you've named it or not.
The Real Cost Is the One You're Already Paying
The instinct is to defer — modernization is expensive and the system still runs. But deferral isn't free; it's a loan accruing interest in forms that don't show on an invoice: the hours your team burns on manual workarounds, the features you can't ship because the foundation won't support them, the growing probability of a breach or an outage, and the compounding cost of eventual migration as the gap to modern technology widens every year.
The honest comparison isn't "modernization cost vs. zero." It's "modernization cost vs. the escalating cost of not modernizing." Framed that way, the math usually favors acting before the forced-migration emergency — which always costs more than the planned one.
Four Paths, Not Two
Most people frame this as rewrite-or-nothing. There are actually four, in ascending order of cost and risk:
1. Maintain and secure. Sometimes the system is fundamentally sound and just neglected. Patching dependencies, closing security gaps, adding documentation and monitoring, and restore-testing backups can buy years at a fraction of a rewrite's cost. The cheapest good outcome — and more common than vendors who only sell rewrites will admit.
2. Incremental modernization (the strangler pattern). Replace the system piece by piece while it keeps running — carve off one module, modernize it, route traffic to the new version, repeat. Lower risk than a big-bang rewrite because the business never goes dark and each step delivers value. The right answer for most business-critical systems.
3. Re-platform / migrate. Move the system to modern infrastructure (current cloud, supported runtimes) without fully rewriting the logic. Addresses platform-decay risk when the code itself is acceptable.
4. Full rewrite. Rebuild from scratch. The most expensive and highest-risk path — and occasionally the only honest one, when the original is so entangled that incremental work costs more than starting over. But it should be a conclusion you're argued into with evidence, not a vendor's default pitch. We wrote a full piece on exactly this call: should you rewrite or rescue an existing codebase?
Start With an Audit, Not a Proposal
No one can honestly quote your modernization without first understanding what you have. A proper audit maps the architecture, documents what exists, inventories dependencies and their security status, restore-tests the backups, and identifies which of the four paths actually fits. It's a bounded, low-cost engagement (typically 1–2 weeks) and it's useful even if you do nothing further — you end up with documentation you didn't have and an honest risk picture.
If the system was built by a team that has since vanished, this matters even more; we cover that specific situation in what to do when your software developer disappears and how to audit a software project before hiring a new agency.
What Modernization Costs
Wildly variable, because it spans those four paths — but as anchors:
- Maintain and secure: often a support retainer, $1,500–$5,000/month, or a bounded fixed project
- Incremental modernization: scoped per module, spreading cost over quarters as value lands
- Re-platform: typically $10,000–$60,000 depending on complexity
- Full rewrite: priced like building new custom software — see our cost guide
The audit is what turns these ranges into a real number for your system.
Don't Let the Rewrite Instinct Win by Default
The most expensive modernization mistake is defaulting to a full rewrite because it feels clean. Rewrites fail at a notoriously high rate: they take longer than estimated, the new system has to re-learn every edge case the old one quietly handled, and the business lives in limbo until it ships. Sometimes a rewrite is right — but it should survive the question "why won't incremental work here?" before it gets your budget.
Get an Honest Read
We modernize legacy systems across all four paths — including the ones we didn't build — and we'll tell you if "maintain and secure" is all you actually need, because recommending a rewrite you don't require is how trust gets spent. Tell us what you're running and we'll propose an audit scope, or a path if you've already had one. You own all code, documentation, and infrastructure from day one.