Foyer Insurance

Foyer Group is key player in the economic and financial landscape of Luxembourg. Leader of the local insurance market since its inception, it is now present in several European countries through its three businesses: insurance, protection, and wealth management. The decision to modernize was aligned with the company’s objectives on three main levels:

Strategic

The legacy systems hosting the Group's strategic applications were seen as a brake on development and digital transformation initiatives. Improved agility was needed in order to meet the needs of the business and ensure future competitiveness in a constantly evolving environment.

Economic

The mainframe is an expensive platform to operate and scale. Replacing it with more open and economically viable architectures can reduce infrastructure and operating costs significantly.

Risk Reduction

Skills related to mainframe technologies are increasingly scarce. The vast majority of available human resources are now oriented to "new technologies". The opportunity to automate both the migration and the testing was a key factor in choosing the Astadia solution. The competitive cost and Astadia’s proven record of successful projects also played a major role in Foyer's decision to work with Astadia.

Challenge

• Synchronize and coordinate with different parties (Foyer, Astadia, Synchrony, and Xact) to migrate the system with uniform technology
• Migrate to ISO-functionality
• Address potential obstacles in meeting the project’s timeframes due to the Covid19 pandemic.

‍

The Project

The project team opted for refactoring the mainframe COBOL and EGL based legacy to a Linux and Java based modern platform, as the best way to modernize and benefit from a good ROI and acceptable project duration. The complexity of Foyer's core business systems required a highly specialized approach. Next to Astadia’s expertise in the migration of COBOL-CICS based systems, the EGL technology know-how was provided by Synchrony (US) and Xact (Denmark).

1. Assessment and POC Phase

The assessment revealed that a significant number of diverse components of the system were interconnected. A migration method and target technology had to be determined for each of those components. The POC had to demonstrate the feasibility of the migration and integration of the most complex parts of the system.

2. Factory Certification (FC) Phase

The FC phase mainly serves to synchronize and tune all migration tools, to determine the test methods and to provide the necessary infrastructure for the initial execution and testing of the migrated components. The FC phase acceptance was reached when all components of the system could be successfully migrated with the tools. Initial smoke tests also had to show that individual programs worked correctly.

3. Factory Exit (FE) Phase

The FE phase primarily serves to ensure that all system artifacts have been migrated and that they individually function correctly. The migration of a complete production dataset was tested several times for correctness and to measure the lead time. Plans were also designed for the training of the various teams to ensure that the maintenance of the migrated system after the GO-LIVE is assured.

4. System Integration (SIT) Testing Phase

All the work from the previous phases was brought together on the infrastructure that was provided for the execution of the SIT. Comprehensive test scenarios were prepared, both for the online and for the batch processes. For the creation of the online scenarios, massive tracing was performed of mainframe activities executed by application specialists. During the SIT phase, Foyer started planning tests by the end users of the system, in consultation with the business. Several training sessions (Java, dojo, bash, linux, intelliJ, git, DB2 LUW) were organized for the technical teams and a sandbox provided to practice. UAT and production systems were installed.

5. User Acceptance Testing (UAT) Phase

During the UAT phase batch test execution continued by the technical team of Foyer using the job scheduler. The online part of the system was tested by the end users who used their own scenarios to verify whether the migrated system met all business requirements.

6. GO-LIVE Phase

The code freeze period started 6 weeks before the GO-LIVE date. Just before that, Astadia performed a final migration of the entire system followed by successful regression tests. From the start of the project until the start of the code freeze period, Foyer was able to continue its developments on the mainframe with no business interruption. The transition from the old to the new system was successfully realized during one weekend. A few weeks later, the mainframe system was shut down as foreseen in the initial plans.

Key Numbers

Key Benefits

• Creating an open infrastructure that makes interoperability easier compared to the mainframe system
• Opening the way to the cloud
• Limiting the number of technologies required for development and implementation by bundling tools
• Generalized DevOps concepts are now available to optimize the development cycle and achieve continuous industrialization of deliveries

‍

I would like to thank the many collaborators who made this colossal project successful, in IT and in the business teams. I say a special congratulation to the migration core team, which has been able to keep a cool head throughout this long project, and organize everything with precision and accuracy. Thanks to you, the Foyer Group has reached an essential milestone in the modernization of its IT architecture, essential to the achievement of our digitalization strategy. - Marc Lauer, Managing Director at Foyer

‍

Automation

As for all its migration projects, Astadia has used its standard tools in a factory set-up:

CodeTurn: To automatically transform the legacy source code (Enterprise COBOL to Java) and scripting code (JCL to Bash) to very well maintainable and 100% functionally code equivalent to the original.

DataTurn: To automatically convert the mainframe data DB2, DL2, VSAM, GDG and SAM files to DB2 LUW and Unix files.

TestMatch: To automatically capture scenarios of mainframe activity that could then be run on the target platform, comparing the results of both systems.

DataMatch: To prove functional equivalency and provide bulk comparison, which made the typical time consuming verification of the correctness of batch job results much faster.

‍

Learn more

‍Astadia's refactoring solution >

Automated migration and testing >

Watch the recording of our webinar to learn more about the project.

‍

‍

‍

‍