The legacy system you cannot switch off yet

You cannot switch a legacy system off because it still owns something the replacement does not: the data model, the integrations, or the compliance record. A legacy system replacement plan sequences the switch so the old system runs in parallel until the new one proves it can take every load, then decommissions it cleanly.

Key Takeaways

• A legacy system stays on because it owns data, integrations or compliance records the replacement has not yet reproduced.
• The strangler pattern replaces a system flow by flow behind a routing layer, so the old box shrinks instead of being switched off in one cut.
• A read-only archive is the cheapest end state when the system only serves occasional reads — do not over-engineer a full migration.
• Verification means replaying real traffic and diffing responses, not running a few manual test cases.
• Big-bang rewrites lose the one asset a legacy system has: known behaviour. Parallel running preserves it.
• Security is usually the trigger: an unpatched legacy box on the internet is an incident waiting for a scanner.
• The plan is only done when the old system is archived, credentials are revoked and the retention clock is documented.

Why can't you just switch the legacy system off?

You cannot switch it off because the system is a dependency graph, not a single application. Payroll, stock, customer lookup and month-end reports all read from it. A replacement that misses one edge of that graph fails on the first real run. That is why "turn it off" is never a one-line decision.

The deeper reason is data gravity. The longer data lives in one schema, the more processes assume its shape — the null that means "not applicable" for one team and "pending" for another, the timezone stored without an offset, the customer record that exists twice. No diagram captures these assumptions. The people who knew them have often left.

Then there is integration debt. Other systems call the legacy box through undocumented endpoints, scheduled jobs fire at odd hours, and reports export from it on the last working day of the month. Switching it off without tracing every caller breaks something that nobody remembers was connected.

When does a legacy system genuinely need a replacement plan?

You need a formal plan when the old system still takes writes or serves live traffic that the new stack cannot yet reproduce. If it only answers occasional reads, a read-only archive is the cheaper, safer end state. The trigger is usually risk: an unsupported runtime, a compliance gap, or a key person who left.

Signals that a full replacement is warranted: the database still receives writes, the runtime is end-of-life, more than a handful of integrations depend on it, or nobody left on the team can explain its behaviour. Signals that an archive is enough: traffic is read-only, usage is occasional, and the data is only needed for historical lookup. Choosing between a custom rewrite and an off-the-shelf replacement is often the first real decision.

Do not start a replacement plan just because the system is old. Age is not the problem. Unsupported, unpatched and unwritten is the problem. A ten-year-old system that is stable, backed up and understood by two people may be cheaper to keep than to replace.

How does the strangler pattern actually work?

The strangler pattern replaces a legacy system capability by capability behind a routing layer. You point one endpoint, queue or scheduled job at the new service, watch error rate and latency, then move the next flow. The old system shrinks until it serves only the flows nobody has migrated, then you archive it.

The routing layer can be as simple as an NGINX rule or an API gateway that sends one path to the new service and everything else to the old box. The key discipline is moving one flow at a time. If you strangle "customer lookup" and the error rate stays flat for a week, you move the next flow. If it spikes, you route back instantly — the old system is still there as the fallback.

Containerising the old application on Docker is often the cheapest way to keep it running on supported infrastructure while you strangle it, and the Docker documentation covers the mechanics. Before any cutover, take a read-only snapshot of the legacy database so you can always reconstruct the pre-migration state:

# Read-only snapshot before any cutover — nothing is written or changed
pg_dump --no-owner --no-acl legacy_db > legacy_pre_cutover.sql

This command only reads data. Before you depend on it, restore the dump to a scratch instance and confirm it loads, because a backup you have not restored is a hope, not a plan. The PostgreSQL pg_dump documentation lists the flags if your version differs.

Step-by-step: building a replacement plan

Start by mapping dependencies, not by writing code. List every caller, scheduled job, report and API consumer that touches the old system. Then pick the smallest self-contained flow, build its replacement, run both in parallel, and only then repeat for the next flow.

1. Inventory callers and data flows. Grep logs, check cron entries, ask the person who has been there longest. You are looking for the flows nobody documented.
2. Lock the schema or take a read-only snapshot before you change anything. Treat the legacy database as evidence, not a sandbox.
3. Pick the smallest flow. One endpoint or one report, not the whole order pipeline. Small blast radius keeps rollback cheap.
4. Build the replacement against real data, not a toy fixture. Production has the weird records your fixtures do not.
5. Run both in parallel and diff responses. Set a threshold for acceptable divergence before you route traffic.
6. Route live traffic gradually to the new flow. Watch error budget, latency and queue depth after every move.
7. Repeat for the next flow until the old system only serves historical reads.
8. Archive, revoke credentials and switch off. Switching off is irreversible — keep the archive and a written restore procedure before you do it.

This is the part where an experienced team earns its keep. Our team can help you scope and run a replacement plan without losing the behaviour the business depends on.

Which replacement strategy fits which system?

Four patterns cover most replacements. A strangler migration suits systems that still take writes; a big-bang cutover suits small, low-risk tools; parallel running suits finance or payroll where reconciliation matters; a read-only archive suits systems that only answer occasional lookups.

Strategy	Blast radius	Effort	When it fits
Strangler pattern	Low per flow	High total	Systems taking live writes
Parallel run	Medium	High	Finance, payroll, reconciliation-heavy flows
Big bang	High	Low to medium	Small, low-risk tools
Read-only archive	Low	Low	Historical lookups with no new writes

How do you verify the replacement is safe before cutover?

