On time and on budget — it doesn't happen often, especially when it comes to replacing legacy systems. Desjardins General Insurance Group, a Canadian property/casualty insurer with a portfolio of more than 2 million active policies, $2 billion in revenues and $4.3 billion in assets, did just this. In 2006, with a number of objectives in mind, the firm began its four-year journey to completely migrate its systems from a multiple virtual-storage/integrated database management system platform to a new Windows/Oracle platform.
This project was big. And its main objectives were plenty. Desjardins General Insurance Group (DGIG) sought to migrate to a platform that could promote the convergence of distribution channels and enable performance and scalability improvement over legacy systems. It wanted to eliminate obsolescence risk associated with legacy multi virtual storage (MVS)/integrated database management system (IDMS), reduce cost, and improve scalability for supporting increasing volumes of business. With a new efficient, cost-effective infrastructure, DGIG foresaw advantages in terms of staffing and recruitment, making it easier to find skills and people to support newer technologies.
The insurer set a project budget of $45 million, "a hard number with no upward flexibility," says Serge Grenier, principal director of IT and VP of insurance technologies at DGIG. Establishing an accurate inventory of the legacy system was critical for establishing scope. However, legacy artifacts were spread over several departments and applications - many of which had never been properly documented, Grenier says.
This isn't a project to rush; 2006 and 2007 were defining years. "The beginning of the project was to improve all of the diversities that we need to do the conversion of the program - the conversion of the streams, reports, database, files, etc.," Grenier says. The insurer worked with Blue Phoenix to define the project work, and then to realize that project, "because we do this type of project only once in a life maybe," Grenier says. In fact, this was the largest project ever taken on by Blue Phoenix, which does business in a number of industries and with large customers, such as Walmart, Citigroup and Ford.
BIG BANG?
"Blue Phoenix told us that it's better to do a big bang implementation - all of the systems, all together at the same time," Grenier says. "We thought that was too risky. So at that moment we decided to do it in two phases, but we kept in mind that we had four years to do the project." At the time CGI was managing DGIG's mainframe environment. The contract was set to expire at the end of 2010. "We didn't want to renew it, because it was costly."
DGIG spent the first two years of the project researching and improving software that was not mature and recapitalizing the solution with all its suppliers, such as Microsoft and Oracle, Grenier says. "We were very concerned about the more than 3,000 people that are using those systems every day, in the call center in contact with the clients. So it's very important that the format is there, the servers are available, things like that.
"In the middle of the project in 2008, we had a lot of problems with the bridges," Grenier says. "Because we had a lot of bridges, we had a lot of links between systems. They are all integrated together. So it was very complex to ensure the performance and synchronize the data. So we decided at that moment to do only one implementation, as Blue Phoenix advised us to do two years before."
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.
For Blue Phoenix, it provided additional visibility into how the legacy systems worked together and the expectations end users had for their performance and functionality.
DGIG converted the IDMS DML commands to embedded SQL to retain the logic of the legacy state in the new relational database. High-quality code eliminated manual fixes and rework, kept the project on schedule and enabled WAZ Informatique, a consulting services company, to properly test across more than 30 integrated systems that leveraged the converted code.
Migration, testing and delivery of translated code was divided into Work Packets. Each packet was broken down into subsystems representing different parts of the business and delivered according to the impact the converted code had on that business unit.
By the end of the project, DGIG had migrated five full-scale code refreshes to support changes requested, more than 2.6 billion records, 237,000 files, 14,000 fields and 4,330 COBOL programs. Many of the COBOL programs were not migrated just once but two to five times, accommodating all the changes DGIG made in the original mainframe system while we were migrating the system, according to Pratik Dalal, Blue Phoenix project manager.
Now, it's easier to integrate new software, which was a goal of the project, Grenier says. Another goal was to decrease operational costs. "For sure, it's millions per year that we are saving."
7 LESSONS LEARNED
From their experience with a large migration project, DGIG and Blue Phoenix identified some best practices:
1. The management approach relied on the accountability of IT resources and the involvement of managers and upper management, which ensured the mobilization of resources throughout the project.
2. DGIG mobilized stakeholders during the entire project by setting up interactive communications - management committees, newsletters, master plans - as well as during the transition period.
3. Extensive resources and timelines were applied to assess the project's impact across the business. Legacy artifacts and logic were measured for relevance to future business goals and requirements.
4. While an extensive proof of translation and proof of concept were required to validate vendor technology, the process also identified aspects of the project that would require internal DGIG resources.
5. To prevent change requests during the late stages of the modernization initiative from delaying or derailing the project, a three-month freeze was imposed on business project deliveries during the migration implementation period.
6. Cross-departmental representation was essential in developing test cases/scenarios for integration and system testing. Testing was started early and involved end users.
7. A core tenet of the project was a seamless migration experience for users. Requirements went beyond duplicating legacy functionality and business logic; the target system had to meet or exceed performance benchmarks of the multi-virtual storage environment.
