91快活林

When modernizing legacy systems and moving to the cloud, many companies consider automated tools that quickly convert legacy applications to a modern technology that can be deployed into the cloud (For example: from COBOL to JAVA or .NET).聽

The automated approach can speed up the migration effort significantly鈥攂ut experience has shown that it can create problems of its own. Companies often find that their automatically migrated applications are very difficult to maintain and manage.

The good news is that there is a solution. The answer lies not in more technology, but rather in enhancing the migration process with a new methodology鈥攐ne that helps ensure that the team managing the target application has the knowledge they need to work efficiently and effectively.

The challenges of automated migrations

When a migration is performed with an automated tool in an idiomatic conversion, the process typically results in a converted application that is hard to maintain for two fundamental reasons.

The first of these is 鈥渃ode bloat.鈥� With automated tools, one line of COBOL code can produce an equal number or more lines of JAVA code in the new application. With legacy system applications often having millions of lines of code, this ballooning code can make the new application more complicated to maintain due to its sheer size.

The second and perhaps more troubling problem is that the automated process creates an application that no one truly understands. Unlike manually analyzed and written code, it essentially performs a line-by-line transcoding of the legacy application. Thus, automatically generated JAVA or .NET code will imitate the legacy system and behave like COBOL code. As a result, neither the full-stack JAVA or .NET programmers managing the target application or the subject matter experts who managed the legacy application will fully understand the new system. The organization will thus struggle to perform activities such as enhancing the system or fixing defects. This typically means more time and cost in the operation of the application.

Overall, the ongoing maintenance challenges with the new application stem from a fundamental gap in the automated migration process. Typically, this process is rigorous, encompassing analysis, planning, mass migration, validation, and parallel production. But it fails to address a key factor鈥攖he knowledge about the legacy system accumulated over time. This knowledge includes the way the system was coded, what it does, and the process and workflow problems that have been addressed. Such knowledge provides invaluable context for maintaining the new system鈥攂ut it is typically 鈥渓eft behind鈥� and lost in current automated migration efforts.

Filling in the missing link

The solution, of course, is to make sure knowledge is captured and made available to the teams that oversee the new application. Indeed, this is critical, and it cannot be an afterthought or add-on effort. Knowledge migration needs to be built into the automated migration process from the beginning, and regarded as an integral part of the effort, along with language and database migration. This methodology includes several key steps that run throughout the migration journey.聽

• Trans-documentation. As the first step in the process, the migration team should start documenting the functionality, business rules, and business logic of the legacy system for use with the target application.
• Re-orientation. This involves upskilling and cross-skilling, which can be accomplished by training some legacy (COBOL) programmers in the new target system language (such as JAVA or .NET) and then embedding them in the target support team. The purpose is not to turn them into JAVA or .NET experts, but rather to enable them to more effectively work with the target-system team to transfer business knowledge.聽
• Naturalization. The target-system support team should perform a walk-through of the new auto-generated code. This will help them understand how the tool has written code differently than the way they would have done if developing the application from scratch. This will help increase their familiarity with the new code and deepen their understanding of how it works to execute business logic.
• Simulation. This entails identifying frequently occurring support instances that took place in the legacy system and simulating them in the target system. This gives the target support team an opportunity to practice solving those problems in the new environment.聽
• Preparation. The Known Error Database, which captures information about problems the system has experienced, root cause analyses, and the fixes developers have come up with over the years, should be brought forward into the target system environment to avoid the need to reinvent the wheel in solving problems. In addition, the IT Service Management process for the target system should be created by the team that maintained the legacy system, helping to bridge process gaps.聽

Adding these knowledge-migration steps to the modernization process will undoubtedly add a modest amount of time to the overall project. But in the long run, it will help eliminate significant maintenance costs鈥攁nd pay off in reduced risk, greater efficiency, and an improved ability to have systems keep pace with the demands of the business.聽聽

In our work with modernization efforts, 91快活林 has found that today鈥檚 automated migration solutions, such as Google鈥檚 G4 mainframe code conversion software, can be powerful tools. Like any tool, however, their effectiveness depends on how they鈥檙e used. With our long experience in IT modernization across a variety of technologies, and our proven methodologies, 91快活林 can help companies leverage these tools while preserving critical knowledge. By taking the right approach, companies can make the most of their migrations to take their applications鈥攁nd the business鈥攚here they need to go.