Verification means proving the new system matches the old one on real traffic, not on test data. Replay a day of production logs through both, diff the responses, and compare reconciliation totals. Only route live traffic when the diff rate is below your agreed threshold.

Set up a read replica of the legacy database and point the new system at it first. This lets you exercise real queries without touching the source of truth. Then run a shadow traffic pass: send a copy of production requests to the new service and compare responses field by field. Pay attention to rounding, timezone handling, null versus empty string, and sort order — these are where silent divergence hides.

For finance or payroll flows, reconcile totals rather than individual records. If the new system's month-end total matches the old one to the penny, individual formatting differences matter less. If totals diverge, stop and find the root cause before moving another flow.

What fails in production and how do you debug it?

The most common failure is silent data divergence — the new system returns a different value and nobody notices until a customer calls. Check reconciliation totals first, then integration error logs, then latency and queue depth. If totals match but users see differences, the bug is in presentation or caching, not data.

• Silent divergence: diff a sample of responses and check rounding, null handling and timezone conversion first.
• Missed scheduled jobs: check cron and job logs in the new runtime, then compare timezone settings with the old box.
• Integration timeouts: verify network egress rules, firewall changes and API rate limits between the two environments.
• Retention violation: confirm the archive is still readable and the retention clock is documented in writing.
• "It works in staging": staging usually lacks the data volume and the strange records production has accumulated over a decade.

Keep the old system in read-only mode for at least one full business cycle — a month-end close, a payroll run, a year-end report — before you even discuss switching it off. A week of quiet is not proof. A quarter-end reconciliation is.

What does this cost in real terms?

A replacement plan costs engineer time more than licences. The main drivers are how long the old system runs in parallel, how many integrations you must re-point, and how much historical data you must migrate and verify. An unsupported legacy box usually costs more to keep than to retire.

Parallel running doubles the operational surface for a while: two systems to patch, monitor and back up. Integration re-pointing is often the hidden cost, because every undocumented caller is a small project. Data migration is rarely a one-time job — it is a migration plus a verification pass plus the fixes that the verification pass uncovers.

The cheapest option is often the read-only archive when the system no longer takes writes. Before you commission a full rewrite, ask what the old system actually does today, not what it was built to do ten years ago. If the answer is "serve occasional lookups", an archive beats a migration. For a proper scoping of your situation, talk to our team — the review is where every good plan starts.

What security traps sit inside legacy systems?

Legacy systems often run unpatched dependencies, hard-coded credentials and weak authentication because the people who understood them left. Check public exposure first, then who can still sign in, then what data leaves the box. An unpatched legacy system on the internet is a breach waiting for a scanner.

Start with the network boundary. If the legacy app is reachable from the public internet, put it behind a VPN or at minimum a restrictive firewall while the replacement is under way. Then audit accounts: legacy systems accumulate ex-employee logins, shared passwords and service accounts nobody can name. Revoke what you cannot justify.

Check TLS versions and the runtime's end-of-life status. A PHP 5.6 app or a Windows Server 2008 box cannot be patched for known vulnerabilities. That alone is often the business case for a replacement plan. Our maintenance team regularly hardens systems like these while clients sequence a longer-term move.

Common mistakes teams make with legacy replacement

The most expensive mistake is a big-bang rewrite because the old system "has to go". You lose the one asset a legacy system has — known behaviour. The second mistake is not writing down the unwritten rules: the 2 a.m. batch job, the special case for one customer.

• Replacing everything at once — you lose the fallback and the known behaviour in the same weekend.
• Ignoring the people problem — staff who have used the old system for years will route around the new one if it feels slower or different. See why staff keep using the old system.
• Migrating data without reconciliation — moving rows is easy; proving they mean the same thing is the work.
• Leaving credentials alive — a decommissioned system with an active admin login is not decommissioned.
• No rollback path — the old system is the rollback path until the archive is proven readable.

A realistic scenario: the order system that cannot stop

A distribution company runs order processing on a ten-year-old system. The database still takes writes, three warehouses call it through undocumented APIs, and finance reconciles from its reports. The team cannot switch it off because no replacement has reproduced the integration contracts.

"The system is the documentation," the longest-serving engineer told us. "We know what it does because we watch it do it."

The plan we would sequence looks like this. Week zero: lock the schema and take the read-only snapshot. Week four: stand up a read replica and point a new reporting service at it. Week eight: route the first read-only flow — customer lookup — through a strangler rule and diff responses for a week. Week twelve: run the busiest month-end in parallel, old and new, and reconcile totals. Week sixteen: the old system serves only archive reads; credentials are revoked, the archive is restored to a scratch box to prove it works, and the power is pulled.

In short

• Do not mistake age for risk — unsupported, unpatched and undocumented is the real problem.
• Map every caller and data flow before you write a line of replacement code.
• Run old and new in parallel and reconcile totals, not just spot checks.
• Archive the old system read-only, revoke credentials, and prove the restore before you switch off.

People also search for

• How to choose between a custom rewrite and an off-the-shelf replacement
• What to do when staff keep using the old system after a migration
• Which hosting fits a replacement system once it leaves the legacy box
• What actually drives the cost of a web build
• How a development team scopes a legacy replacement
• Common questions about replacing business software

A legacy system replacement plan is less about the new technology and more about not losing what the old system already does correctly. Our team can help you review what is actually running today, map the dependencies nobody wrote down, and sequence a switch-off your own staff can operate. See the kind of work we have shipped in the portfolio.