Opinion How to Migrate 4,000 Programs Without the Business Really Noticing

As the weather gets warm, our roads and highways get their makeovers and repairs. Sometimes, entire swaths of highways are replaced. If you're driving through such a stretch on a regular basis, you will notice that highway departments do their best to keep the highway open and traffic flowing. While one lane is resurfaced, traffic is funneled down a different lane. The next week, you may be directed still along another lane.

The same holds true with systems migrations. All efforts are made to keep the business operating normally, but users still know something is up. Whether they are lift-and-shifts, incremental or simply side-by-side rollouts, migrations are often multiyear projects involving many parts of the business and requiring major systems implementations along with retirements.

That's why a case study, published a couple years back by Blue Phoenix Solutions, still stands out as a roadmap of how to get a migration right. The story documents a four-year effort at Canadian P&C insurer Desjardins General Insurance Group (DGIG) migrate its MVS/IDMS mainframe platform to a distributed Windows/Oracle platform. This project took four years to complete and, according to DGIG, at the time stood “as the largest successful modernization project done in both North America and in the history of the insurance vertical.” The best practices established from the project are published here at INN, and what follows is a description of the steps taken to achieve project success.

The project produced some very compelling numbers for DGIG, Blue Phoenix reports. The migration involved moving more than 2.6 billion records, 237,000 files and 4,330 COBOL programs. Small wonder it took four years to complete. There was also a hard-and-fast deadline — “DGIG had to migrate by a specific date to avoid substantial costs from extending its outsourcing contract.”

The migration also included two implementations that had to be conducted within the same fiscal year. The outcomes were impressive: annual operating costs were reduced by $4.5 million, and the performance of transaction processing went up by up to 50 percent.

Here are five keys to DGIG’s success:

Select dedicated migration and integration teams: In DGIG's case, their own teams oversaw the project, but they also had other outside partners who assisted. The insurer's preference was to work with companies that already understood the business through long-term working relationships.
Collect and analyze inventory: Map out the systems that will be impacted, exactly when they will be impacted and who will be affected. “The DGIG team instituted a  'bridge analysis' system, developing specific programs to facilitate data sharing between legacy and target systems. This was a cross-functional IT effort across DGIG and enabled systems to be migrated with minimal to zero impact on end users and production systems. It provided additional visibility into how the legacy systems worked together and the expectations end users had for their performance and functionality.”
Convert applications and data: DGIG had already invested heavily in C# applications, which served as the presentation layer applications. The migration team chose to convert the mainframe-based IDMS DML commands to embedded SQL “to retain the logic of the legacy state in the new relational database.” To maintain data query performance, the team developed an automated solution that ran behind the scenes.
Test converted applications: Application testing was challenging, due to the fact that it could not be performed offsite due to DGIG’s security policies, ongoing change requests and the need to test against several integrated systems that were still under development. As a result, the project required high-quality translated code and “well evolved, relevant test scripts and problem descriptions.” By having high code quality, the team was able to reduce manual fixes and rework. Probably the most important strategy to accomplish the testing process was engaging the business users, the report adds. The testing teams were able to get a holistic view of application performance, as well as collect anomalies.
Deliver converted code: Akin to laying new roadbed for new highway lanes while keeping traffic flowing, the process needed to take place without disrupting ongoing business. The case study observes that “Desjardins code was not frozen during delivery, so even during migration, code was changing and testing and delivery needed to adjust accordingly.” The solution was to migrate, test and deliver translated code into 'work packets,' each of which was “broken down into subsystems representing different parts of the business- and were delivered according to the impact the converted code had on that business unit.” It's notable that the project didn't just consist of one code migration from the old to new systems, but rather, up to five times code was moved back and forth between systems.

Joe McKendrick is an author, consultant, blogger and frequent INN contributor specializing in information technology.

Readers are encouraged to respond to Joe using the “Add Your Comments” box below. He can also be reached at joe@mckendrickresearch.com.

This blog was exclusively written for Insurance Networking News. It may not be reposted or reused without permission from Insurance Networking News.

The opinions of bloggers on www.insurancenetworking.com do not necessarily reflect those of Insurance Networking News.