Updating Legacy IT Systems While Mitigating Risks: 10 Best Practices

By Chris Preimesberger

One approach to modernizing legacy applications is to install a new-gen replacement and move the entire dataset from the legacy system to the new solution in one operation—often completed over a weekend or holiday break—a process frequently called a Big Bang data migration. So on Friday business users would be using the legacy system, but when they come to the office on Monday morning, they’ll be switched to the new system. Ideally, this is a seamless exercise for the business, and employees have no problem transitioning to the new system.

Few data migrations are seamless. Import fields do not necessarily align, data can be corrupted during the transfer, and new systems may not read data the same way as the original application did. If the new system cannot be brought into production soon enough, the entire business may need to shut down as well, which is a step that could threaten the entire operation—not to mention the career of the IT executive in charge of leading the project.

To reduce this risk, a lot of companies use a parallel run-type migration strategy, which enables their old system and new system to operate in tandem. This approach may require employees to double-key the data into the legacy system, so that target and legacy environments are synchronized. With this approach, it is critical for the deployment team to reserve the time needed to perform testing, while leaving in place the option of a rollback strategy—in case the deployment runs into hiccups—to ensure that business operations can continue.

Particularly in cases where aging hardware is a problem, it is possible to lighten the load on the hardware by offloading the data to a storage device or a server, while leaving the legacy applications in place on the original hardware.

This approach is a short-term solution only, until a full migration can be completed.

By reducing the processing load on the hardware, and increasing storage capacity, the team can buy breathing room—in some cases up to two years—which allows the IT team to plan a final migration. Therefore, a phased migration approach serves primarily as a stopgap until a final modernization approach is selected.

Java’s platform-agnostic qualities have made it an attractive environment for legacy software modernization projects for more than a decade. The process begins by using compilers that work in the COBOL or Fortran environment but deliver output in Java code. Several software vendors offer this capability. Using this approach, it is possible to replace the core application component with a Java component in the same environment. Then the Java component can be installed on new-gen hardware; once it is installed, a process can be implemented to transfer data and new components to the new hardware platform, or even move the deployment to a virtualized or cloud environment.

With such a big migration comes the risk of issues associated with environments not working well and keeping data consistent while in the midst of implementation of modernization.

This approach can be completed in phases, which limits the risks from any migration issues to the latest migration phase. During this phased migration, the actual data is shared by both Java and original COBOL components, which provides an escape route to return to the old platform if necessary. This phased approach also opens the possibility of migrating data and applications first to a server or virtualized environment, and ultimately migrating to a private or public cloud.

Regardless of which option you choose, modernization projects are rarely seamless, due to the involvement of a high degree of complexity, a factor that is frequently underestimated. So be sure to be ready for anything as you migrate to a system that is essential for operations in the 21st century.