Fix the old system or rewrite it from scratch?

"Legacy" isn't "old" or "bad" code. Legacy is a system you're afraid to change, because no one fully understands how it works. It can have been written five years ago on a modern stack and still be legacy if the author left, there's no documentation, and every change is a gamble.

The paradox is that a legacy system usually works and brings in money — otherwise it would have been switched off long ago. The problem isn't that it doesn't work, but that the business became its hostage: it can't be developed, it's scary to fix, and replacing it is expensive and risky. It's precisely this fear that unscrupulous contractors exploit.

When a new contractor, barely glancing at your system, says "this is all bad, we need to rewrite from scratch" — most often that's not about your system, it's about their convenience.

Untangling someone else's code is slow, hard and thankless: you have to reconstruct someone else's logic, read what was written without documentation, hold non-obvious connections in your head. Writing from scratch is easier and more pleasant for a programmer — it's a clean slate, a clear scope, and a tidy quote. But the business downtime during the rewrite, the risk of losing working functionality, and the migration cost all land on you.

This is a conflict of interest that's rarely spoken aloud: what benefits the contractor isn't always what benefits the client. A sign of an honest contractor is that they run an audit first and cost out both options, rather than handing down a "rewrite" verdict on the doorstep.

"Fix or replace" is a comparison of two numbers, not a matter of taste:

1. Audit. What's inside the system, where the risks are, whether the source code exists, how interlinked the modules are.
2. Cost of owning the current system. What support costs now and how fast that cost is growing: manual workarounds, downtime, expensive one-off fixes, security risks.
3. Cost of replacement + migration risk. How much it costs to build the new one and what you risk transferring the data and processes.
4. Priorities. What's critical to fix now, and what can wait or doesn't get in the way at all.
5. Verdict. One of three: refactor the critical modules, replace in stages, or (less often) rewrite entirely.

The key idea — the answer is almost never "fix everything" or "rewrite everything." The real decision is almost always hybrid: part of the system is kept, the critical parts are fixed, the hopeless parts are replaced piece by piece.

The criteria by which the verdict is reached at the audit. The more points that land in the right column — the stronger the case for replacement:

Criterion	Lean toward fixing	Lean toward rewriting
Source code	exists and builds	lost / won't build
Architecture	modular, comprehensible	everything tied to everything; any change breaks a neighbor
Technologies	supported	end-of-life, no specialists available
Business logic	current	processes changed long ago; the system no longer fits them
Data	intact	chaos, duplicates, can't be trusted
Support cost	predictable	growing faster than the benefit
Security	manageable	critical holes that can't be closed without a rewrite

How to read the table. Rarely is everything clear-cut. More often the conclusion is "refactor the critical modules, leave the rest" or "rewrite in stages, not all at once." A full replacement is justified only by a tilt to the right column on several key rows at once — especially if the source code is lost and the architecture resists change.

The main criterion is architecture (a breakdown)

Of all the rows in the table, architecture weighs the heaviest, so it's worth dwelling on. The question isn't whether the code is "pretty," but whether you can change one part without breaking the others. In a well-built system the modules are decoupled: a fix in payroll doesn't touch the warehouse, an update to one screen doesn't bring down the reports. Such a system is fixed surgically and cheaply, even if the code is ugly in places.

In a heavily coupled system it's the opposite: any change drags a chain of unpredictable consequences behind it, and every fix turns into bomb-disposal work. It's precisely these systems that breed the fear of "better not touch it." If on top of that there are no source files or tests to catch a breakage — that's the weightiest argument for staged replacement. But even here, don't rush to "rewrite everything": it's often more cost-effective to wrap the old core in a protective layer and replace modules one at a time, rather than stopping the business for a big rewrite.

What people usually underestimate

Two things regularly drop out of the calculation and then cost dearly. The first is the cost of data migration: transferring years of accumulated data without losses is often harder than writing the new code. The second is the implicit business rules baked into the old system: over the years, exceptions and arrangements have settled into it that are written down nowhere and surface only when the new system starts calculating "the wrong way." That's why an honest audit always budgets time for the archaeology of the old logic, not just for assessing the code.

The owner's main fear is "while you tinker, the business will stop." That shouldn't happen. Proper modernization goes in stages: the old system keeps running, while the new one is connected piece by piece and reconciled against what's live. Data is transferred gradually, with a check at each step. By the time the old one is switched off, the new one has already proven it works on the same data. It's slower than "rewriting in a vacuum," but it's exactly how the business loses not a single day.

A common and not hopeless case. Even without the full source code, you can reconstruct the picture: analyze the running system, the database, the behavior, the remaining fragments of code. At the audit we assess what can realistically be recovered and assembled, and what will have to be replaced. A loss of source code is a strong argument toward replacement, but not an automatic death sentence: sometimes it's cheaper to wrap the old in a new interface than to rewrite from scratch.

The cost depends on the size of the system and the state of the code, but the first step — the audit — gives you a clear map and a "fix vs. rewrite" calculation before any major investment. You can ballpark the order of magnitude in the calculator. We work on a model where the risk is on our side: the audit and the concept show the scope and the cost before you commit the main budget. In detail — modernization and legacy and how we work.

• Do you always advise rewriting from scratch? No. First the audit, then an honest verdict on each module. More often improvement beats replacement — and we'll say so.
• The source code is lost — what do we do? We reconstruct the picture from the running system, the database and code fragments; what can realistically be assembled, we assess at the audit.
• Can it be modernized without stopping the business? Yes — in stages, in parallel with the old system, with a check at each step.
• Where do I start? With the audit: it is the honest answer to "fix or replace," with numbers instead of emotions.
• How much does it cost? The price is calculated individually; the audit gives a calculation before any major investment. Your project's scope — in the calculator.