Modernizing Legacy Systems with Parallel Implementation

As a software developer, I don’t usually get excited about writing blog posts, but recently, I worked on a project that challenged me in new ways and taught me a lot about legacy system modernization, especially in high-stakes industries like finance, where stability is everything. Our client needed to keep their business running smoothly, even as a modern replacement for their aging platform was being built. The solution? Running both the legacy system and the new platform in parallel.

This post is not just about overcoming technical debt - it’s about finding a practical path forward when a full rewrite isn’t immediately possible. I believe a lot of people can relate to the example below, and I hope it can give some ideas on how you can approach similar challenges.

Background: Navigating the Realities of Legacy Systems

As we all know, developers don’t always work on projects “from scratch” or with the latest cutting-edge technologies. When a new software project begins, the target is always to make something sustainable, clean, efficient, and easy to maintain. However, as the software evolves - sometimes beyond its original scope - things can get complicated. The tech stack may not be able to scale along with the project and its requirements. Over time, as team members change, best practices may slip. It is rarely intentional and occurs naturally as the project evolves and faces new challenges. Sometimes, teams don’t have time to update to the latest version of packages, libraries, or framework versions, but rather focus on distributing new features and meeting business requirements. As a result, updates are often postponed until they include significant changes. Although it can work in the short term, in the long term, the team is forced to jump several major versions at once, which brings problems and compatibility issues, causing days and weeks to be resolved.

Inheriting a Legacy Platform in Finance

We faced similar challenges working with a UK client from the Finance industry. Originally operating as finance experts offering investment products and custom mortgage solutions, a few years ago, they transitioned into a fully licensed bank. Since then, they have expanded their portfolio, offering a broader range of services including savings accounts, residential and commercial mortgages, and retail finance solutions.

This growth put new demands on their software. Their legacy system, which handles both residential and commercial mortgage applications, was increasingly difficult to support. Since most of their in-house developers working on the project had left the company and we already supported several of their projects, they asked us to take over the legacy system until the new software was ready. From a technical perspective, the platform is built using PHP 5 with Laravel framework, AngularJS, Vue.js, and MySQL. With zero knowledge about the project, architecture, processes, and just a quick handover, it was challenging to support and maintain.

The project serves multiple user groups through a set of connected platforms. For the administrators, we have two internal websites. The first one manages the user’s access, permissions, and turning on and off accounts (the company’s employees and brokers we don’t work with anymore). The second website is responsible for managing firms and brokers, available products, taxes, and interest rates. Brokers, on the other hand, interact with a public-facing website where they can log in, create new mortgage applications, or track the status of existing ones. For more detailed input and submission, they use a dedicated application portal that guides them through filling in customers’ information and submitting mortgage requests for review.

Challenges of Supporting a Legacy System During Growth

Over the years, the project faced several challenges – some technical, others organizational, but all significant in their impact. One of the biggest turning points came as members of the core team slowly left the project. This knowledge gap made it difficult for new developers to confidently navigate the codebase and architecture, which often led to patches instead of long-term solutions.

At the same time, the business evolved, requesting new, highly tailored features and changes. While understandable from a business perspective, these changes made the system complex and difficult to maintain. On the technical side, staying up-to-date with dependencies proved difficult. Frameworks and libraries were often updated only when it was absolutely necessary, which introduced problems over time, especially as some technologies, like AngularJS, became deprecated. Scalability also became a growing concern, since the system was stretched beyond its original limits. All these factors are combined to make legacy system modernization not just a good idea, but a necessity.

Why Was a Full System Rewrite Essential?

Given the state of the current system, the need for a new software solution has become clear. With most of the members no longer on the project, maintaining or delivering the legacy platform became risky and time-consuming due to the lack of institutional knowledge. Running old versions of PHP or AngularJS, which no longer receive updates or community support, added further risks and long-term uncertainty. Additionally, years of business-driven customizations had resulted in an overly complex system, filled with tailored features, exceptions, and outdated automated processes. Due to a lack of maintenance, some originally automated procedures became manual. Team members now have to run them regularly to ensure consistent and timely data flow. Instead of continuing to patch and expand the system that was becoming increasingly fragile, our client decided to build a new platform from the ground up. One that’s focused on doing the job well, without overcomplication – scalable, maintainable, and future-ready.

Parallel Implementation: Bridging the Gap Between Old and New

You might wonder why we needed to run both systems in parallel instead of sticking with the legacy one until the new platform was ready. While this seems to be the most reasonable approach, in this case, it wasn’t.

Since the new platform was still in active development and didn’t yet include all the required business functionality, it wasn’t possible to make a clean switch overnight. At the same time, our client aimed to reduce investment in the legacy system, meaning we had to find a balance between maintaining critical updates and still developing some new demands from the business.

One of the biggest technical challenges was when Amazon announced the end of standard support for MySQL 5.7. Migrating MySQL from 5.7 to 8.0 was an essential step that came with major risk. This process alone required nearly two months of planning, testing, code adjustments, and workaround implementations across the entire platform.

The goal was simple: ensure a smooth transition without any downtime or disruption in the live environment. And we achieved it. Running both systems in parallel gave us some strategic benefits.

Real-world user testing

Our client invited a group of long-time brokers to test the new system. Their feedback helped us identify bugs, suggest improvements, and shape the overall user experience. This also gave us a unique opportunity to compare some characteristics and workflows performed in the new system versus the old one, providing direct insights into performance and usability.

Controlled rollouts

At first, we started by adding low-risk products that can be handled with ease. This allowed the team to identify and resolve issues in a controlled environment without significant business impact. Thе approach also built user confidence and familiarity with the new system before expanding to more complex products.

Reliable fallback

Meanwhile, the legacy system remained fully operational, providing a reliable fallback in case anything critical happened with the new platform. This reduced the pressure for the new system to be perfect from day one, allowing the team to focus on building a stable foundation and gradually layering in more complex features with confidence.

Smoother onboarding

From the client's side, this dual-system approach also made onboarding smoother for underwriters and internal staff. It gave them a chance to get firsthand experience with the new software gradually, without pressure, and to build confidence as the system matured.

Once both systems provide identical features, our client plans to make a full transition. The old system won’t be shut down straightaway but kept on standby until we are sure everything is working as expected and there are no major issues that could disrupt our client’s business. As for data management, one option is to review and clean up the existing database by removing unused tables and columns; another is to start with a new database and migrate only the necessary data from the old system.

Lessons Learned from Running Two Parallel Systems

While the transition is expected to be straightforward, in order to make it as smooth as possible, the following steps should be taken:

• Test all features and ensure a positive outcome
• Prioritize internal training for all teams working daily with the new software
• Plan a rollout date for the new system
• Inform third parties (firms, brokers) of the transition
• Send out documentation, including how-to guides, and offer support

Conclusion

In conclusion, I can say that the complexities of maintaining a legacy system while building a new one from scratch are no small feat. Yet, by running both in parallel, we found a practical, low-risk way to support business continuity while embracing modern software practices. This journey not only highlighted the importance of balancing short-term needs with long-term goals but also showed how thoughtful planning, open communication, and a bit of flexibility can make even the most challenging transitions manageable. It’s been a valuable experience for us as software engineers and for our client as they move toward a more scalable and future-ready platform. We’re excited to see how the new system evolves and proud to have played a part in this transformation.