There are many reasons to consider modernizing your legacy software. But when doing so, it’s important to remember your customers who regularly use your product and to take their preferences, habits, and needs into consideration. Here are some practical tips to boost your chances of a smoother transition.
Many companies make the mistake of only focusing on new system functionality and technology improvements and forget the importance of what clients like about the legacy system. Sometimes it’s worth considering the adage “If it ain’t broke, don’t fix it.”
But if you are going to press ahead and modernize that legacy system, configuration management best practices can help you be successful. The first step is a functional configuration audit to review and fully understand your existing functionality. Here are some practical tips to boost your chances of a smoother transition.
Tip #1: Analyze the platform from a business perspective
Chances are good that a large percentage of your business revenue is coming from your legacy platform. Your existing clients are using it, there are things they love about it, and they are not going to be pleased if some functionality ends up missing after modernization. That’s why you have to analyze the current system in depth.
Send a couple of business analysts to work directly with your customers and key client-facing business teams: customer support, client advocates, and account managers. This group will know which features have kept customers happy. Customers need to be interviewed so you can build a complete picture of the key functionality provided by the legacy system and hidden features. Besides collecting data points from business teams and end-users, you also need to go through the system screen by screen and capture every piece of existing functionality. Often, business teams don’t know everything clients are using; that’s why it’s a good idea to do your own analysis.
In particular, look at what the top-revenue customers on the platform are using. How does their system behave differently due to configuration or customized differences? Document everything, no matter how small. When you’re done, you should have a complete map of key users’ workflows so you understand the legacy system from a user and business perspective.
Tip #2: Perform source code analysis
In parallel with the business analysis, you need a team of developers to examine the existing source code. In this case, your version control system is your source of essential information. The developers should map out all of the key functionality based on existing code logic, and special conditions in the code based on some hidden flags or settings. The idea is to capture a picture of all the idiosyncrasies and hidden functionalities that may have been forgotten over time but are still being used by someone daily.
A lot happens in the back end; there may be workarounds you can’t see by working through or capturing the screen flows. Often, these details aren’t common knowledge; they may have been put into the code years ago by developers to solve some time-critical client problem.
When you merge the business analysis with the source code analysis, you should have a solid overview. You’ll get user stories for every single scenario the current legacy system supports and the details you need on how it actually works.
Tip #3: Map the functionality and find the gaps
You need to map all the existing functionality and figure out how it will work in the new system, including dependencies. It must be able to do all of the “client-important” things, even if it does them in a slightly different manner. Typically, you might find around 35 percent will work the same way in the new system as it did in the old. Perhaps another 35 percent of the functionality will map but will work slightly differently. Most likely the remaining 30 percent of the functionality is gap.
Finding the gaps is about identifying the 30 percent of the functionality that’s missing. Where are the gaps between the old and new systems? What interfaces will be required? Once you have found them, you have to decide how to update the new platform to accommodate this missing functionality, or identify functions that can be dropped. Go back to the client and confirm what functionality they use or don’t use. You can prioritize the missing functions from your gap analysis and maybe drop up to 15 percent of that missing functionality.
For the rest, you’ll need a plan to solve each gap in the new system and make sure the functions your customers need are going to be in place. What you must avoid is a situation where clients are moved across to the new system and they find that functionality they commonly use simply isn’t there.
Tip #4: Consider data mapping and migration planning
The legacy system may have years’ worth of data in it. You can’t assume this will be easy to migrate. You need to consider how it will map across from the old system to the new. Data doesn’t always map cleanly in the new data model; sometimes, some fields are missing. You may need a stopgap solution to act as a bridge. If you plan carefully from the outset, you can make sure there are no gaps and the data can be migrated smoothly. This is critical, as many times a data migration is an afterthought, and by that time it is too late. Plan the migration strategy as part of the new system design. You may very well have to carry some old baggage from the legacy system to the new system in order to accommodate a smoother migration of data.
Tip #5: Estimate as accurately as possible
Now that you have a thorough set of requirements for the system and data migration plan, you can begin to estimate what it will take to modernize it. You should set the expectations that there must be deviations in estimates even when you already have all the details about what needs to be done. The deviations will be minimized, and the total effort, cost, and schedule estimate will be better known when the development team starts working, adhering to agreed quality standards and measuring productivity in a few iterations. That does not mean the early estimate has no value; it’s important for business or budgeting decisions to have the early high-level estimates.
You can work out exactly what’s needed in terms of time and resources. Draw up a complete plan of the cost to build this new system and retire the legacy system. Plan for using the best tools available to manage source code, continuous integration, and automated application deployment. Think about the learning curve for clients with the new system, and consider a staggered migration in order to minimize disruption as much as possible.
If you identify and tackle these potential problems before you start, there’s a better chance of a smooth transition that won’t upset your legacy customers.
