Deciding to replace your legacy application with a newer, bigger, faster application with the existing functionality your users have come to expect is not for the faint of heart. You likely have a huge investment in the original legacy app; users have learned how to navigate it and work within its strengths and weaknesses. It’s a known quantity.
Here are some tips on how to ensure the migration to a new generation is successful and embraced by the user community.
Signs Your Legacy App Warrants Replacement
Perhaps the most common reason for modernizing a legacy app is that it has been enhanced/updated/reworked so much over time that:
- It is no longer performant.
- It is not scalable.
- It has become too complicated to use.
- It has become a support nightmare.
- Technology/storage/capacity limits have been reached.
- The cost of maintenance and enhancement is no longer profitable.
- It has become such a patchwork jumble that it no longer presents well.
Or perhaps other factors are driving the decision:
- Industry needs or requirements have changed, so the legacy app can no longer keep up.
- The app no longer compares well with the competition that has similar applications.
- Technology offers opportunities for new functionality that the older legacy app cannot address.
If any of these reasons fit your situation, you have a vision – and hopefully a budget! – you’re ready to make the leap.
How to Avoid Legacy Application Migration Roadblocks
Naturally, every project is different, but here are some tips and potential roadblocks to watch out for when migrating your legacy app to a new generation.
1. Make sure everyone shares the same vision.
I’ve been invited to participate in projects where everyone agreed that the team needed a new visual direction. However, everyone seemed to have a different opinion on what that vision should look like or what that new direction should be.
Imagine how surprised everyone was when we’d meet to discuss the next steps only to discover that there were as many variants to the vision as attendees in the meeting. Marketing had one set of expectations, development had another, users weren’t included at all, and management just looked shell-shocked.
Make very sure everyone who gets a vote shares the same vision. This likely includes developers, users, product owners, marketing, sales, and of course, management. But you might also want to consider including people outside the organization. People not familiar with your app or industry can often offer insights that those close to the app have not considered.
2. Stay up on industry trends and the competition.
What kind of innovations are you seeing that pertain to your particular industry? Industry insights are particularly important if you operate in a highly regulated industry, such as medical or finance. You don’t want to start down a path that you later find conflicts with your industry’s direction.
Similarly, if you operate in a competitive space, knowing what your competition is doing is paramount. Your sales and marketing people – even perhaps your users – may be able to offer ideas.
3. Consider technology developments.
This one is probably obvious, but for completeness should be listed. Examples of this include:
- Software Technology
- Application Hosting and Deployment (the Cloud, for example)
- If your application uses technical devices for things like data capture or sensor monitoring
- Mobile app opportunities.
4. Map out how users will utilize the app and their role.
Consider who will be using the app and what functionality they will need. Take advantage of all you’ve learned from how the legacy app is used to better organize functionality into “sections” oriented toward each user role.
For example, a user whose primary function is updating data in the system will need different “tools” than a management person whose role is making decisions based on that same data. Try to separate your functionality visually so you don’t end up with cluttered screens that tend to confuse users.
5. Clearly document app logic and functionality.
Some people – especially those not technically minded – may approach the new development project assuming that if a particular functionality exists in the old legacy system, that functionality will somehow automatically find its way into the new system. Not so! Be careful not to make this assumption.
If you do not specify every functional piece you expect to be incorporated into the new app, you can expect surprise omissions. Even seasoned developers intimately familiar with the legacy system will likely not think to include everything the legacy app had to offer. Besides, some functionality in the legacy system may not be intended to be incorporated into the new app. Ensure that all the desired business logic and functionality from the legacy app are clearly documented as needed in the new app.
6. Plan for training.
Speaking of users, keep in mind how much retraining will be required. The new app should provide a better user experience. If it doesn’t, users will be slow to accept it. On the other hand, if the new app makes life easier/better for users, they will jump on the bandwagon much more quickly. Consider how you can leverage the extensive amount of knowledge and experience your users have with the legacy system and how you can use that knowledge to help them transition to the new system.
7. Keep the strengths, abandon the weaknesses.
You know a great deal about your legacy system. Take a step back and honestly evaluate its strengths and weaknesses.
- What do you like about the app?
- What would you do differently this time around?
The adage “Just because you’ve always done it that way…” doesn’t mean you have to completely scrap your legacy app’s approach to how things are done. If that approach makes sense, don’t just abandon it because it’s “old school.” It was designed the way it was for a reason. If that reason is still valid, consider incorporating that approach in the new app. It would be one less change your users won’t have to readjust to.
Some legacy applications remain relevant for many years beyond their original expected lifespans. There’s usually a reason for that. Sometimes it’s simply budget constraints, but often enough, forethought went into the original development that allowed it to endure. Decide what you expect the new app’s lifespan to be.
Of course, technology will continue to evolve significantly over the next few years. Industry standards and requirements will also change. These are things you cannot predict with certainty. But creating a resilient and agile application today can improve the new app’s life expectancy.
