Your Legacy System Still Works. Here's What It's Quietly Costing You.

The hidden bill of aging software: hours lost to manual workarounds, the one developer who understands the code, integrations nobody dares touch. How to put a number on each one.

Your legacy system boots every morning. Invoices go out, orders process, the day closes without a crash. That is exactly why it is dangerous. "Works" is a low bar, and it hides a bill you pay in small installments instead of one obvious lump sum.

That bill almost never shows up as a single figure. It is spread across payroll, missed deadlines, and a risk nobody bothered to price. Below is how to find each line item and attach a real number to it, so "it still works" stops being an argument and becomes a calculation.

"Works" is the most expensive word in your stack

"Works" only means it hasn't fallen over today. It says nothing about what it costs to run, what it costs to change, or the blast radius the day it finally breaks. A system can run for a decade and still bleed money every week. The trick is that none of that bleeding arrives labeled "legacy" — it hides inside numbers you already accept as normal.

Manual workarounds are payroll, not annoyances

Every aging system grows a layer of human glue around it: spreadsheets, data re-keyed between two systems that don't talk, a nightly export someone emails to finance. That work feels normal because it has been normal for years. It is also the easiest cost to measure, because it maps directly to hours and salaries.

Put a number on it. List the recurring manual tasks, estimate hours per week for each, and multiply by a loaded hourly cost — base salary plus overhead, typically 1.25 to 1.4 times base. Do this per task and the total tends to surprise people.

• A finance clerk re-keying orders from the old ERP into the accounting tool: 6 hrs/week x ~$35 loaded = ~$11k/year for one task.
• A month-end close that costs four people three extra days because reports are exported and stitched together by hand.
• A "quick" reconciliation macro that exactly one person knows how to run.

The bus factor of one

Ask who can safely change the core module. If the answer is a single name, that isn't stability — it's a single point of failure with a pulse. A bus factor of one means every change waits on one person's calendar, and their two-week vacation is a company-level risk.

That person is usually underpaid relative to the risk they carry and overworked relative to what's healthy. When they leave — and eventually they do — the knowledge leaves with them. Undocumented business rules turn into archaeology, and you pay for the dig.

• Onboarding a new developer takes months because the logic lives in one head, not in docs or tests.
• Estimates balloon: nobody else can predict what a given change will break.
• You lose leverage — a counteroffer is cheaper than the alternative, and everyone in the room knows it.

The integrations nobody dares to touch

Old systems accrete integrations: a payment gateway on a deprecated API version, a SOAP endpoint, a CSV dropped onto an FTP server at 2am. They work until a partner sunsets a protocol or rotates a certificate. Because changing them is frightening, they freeze — and a frozen integration quietly blocks every roadmap item that touches it.

The cost here is opportunity, not just hours. The feature you can't ship because it would mean touching the untouchable integration is revenue you never see. That gap doesn't appear in any budget, which is precisely why it's dangerous.

Unsupported dependencies are a bill with a due date

Software has an end-of-life. An OS past its EOL, a database version no longer receiving patches, a framework two majors behind — each is a CVE waiting to become someone's incident. This debt compounds silently until an auditor, an insurer, or an attacker makes it urgent, and by then you don't get to choose the timing.

• Compliance: PCI-DSS, SOC 2, or HIPAA controls that assume supported, patched software.
• Cyber-insurance premiums that climb — or coverage that gets denied outright — on unsupported stacks.
• Upgrade cost that grows non-linearly: jumping six versions at once is far harder than staying current.

How to put one number on all of it

You don't need a consulting engagement to estimate this. Build a rough annual figure from four buckets and defend the assumptions behind each one.

• Manual labor: recurring hours/week x loaded hourly cost x 52, summed across every task.
• Slow change: measure feature lead time now versus a healthy baseline; each extra week of delay on a revenue feature has a price.
• Incidents: outages per year x average duration x cost per hour of downtime (lost sales plus staff time).
• Risk-adjusted exposure: probability of a key-person exit or a security incident x its estimated cost. Even at 10-20% likelihood, the expected value is usually large.

Add them up. For a mid-sized system the honest total often lands in the tens of thousands per year at minimum — and that's before the tail risk of a real failure. Now you have a figure to compare against the cost of fixing it, instead of a vague feeling.

When leaving it alone is the right call

Honesty as a tactic: not every legacy system should be rewritten. A stable, well-understood system that changes rarely and carries low risk may be cheapest exactly as it is. The big-bang rewrite — throwing it all out for a shiny new build — fails often and expensively. You spend a year rebuilding what already worked and inherit a fresh crop of bugs for your trouble.

When the numbers do justify action, incremental beats heroic. The strangler fig pattern — standing up new functionality around the old system and redirecting traffic piece by piece — lets you retire risk in slices while the business keeps running. Start with the module that carries the most cost or risk, not the one that's most fun to rebuild.

• Rewrite when: change is frequent, the stack is unsupported, and the bus factor is one.
• Refactor or strangle when: the core logic is sound but the edges are brittle.
• Leave it alone when: it's stable, low-risk, rarely touched, and cheap to run.

A five-minute audit you can run this week

You don't need a full assessment to know where you stand. Answer five questions honestly:

• Who is the one person you can't afford to lose? Write the name down.
• How many hours a week does your team spend moving data by hand?
• What can't you ship because it would mean touching the integration nobody trusts?
• What in your stack is already past its support date?
• What does one hour of downtime actually cost you?

If those answers make you uncomfortable, you've already found the bill. The next step is pricing the fix and comparing the two numbers — not assuming that "still works" means "still worth it."