Retiring legacy systems: Avoiding the pitfalls of large-scale migration

There are few things more certain in public sector digital delivery than this: every organisation has at least one legacy system that everyone agrees needs to go, yet no one quite knows how to retire safely.

I’ve worked on multiple programmes where the intent was clear from the outset — replace the outdated platform, modernise the service, reduce cost, improve resilience. On paper, these are straightforward goals. In practice, large-scale migrations are where good intentions go to fail.

The common assumption is that legacy systems are primarily a technical problem. They are not. They are organisational, operational, and often cultural problems that happen to be wrapped in technology.

What I’ve seen repeatedly — across departments and programmes — is that failure rarely comes from poor engineering. It comes from misunderstanding the service, underestimating complexity, and trying to force change at a pace the organisation cannot absorb.

This article draws on those experiences. Not theory, but the patterns that show up again and again — and how to avoid them.

Treating Migration as a Technical Exercise Instead of a Service Transformation

One of the most consistent pitfalls is framing migration as a system replacement rather than a service transformation.

Programmes often begin with a focus on the technology: selecting a new platform, defining architecture, planning data migration. All necessary, but incomplete. The real risk sits in the service layer — how people interact with the system, how decisions are made, and how work flows across teams.

In one programme I worked on, the replacement system was technically sound. It met requirements, passed testing, and was delivered broadly on time. Yet within weeks of go-live, workarounds began to emerge. Teams reverted to spreadsheets, manual processes crept back in, and confidence dropped.

Nothing had “failed” in the traditional sense. But the service had not improved.

What was missed was a clear understanding of how the legacy system was actually being used — not as documented, but in reality. Years of patches, informal processes, and local adaptations had created a service far more complex than anyone had captured.

As a business analyst or service designer, this is where you need to hold the line. Migration is not about replicating what exists. It’s about understanding the service end-to-end and making deliberate decisions about what should change, what should stay, and what should be removed entirely.

If you don’t redesign the service, the legacy system will simply reappear in a new form.

Underestimating the Complexity Hidden in Legacy Systems

Legacy systems are often described as “outdated” or “inefficient”. That’s true, but it hides a more important reality: they are also deeply embedded.

Over time, these systems accumulate layers of logic, dependencies, and tacit knowledge. Much of this is undocumented. Some of it is no longer fully understood by anyone still in the organisation.

I’ve seen migration plans built on the assumption that data structures are clean and consistent, only to discover late in the process that fields have been repurposed, duplicated, or used in ways never intended. What looks like a simple data migration quickly becomes a forensic exercise.

In one case, a single field carried three different meanings depending on context. It worked in the legacy system because people knew how to interpret it. In the new system, that ambiguity became a critical failure point.

The lesson here is straightforward: you cannot shortcut discovery.

Good discovery is not just about mapping processes. It’s about uncovering how the system behaves in edge cases, how users compensate for its limitations, and where critical decisions actually happen.

This takes time, and it often feels slow compared to delivery pressure. But every hour invested here saves exponentially more later.

As practitioners, we have to be comfortable challenging unrealistic timelines. If you don’t understand the system, you cannot safely migrate it.

Big Bang Migrations and the Illusion of Control

There is a persistent belief that large-scale migrations should culminate in a single, controlled cutover — the “big bang”.

It’s appealing. It suggests clarity, control, and a clean break from the past. In reality, it introduces significant risk.

I’ve been part of programmes where months — sometimes years — of work were tied to a single go-live date. Everything depended on that moment. When issues emerged, as they always do, the organisation had limited options. Rollback was complex, partial fixes were risky, and confidence eroded quickly.

Contrast that with programmes that take an incremental approach. Smaller releases, parallel running where possible, gradual migration of users or data. These approaches feel less dramatic, but they provide something far more valuable: feedback.

You learn early what works and what doesn’t. You can adjust before issues scale. You build confidence across the organisation rather than asking for it all at once.

This requires a shift in mindset, particularly at senior levels. It means accepting that migration is not a single event, but a process.

As a delivery lead, analyst, or designer, part of your role is to make that visible. To show that incremental delivery is not slower — it is safer, and ultimately more effective.

Ignoring the People Who Keep the Legacy System Alive

Every legacy system has a group of people who understand it better than anyone else. They may not have formal documentation. They may not even be recognised as experts. But they are the ones who keep the service running day to day.

Too often, these people are brought in late, or not at all.

I’ve seen programmes rely heavily on documented processes and system specs, only to discover critical gaps that frontline staff could have identified early on. In one instance, a key operational step was missed entirely because it sat outside the formal system — it was something the team “just did” to make things work.

The impact was significant. The new service could not handle a common scenario, leading to delays and manual intervention.

Engaging these users early is not just good practice — it is essential risk management.

This is where service design thinking becomes critical. You need to go beyond workshops and documentation. Spend time with users. Observe real work. Understand the pressures they operate under.

When people feel heard, they contribute more. When they are excluded, they resist change — often for valid reasons.

A successful migration is not just technically correct. It works for the people delivering and using the service every day.

Failing to Plan for What Happens After Go-Live

There is often a sense of relief when a new system goes live. The programme has delivered. The legacy system is decommissioned, or at least on its way out.

But go-live is not the end. In many ways, it is the beginning.

What I’ve seen repeatedly is a drop in support just when it is needed most. Teams are stood down, funding reduces, and attention shifts elsewhere. Meanwhile, users are still adapting, issues are still emerging, and the service is still stabilising.

In one programme, post-go-live support was underestimated. The initial weeks were manageable, but as usage increased, new issues surfaced. Without the right support structure in place, small problems became larger ones.

Planning for post-go-live is about more than hypercare. It’s about recognising that the service will continue to evolve.

You need clear ownership, ongoing user feedback loops, and the ability to iterate. This is where aligning with a live service model is critical — treating the service as something that is continuously improved, not something that is “finished”.

From a practitioner perspective, this is also where you can add real value. Ensuring that insights from early use are captured and acted on, rather than lost as the programme closes.

Final Thoughts

Retiring a legacy system is rarely about technology alone. It is about understanding a service that has evolved over years, sometimes decades, and guiding it through change without breaking what matters.

The patterns are consistent. Treating migration as a technical task. Underestimating complexity. Relying on big bang delivery. Overlooking the people who understand the system best. Assuming the work ends at go-live.

Avoiding these pitfalls is not about having a perfect plan. It is about approaching the problem with the right mindset — one that values discovery, embraces incremental change, and keeps the service, not the system, at the centre.

If there is one question I would leave you with, it is this:

When you plan to retire your legacy system, are you replacing a piece of technology — or are you truly redesigning the service it supports?