2The Traditional Big Bang Data Migration Strategy
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.
3Mitigation Risk for Big Bang Data Migration Strategy
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.
4Mitigating the Big Bang Data Migration Risk
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.
5The Iterative or Phased Hardware Migration
6Migration Risk for Iterative or Phased Hardware Migration
7Mitigating the Risk for Iterative or Phased Hardware Migration
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.
8Using a New, Platform-Agnostic Environment: Java
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.
9Migration Risk for Java’s Platform-Agnostic Environment
10Mitigating the Risk for Java’s Platform-Agnostic Environment
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.
11Key Takeaways From This Presentation
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.