Legacy without panic: how to safely take over an old app

Discomfort is not risk

Code can be ugly and stable, while a polished new module can lack a working backup. Instead of asking whether the technology is old, ask what happens during the next change or incident: can the environment be recreated, the error found, the data restored, and the deployment rolled back?

If the application supports an important process, a rewrite with a large scope can freeze development for months while recreating rules nobody wrote down. That is a risk assessment for the specific project, not a universal statistic. Reduce operational risk and learn the system boundaries first.

• Do we know the critical processes and data?
• Do backup and restore work?
• Can deployment be repeated without the original author?
• Do we know roles, permissions, cron jobs, and external APIs?
• Can we measure that a fix did not make behavior worse?

A takeover starts with access and recovery

Collect repositories, cloud accounts, domains, certificates, services, secrets, scheduled jobs, and environments. Do not keep secrets in an ordinary document; decide who can access them and how they can be changed safely. Repository access alone does not mean the system can be started.

The first stage should end with a short map: how to run the project, deploy it, find logs, restore data, identify manual steps, and record what is still unknown. Eurostat reported that in 2024, at least one ICT incident was reported by 22% of surveyed enterprises in the EU and 32% in Poland. This is the share of businesses reporting an incident, not the probability of failure for this application. It is a reason to test the process, not to fear every old dependency.

Missing tests do not require an immediate rewrite

When tests are missing, start with representative data, logs, outputs, and observation of user work. A characterization test records current behavior and protects against accidental changes, but it does not prove that current behavior is correct. That requires the process owner’s context.

AI can find entry points, name modules, identify similar functions, and draft a test. It cannot confirm that an odd behavior is a bug rather than an informal business rule. Compare every generated description with real behavior.

Prototype a change behind an observable boundary

A safe change prototype has a limited scope, a separate environment, test data, a success metric, and a rollback instruction. In legacy, a good boundary can be one endpoint, document type, process step, or user role. It does not need to be perfect; it needs to be observable and reversible.

A feature flag, shadow mode, old-versus-new comparison, or small user group lets you learn without switching the whole system. NIST’s SSDF organizes secure development around preparing the organization, protecting the software, producing secure software, and responding to vulnerabilities. NIST’s DevSecOps model connects planning, building, testing, release, deployment, and operations with monitoring and feedback. The specific rollout technique is a practical choice for the system, not a guarantee supplied by a standard.

• write down what changes and what does not;
• prepare a backup and test restore;
• log differences between old and new paths;
• decide who can roll back and what signal triggers it.

AI can help with production, but it does not own responsibility

A model can prepare a test, migration sketch, log analysis, or proposed fix. In production code it must work without secrets or uncontrolled access, and the change should be visible as a diff, tested on safe data, and reversible. In the self-selected 2025 Stack Overflow Developer Survey, 66% of respondents reported frustration with “almost correct” solutions and 45% said debugging AI-generated code took more time than writing it themselves. These are developer reports, not an audit of every model, but they show why review remains necessary.

A rewrite makes sense when no safe change boundary exists, the data model blocks required security, or every further fix costs more than replacing a specific area. Replace in stages where possible, preserving knowledge of what the old system actually did.