Knowing When and How to Migrate From the Legacy System

Legacy System Held Back the Business Processes

I was hired in one of my previous roles to review their system, which was built around 2005, making it a legacy system. We all know that the problem with legacy systems is that if you don’t actively maintain them, chances are they will become outdated. So, when I joined the team, the team was a very small group of engineers working together, and in order to maintain and evolve a system that supported a B2B2C was a challenge.

As I stepped in, I was expected to partner with the product and think about ways to move away from the legacy system to deliver quickly while migrating to a better and newer experience. The problems were that I did not have enough resources, a sound technical strategy, or operational support to build the product. Altogether, there were operational challenges and technical challenges that drove no results.

Evaluate the Legacy System

My first action was to shake hands with my product counterparts to plan out how to proceed with the problems at first. To make a significant impact, we focused on the customers’ pain points, followed by devising the first strategic priority in the product vision. Then we got an alignment and found pilot customers who’d join us throughout the journey.

Based on the product and UX vision, we formed a technical strategy. Instead of rebuilding the entire platform, we used the strangler pattern to replace only a part of the experience. Eventually, we commingled the experience to find a way out of the legacy system. Once we had the first version of the product vision, requirements, UX vision, and tech strategy, we started developing a resource plan with the information.

For instance, it covered all the details, such as how many people we needed and the hiring plan B so that we could start executing that vision. Additionally, we could figure out the tech strategy for the next 6 to 9 months of timeframe.

Operationally, we focused on one problem rather than having a standard process from the beginning. We solved it bit by bit, whether it was stakeholder management, coordination problems within the team, or even budgeting. In essence, we let the problems surface in the team retrospective meetings to learn about the operational challenges and fix them.

Take the Processes Slower

• If you are migrating from an extensive legacy system, it is certainly not a good idea to do it all in one go. Break the process down into smaller pieces, do it iteratively, and incrementally launch the new system.
• Solve the problems that are more difficult in the early stages. In our case, operational problems were the tough ones, so we structured the team before proceeding with solving technical challenges.