Legacy System Migration: A Decision Guide

Legacy system migration is the decision to stop running the business on a system you can no longer support, change, or connect, without pretending the move is one clean switch. Age is a weak test. A long-standing tool that is still supported, still understood, and still meets the work is not automatically a problem. A newer tool that one person understands, with no vendor support and no way to connect, is.

This guide is about operational systems: a CRM, a job tracker, a custom database, the desktop app the office still depends on. It is not about switching AI vendors. That decision, including prompts and vendor-locked workflow logic, is covered in AI migration costs. The risks here are different. Downtime and data loss are among them. They are risks you plan for. They are not outcomes anyone can promise away.

When a legacy system migration is the question

The Central Digital and Data Office defines legacy IT by burden and risk, not by age or fashion: systems whose continued use creates a persistent, unacceptable burden or risk, and that can no longer be supported or secured effectively or economically.

A system is classed as legacy if any one criterion is unacceptable: out of support; contracts or licences needed to run it have lapsed, with no continuity arrangement; not enough people know how to maintain it; it cannot meet current needs or the next ones; the hardware is failing or cannot be repaired; it fails minimum cyber security standards; or it depends on something else already classed as legacy. “Action required” means not yet over the line, but expected to be within 12 months if nothing changes. That 12 months is their classification window, not a migration timetable.

The Government Digital Service lists reasons teams move: support has ended, a contract is about to expire, the system cannot support a needed change, the risk of keeping it is too great, or the burden of maintaining it has outgrown the case for keeping it. None of those is “it looks old”. GDS also includes retain, beside retire, re-host, repurchase, and re-platform. If the system is understood, supported, and still fit, moving can be the larger risk.

Strangler fig, big bang, or parallel running

A big-bang cutover moves everything in one event. Mapping errors, missed exceptions, and integrations land in the same window. Downtime is possible. So is data loss, including records that arrived in the wrong shape. Big bang is sometimes the honest choice. Microsoft’s notes on the strangler fig pattern say it fits poorly when you cannot intercept requests, cannot change the old system, the system is small enough to replace whole, or you must decommission quickly. A contract end date can force it.

The strangler fig, Martin Fowler’s name for a gradual replacement, moves one capability at a time. New work goes to the new system. The old system stays until nothing important depends on it. Fowler is clear this does not make the work easy: old behaviour is often unwritten. The point is a smaller blast radius, not a quiet cutover. You will need a route that sends some work each way. Microsoft describes that route as a façade, and warns it can become a single point of failure.

Parallel running is different. Both systems process the same work so you can compare results before one becomes the source of truth. It does not prove the new system is right, and it does not remove cutover risk. It means two processes, for a period you define yourselves.

Re-hosting moves the same system with little change. Re-platforming changes the footing and keeps more behaviour. Replacing means buying or building something else, and accepting the fields will not match. If an off-the-shelf tool never matched the work, another can repeat the mismatch. Settle that before a cutover plan. The test is in when off-the-shelf is not enough.

What to inventory

You cannot pick a strategy from a product name. GDS treats a register of systems, and of the data they hold, as a precondition:

The business steps, including exceptions. If they live in one person’s head, write an SOP while they are still there.
Every data store: where it sits, who owns it, which fields matter, and what a blank means.
Every API integration, file drop, export, and manual copy. Who calls this system, and what it calls.
Support dates, licences, and whether you can extract data in a form the next system can use. An export that exists is not data portability.
The people. One person who can explain the status codes is a staffing risk whether or not you move.

Mapping, parallel running, and rollback

The hard part is a field with no honest home in the new system. Fields collapse. A value calculated on screen was never stored. Status words do not match. Duplicates attach to the wrong customer. History does not fit. Data quality problems you have lived with become blocking errors. Clean a sample of the awkward records before anyone talks about a full load, and compare it to a written mapping. If personal or financial records are in scope, check that mapping against obligations you already have, with your existing advisers. Fernside does not provide legal or accountancy advice.

Decide, in writing, which system is the source of truth, and who may change that. Without that sentence, parallel running produces two sets of edits and no winner. Compare cases you chose in advance, not only the clean ones. Name what difference halts the cutover, who decides, and how they reach someone who can still use the old system. Downtime may happen. Data may be missing, duplicated, or altered. No pattern removes those risks. A plan that says “zero downtime” or “no data loss” has skipped that decision.

Keep a copy you can restore, and know how current it is. A rollback that needs data you have already deleted is not a rollback. Microsoft’s notes make the same point: while the old objects exist, going back is conceivable; once you remove them, the risk jumps. Leave the old path until the new slice has done real work, then decommission that slice, not the whole estate. A visible boundary is not a safe one.

What this is not

Fernside does not migrate a system on a timetable. We will not tell you the move will be painless, or that it will take a given number of weeks. Downtime and data loss remain risks you plan for.

Advisory is a paid scoping engagement: architecture, a roadmap, and a vendor comparison. It is not the migration. A later build, if you choose one, is separate project work under AI systems. Scoping does not commit you to that build, and a build should not start until the inventory and the rollback story exist.

Write the map, then send an enquiry if you want a scoped plan rather than a leap.