SOLUTION · SOFTWARE QA, TESTING AND MAINTENANCE

Legacy system rescue and maintenance

Rescuing a legacy system means understanding it, stabilizing what's critical, protecting it with tests and modernizing it piece by piece instead of throwing it away and starting over. If the developer who built it is gone, there's no documentation and every change breaks something else, I start with an assessment that tells you what to keep, what to fix and what's worth replacing.

01 / THE PROBLEM

What’s happening today

Many businesses depend on a custom system built years ago: order management, internal billing, the warehouse system. It works, more or less, but nobody really understands how. The person who built it is gone, there are no tests or docs, the development environment only ever existed on that person's laptop, and the dependencies haven't been updated in years.

Every change is scary, and for good reason: a report gets fixed and order entry stops working; a library is updated and the system won't start. So people stop touching it. The improvements the business needs keep getting postponed, known bugs are worked around with manual tricks, and the system becomes a risk everyone knows about and nobody addresses.

The most serious risk is usually security. Unsupported technologies don't receive patches, and old dependencies accumulate known, publicly documented vulnerabilities. An internet-facing system in that state is an open door, even if it has "always worked".

Rewriting from scratch looks like the clean solution, but it's expensive, takes longer than planned and carries a big risk: losing business rules that exist only in the old code, that nobody documented and that someone will discover only when they're missing. The sensible alternative almost always starts with a rescue: understand, stabilize, protect with tests and modernize in reversible slices.

02 / APPROACH

How I’d solve it

  1. 01

    Technical assessment

    I review the code structure, dependencies and their known vulnerabilities, the database, how it's deployed and where it runs. I use static analysis to detect security risks and technical debt — the same approach as ScriptC. I work with read-only access and a copy of the data.

  2. 02

    Back up and stabilize the urgent

    Before touching anything, I make sure restorable backups of the code, configuration and database exist. Then I fix critical bugs and the most serious security risks, one at a time and with tests.

  3. 03

    Document and protect with tests

    I document how the system works, where each business rule lives and how it's deployed. I add tests around the critical flows so any later change happens with a safety net, and leave a reproducible Docker development environment.

  4. 04

    Decide module by module

    Not every part of the system has the same fate. Some modules are kept and simply wrapped; others are upgraded to supported versions; others are gradually replaced by new pieces that run alongside the old ones until they take over — the strangler fig pattern — without stopping operations.

  5. 05

    Evolution and maintenance plan

    You get a clear, prioritized recommendation: what to keep, what to upgrade and what to replace, with risks and a suggested order. If you need it, we agree on a monthly maintenance arrangement for bugs, updates and small improvements.

03 / EXAMPLE

Example: a two-week initial assessment

  1. Read-only access to the repository, the server and a copy of the database.
  2. An inventory of technologies, versions and dependencies with known vulnerabilities.
  3. A test that backups exist and can actually be restored.
  4. A map of the main flows and where each business rule lives.
  5. A prioritized list of risks and bugs, with impact and estimated effort.
  6. A proposal for immediate stabilization and phased evolution, with a fix-or-rewrite decision per module.
TOOLS
SAST tools (Semgrep and similar)Dependency auditingGitDockerNode.js / Python / PHP / SQLGitHub Actions
PROOF

Related work

GUIDES

Go deeper

Frequently asked questions

Should I fix my system or rewrite it from scratch?

It's usually best decided after the assessment, module by module. If the problems are concentrated in specific parts and the foundation is reasonable, fixing and modernizing incrementally is cheaper and safer. If the technology is no longer supported, every change breaks something different and maintenance costs more than replacement, a phased rewrite makes sense — preserving the business rules that today live only in the code.

Do you work with any technology?

I'm strongest in JavaScript/TypeScript, Python, PHP and SQL; I worked with PHP and SQL on a transactional system at Faena Uniformes. If your system uses another technology, the assessment will tell you honestly whether I'm the right person to maintain it or whether you should look for someone with that specialty.

Can we keep operating while the system is rescued?

Yes, that's the goal. The work happens in a separate development environment, with backups and tests, and changes ship in agreed windows. Replacing modules gradually lets the old system and the new pieces coexist without stopping operations.

What do I get at the end of the assessment?

A document with the system's state, prioritized risks, a per-module recommendation (keep, upgrade or replace) and a phased proposal with scope. That document is yours and useful even if you decide to do the work with someone else.

How much does a legacy system rescue cost?

The assessment is a bounded piece of work and the first thing worth doing, because without it any rescue or rewrite budget is a bet. After that, cost depends on the system's size, the state of the code, the security risks found and how many modules you decide to upgrade or replace. It's budgeted in phases, starting with what's urgent.

Do you offer ongoing maintenance?

Yes. After the rescue we can agree on a maintenance arrangement, usually a monthly block of hours, for security updates, fixes and small improvements. The cost depends on the system's size and how often it changes.

Want to talk it through?

If your situation sounds similar, tell me how you work today. I’ll tell you which part is worth automating or building first.