Legacy System Migration

The Problem With Doing Nothing

Every organisation that's been running software for more than a few years has at least one system that's become difficult to maintain. The framework is out of support, the original developers have moved on, and the team that inherited it spends a disproportionate amount of time keeping it running rather than improving it. The business adapts around the limitations, processes get built to compensate for what the software can't do, and the cost of the workarounds becomes invisible because it's spread across the organisation.

The other pressure is security. Older frameworks and languages fall out of active support, dependencies stop receiving patches, and the attack surface grows. This isn't theoretical - it's a compliance risk, a reputational risk, and increasingly a commercial risk as clients and partners ask harder questions about the platforms they're integrating with.

None of this means every legacy system needs replacing. Some are stable, well-understood, and doing their job. The question is whether the system is holding the business back, and whether the cost of maintaining it has quietly overtaken the cost of replacing it.

The Migration Spectrum

There's a common misconception that legacy migration means a complete rewrite - throw everything away and start again. Sometimes that's the right answer, but it's rarely the only one, and it carries the highest risk. The options sit on a spectrum:

Incremental refactoring works when the existing system is fundamentally sound but has accumulated debt in specific areas. You identify the worst pain points, modernise them in place, and gradually improve the codebase without disrupting the overall system. This is the lowest risk approach, but it's only viable if the underlying architecture can support the changes.

The strangler fig pattern involves building new functionality alongside the old system and progressively routing traffic and data to the new components. Over time, the old system shrinks as the new one grows around it. This works well when you need to maintain continuity of service but the existing architecture can't support the changes you need to make.

A full rewrite is appropriate when the existing system is beyond incremental improvement - the technology is obsolete, the architecture is fundamentally wrong for what the business needs, or the codebase has deteriorated to the point where maintaining it costs more than replacing it. This is the highest risk option, but when it's the right call, it's the right call.

The choice between these approaches is one of the most consequential technical decisions a business can make, and it needs to be informed by a clear understanding of the current system, the target state, and the constraints around budget, timeline, and team capacity.

How I Approach It

Every migration starts with an assessment. I need to understand what the current system does - not just the documented functionality, but the undocumented behaviour that users and processes depend on. Legacy systems accumulate implicit knowledge over the years, and a migration that doesn't account for this will break things that nobody realised were important until they stopped working.

From the assessment, I produce a migration plan that covers the target architecture, the migration strategy (which of the approaches above, or a combination), the phasing, the risks, and the rollback options at each stage. Phasing is critical - a migration that tries to do everything at once is a migration that's likely to fail. Breaking it into stages, each with a clear deliverable and a way to reverse course if needed, is how you manage the risk.

During the execution, I'm hands-on. I write code, I review code, I manage the cutover, and I make sure the team understands the new system well enough to maintain it after I've moved on. The goal is a clean handover, not a dependency.

Where I've Done This

At SUMAC, I led a complete platform rewrite over several years. The existing system had served the business well but couldn't support the growth and the feature requirements that the market was demanding. I rebuilt the platform on PHP 8 and Laravel with a Vue.js and Livewire front-end, containerised the infrastructure with Docker, and implemented CI/CD pipelines that the team could maintain independently.

The critical detail is that we maintained 100% customer retention throughout the transition. Not a single client was lost during the migration, because the process was planned carefully, communicated clearly, and executed in stages that minimised disruption. The platform went on to support the company through a successful acquisition, where the quality of the rebuilt system was a material factor in the technical due diligence.

At Tokheim, earlier in my career, I ported an internal intranet from classic ASP to Laravel - a smaller scale migration, but one that taught me the importance of consulting with end users throughout the process. The technical migration is only half the job; bringing the people along with it is the other half.

---

If you're running a system that's becoming harder to maintain, more expensive to operate, or unable to support what the business needs next, get in touch.