1. ASSESS IMPACT ON USERS
When migrating your legacy application, first you need to identify the reasons for the migration. There are 3 angles to consider: the business goals, technical drivers and impact on users.
The area that is often overlooked is the impact on users. When that happens, the business misses out on an opportunity to significantly enhance its offering.
Assessing the impact on users will help enable a seamless transition to the new system. When you migrate your legacy application, you are not just migrating components and features but also users and workflows. You will need to decide on whether you want to migrate a subset of those first, and which ones to start with.
To help make that decision, you can create a matrix of existing workflows and user groups. You then create a heatmap of the areas that are most used by each set of users. Knowing the percentage of users in each user group will help inform the prioritisation as well. This can allow you to gradually migrate users and workflows adding value early on.
You might want to start migrating a subset of users from one or multiple user groups, an entire user group, or all users. Workflows could be in the legacy system or the new system or in both. The choice you make will also depend on the migration option you choose.
2. CHOOSE A MIGRATION OPTION WITH USERS IN MIND
Choosing your migration strategy depends on the business drivers and constraints. There are a few options and pros and cons to each. The appropriate one to choose will depend on your goal and the context. The main migration options are:
1. A Big bang migration where you transfer from the legacy to the new system in an instant changeover. When one switches off, the other one switches on.
There’s a high risk if the system fails or if the new system interferes with the users’ way of working. However, a big bang migration might sometimes be your only option if for instance the legacy and new system can’t coexist. Doing a lot of testing with focus groups can help collect some early feedback from users before the new system is launched.
2. An Incremental migration allows the legacy system and the new system to coexist and be used simultaneously. You gradually transfer to the new system so you introduce it to users early and therefore reduce the risk. It gives you an opportunity for enhancements as you can gradually gather users’ feedback and incorporate it into each iteration.
The challenge with this option is to make the transition between systems seamless especially when user workflows cut across both. You also have to decide on whether in the context you’re working in, it is more beneficial to make it obvious for the users that they are using two systems or whether you want it to be more subtle.
3. A Parallel migration allows users to switch between the legacy and new system. The two systems run simultaneously. Once the criteria for the new system are met, the legacy system is disabled.
The risk is reduced because you can toggle between the two systems but it is costly to run both. In terms of users, it makes the adoption less likely because users can stick to what they’re used to and are not forced to change immediately. However, it might give users some reassurance because they can always switch back to the legacy system while having the opportunity to try the new one.
For example, Outlook allows users to toggle to the new outlook using a toggle switch while giving them the option of switching back.
4. Incremental parallel migration as the name suggests is a combination of the incremental and parallel migration options. The new system is introduced in phases and runs in parallel with the legacy system until the latter is disabled. Unlike the incremental migration, in this option, the legacy system is not gradually decommissioned.
It reduces the risk with the early introduction of the system allowing early feedback and the opportunity for enhancements. It keeps the legacy system running which gives the flexibility of keeping some users entirely on the legacy system until they are ready to move.
3. PLAN YOUR STRATEGIC ROADMAP
When migrating your legacy system, having a strategic roadmap enables you to outline your end goal and plan ahead so you avoid any potential rework. Regardless of which migration option you choose, there are three main areas in your roadmap you’ll need to plan for.
1. Product Expansion
These are new features that you are adding to your new platform and that were not available in your legacy system. The migration is an opportunity to highlight the unique offering that your business provides users, giving you a competitive advantage. It can help attract new users as well as improve the experience of your existing users. An example of product expansion could be a chatbot assistance functionality in your new system which you didn’t have in the legacy application and that can help you reduce the number of calls to your support team.
2. Investment in platform
These are features that are cross cutting and that present a new direction that will affect the entire application. For example, in your new platform, you might want a design that is mobile compatible and you might want to support localisation. These are decisions that are better made early on in the process and included in your roadmap.
3. Enhancements
These are improvements that could be done either on the legacy application or on the new system. You would need to weigh whether it is more beneficial to do them on the legacy system even if it means having to redo them in the new system, or whether it is better to wait. This will depend on the effort involved and the benefit to users.
CONCLUSION
When it comes to migrating legacy applications, planning ahead and keeping users in mind will be key to making sure the new system is adopted and welcomed by users. Migrating legacy systems is not merely a process of moving existing features to a new system but rather an opportunity to build a strategic system that supports your business goals and ensures adoption by existing and potentially new users.
