by William Méndez, Project Manager at Growth Acceleration Partners
One of the reasons I joined Mobilize back in 2017 was this crazy, wonderful, and out-of-the-box idea that there was a tool that could convert a desktop application into a web one in less than a day. For me, it sounded like magic coming out directly from a Harry Potter book in which, by just casting a spell, you would have the power to transform thousands (even millions) of code lines in front of your eyes.
What is the recipe? How can an engineering team achieve a web application that behaves almost equivalent to a desktop one , using a new architecture, and keeping the same business rules?
Five years later, and after executing multiple modernization projects from and to different technologies, I can share my testimony about the power and benefits of the Mobilize Modernization Tools. However, they are not enough without a plan and process in place.
This is what we defined as the “Golden Rules for a Successful Code Modernization”, and I would like to share the basic principles that any team starting a modernization journey should know since the first day.
Rule #1: Every team member has a role
The modernization of a legacy application is not a single resource effort endeavor. It requires a group of people with different knowledge and skills, including four roles.
- Migration Engineer: accountable for all the development activities related to the legacy code, with expertise in the source and target technologies. Their knowledge of the legacy application’s business rules is an important plus.
- Product Engineer: accountable for the modernization tools, and the implementation of generic solutions that can be used for generic code patterns.
- Quality Assurance Lead: accountable for the creation of test cases and the execution of ad-hoc testing to ensure the quality of the Modernized application. They require a strong knowledge of the Legacy application’s behavior.
- Subject Manager Expert (SME): client’s end user with knowledge of the legacy application and how it is used in a “production” environment. Their availability, once the application is approved by the Quality Assurance Lead, is crucial to achieve a modernized application that is stable and within the expected time-to-market.
The definition and discipline related to these roles will be helpful to maintain clear communication and prepare everyone to manage expectations and uncertainty during the modernization process.
Rule #2: The testing plan is your map
One of the main purposes of a modernization project is that the end-user can have an equal or better user experience (if you compare it to the legacy application). The modernization process must be transparent, so any understanding, interaction, and automation (especially if it’s a data-entry application) remain intact and the adaption effort almost insignificant.
How do we include the user experience as a metric in the success criteria of a modernization project? By defining test cases that describe the current behavior the user is having in the legacy application.
It is almost impossible and very expensive to cover 100% of the legacy functionality, but doing a good job on this definition (~70%) will increase your chances of success.
Rule #3: Use the legacy code to guide you in the journey
The business rules of the legacy application were created years ago. Possibly, few people remember why they were defined as they are in the code. It’s also very possible that you don’t have access to updated and trustable documentation (if it exists), explaining why someone made the decision that directly impacts the behavior of the application.
How do we deal with this level of uncertainty and unknowledge? By using the test cases (Rule #2) and by respecting the purpose of the source code from the legacy application.
Years ago, the business logic of the legacy application was created for one reason. Why do you want to take a risk implementing a different solution to a problem that was already solved on the legacy application? Trust the work done by the engineers that already developed and kept the legacy application alive and relevant. The best guide is in front of your eyes: the legacy code.
Rule #4: Use the Mobilize Modernization tool to accelerate your progress
When the modernization project starts, one of the first activities assigned to the Migration Team is the use of the latest version of the Mobilize Modernization tools to convert the source code to the target platform. The modernized code that comes out of the Mobilize Modernization tools is named “green code.”
Once the green code is generated, all the occurrences of the same code pattern will be solved across all the code of the modernized application using the same solution that was implemented on the Mobilize Modernization tool.
After this, the Migration Team will review the generated code and execute three specific actions:
- Identify additional enhancements and places where the code automation can be increased (based on the discoveries or recommendations from the Application Assessment Report).
- Merge the changes against the code baseline of the modernized application. (If it’s the first version, this will be your code baseline.)
- Identify migration issues with few code occurrences that can be solved by introducing manual changes, using “horizontal development” techniques. The concept of this technique is that the Migration team must apply any code fix to all the files and projects related to those properties, methods, events, and code patterns. In simple words, each fix applied by the Migration Team to a control, form, screen, or test case must be horizontal (searching for the same scenarios across all the code and applying the same fix).
Thus the “Cycle of Code Improvements” is a cyclic process that can be repeated as many times as required, and it’s the key element to accelerate the project modernization timeline.
Rule #5: Define a strategy for the “code freeze” period
As any software product has a life cycle, the product manager of the legacy application will be in charge of fixing minor bugs or including new features. These improvements to keep the legacy application updated for the end-users would be applied to the production environment in release cycles of one, three, or even six months.
Because of this, during the execution of a modernization project, there will be a moment in which the product manager will have to define a “code freeze” period. During this timeframe, there will not be any further modifications from any developer in the legacy application’s code.
If there’s a legacy code release available once the modernization project started, the Migration team can repeat the “cycle of code improvements” all over again using a newer version of the Mobilize Product Tool (which will include new fixes or solutions to issues identified on early stages of the project) and merging those changes in the modernized application’s code.
After the start date of the code freeze period, the legacy code application should not be changed by the developers.
Rule #6: Identify and document known differences
Sometimes, there are specific behavior differences between the legacy and the modernized applications that can’t be reworked to be 100% equivalent for the end-user. The cause of this is that no property, method, or event in the target platform can reproduce the same behavior of a specific control.
We call this concept a “known difference,” and both teams (Migration and Quality Assurance) are responsible for the identification and documentation of these differences.
Are These Rules Enough to Succeed in a Modernization Project?
The definition of these rules was intended for any person who is as intrigued as I was when I decided to join Mobilize. No matter if you work for a small or big company, the principles are never under question.
It doesn’t matter if you want to join the company, buy a modernization tool license, or execute a project with Growth Acceleration Partners. I strongly believe that this guide may clarify many questions that you may have before starting a modernization journey.
This is a custom development process that only makes sense in modernization projects and it requires many of the best industry practices to succeed.
Do you want to learn more? Don’t hesitate to reach out to us if you have further questions.
