Allianz ditches mainframe for scale and innovation

Due to a risk of not being able to scale and innovate properly, nor provide a basis to accommodate new platforms or programming languages, a decision was made in mid-2019 to migrate the entire Allianz Business System (ABS) — the IT core applications including its database in Germany — to standardized x86 servers with Linux operating systems. The project, called ABS Goes Linux, was a first in the insurance industry.

With such a move, connecting cloud-native applications and developing them in an agile way would be seamless, and IT would be less dependent on suppliers and more technically enabled.

“We haven’t been on the mainframe since Easter 2022,” says Axel Schell, CTO of Allianz Technology, which provides IT services worldwide for the Allianz Group. “That was one of the riskiest and most difficult projects of my career.” 

Real-time data on database availability, for instance, and application stability and processed insurance claims are stored on the new infrastructure. At the same time, everything is displayed on a dashboard. “This is how transparency works today,” says Schell. “Everyone is always up to date and that speeds up the organization.”

In addition, the setup ensures trust among internal customers, adds Sebastian Pongratz, senior executive in Schell’s team and responsible for the implementation of the project. “Every user in the business areas, not just IT, can access the dashboard and see it’s working. With the mainframe, we could benefit from innovation cycles of the manufacturers, but we were also dependent on them,” he adds, pointing out one reason to make the move to Linux.

Core applications previously on the mainframe

ABS includes all core business applications of the German group companies as well as all the region’s holdings. “It’s the central customer platform, in which more than 30 million contracts are managed,” says Pongratz. “It’s the core of the German IT ecosystem. This includes all interfaces to processing as well as to customer and sales portals.”

If ABS didn’t work, sales, brokers, back office, and web services wouldn’t work either. This applies to all lines of business with health, property and life insurance.

As planning went along, Pongratz and his team explored options to migrate the system to the new platform in slices. But the centerpiece, one of the largest Linux-based DB2 databases available, could only be migrated as a whole. In order to prepare for such a procedure, Allianz Technology chose an iterative approach.

They knew the target KPIs of the new environment, and that the performance and automated processes of the mainframe should also be available under Linux. “We also had a volume issue,” says Pongratz. “Everything had to work as before. And at the same time, there had to be room for growth in the coming years.”

The team defined various requirement clusters like target architecture, requirements for the products used, operational KPIs for performance, throughput and automation quotas, and underlying security standards.

“Based on this, we went through various iterations in order to gradually increase the level of maturity and worked together with providers to adapt their products to our requirements,” says Pongratz. The several petabytes-large database offered mid-five-digit processing power in MIPS (millions of instructions per second) on the mainframe. So far nothing like this has been translated to DB2 under Linux.

Gradual migration of legacy applications

In the first phase, it was necessary to convince stakeholders of the project’s benefits for the business. From there, the IT department made the first steps in the new environment. “We tried how we can get basic ABS parts to run under Linux and how they behave under load,” says Pongratz. It started with applications and continued with the integration of the database through to specific components such as the large batch for the monthly renewal.

Then followed an initial validation, asking questions such as are desired KPIs considered, can operations be simulated for test runs before go-live, are the capacities and throughput speeds of the procured server and storage systems sufficient. The answer was no.

Setbacks and adjustments

About 14 months before the cut-over, Pongratz realized the infrastructure that was set up and ordered didn’t support the target system, so the environment had to be adjusted.

IT switched to a more powerful infrastructure and revised the entire storage concept. “We worked closely with external providers and their labs, and sent them feature requests, not only for functions, but also for situations during operation,” he says. For example, in the event of problems, it should be possible to shut down and restart several thousand processes in the database cache in less than 10 minutes without the user noticing anything.

Security products in the client-server environment also reached their limits. The process volumes to be protected were 10 times higher than what the solutions were originally built for. “We had to convince the providers to get involved and adapt their software to our environment,” says Schell. “They can now also offer such features to other customers for a similar size. We did the pioneering work together with them.”

The mainframe as a benchmark

The benchmark for such KPIs was set by mainframe. “The fact that the new environment delivers similar performance to the old one is crucial for internal customer buy-in,” says Schell. The new features were tested, adjusted and expanded in several iterations.

The IT team also checked the scalability of the new platform. “We have to be able to migrate more portfolios and win new customers,” adds Schell. “So we also tested whether additional volumes could be processed.” Using growth simulations IT tested whether the system would remain functional even with major release changes or upcoming migrations.

“For example, we measured the utilization of the online channels, used the times with the most access as a benchmark, and checked whether the new system also worked reliably with a thousand additional simulated clerks,” says Pongratz.

Batch processes were also checked in this way, for example, in regard to peak loads in seasonal business. The KPIs for this were the DB2 accesses per second, which were simulated in the Linux database, and measurements were taken every day of the month to cover all scenarios.

In parallel, the target operating model of the new environment was introduced. Allianz IT set up teams of experts in Germany, India, and Hungary to operate the new ABS.

The hot phase

Around four months before the scheduled date for the migration, the team stopped further development of the products. The versions developed to date were prepared for the changeover and only adjusted with individual fixes. On this basis, the continuous operation simulation started in the last few weeks before the deadline.

In this phase, for example, the concept for database reorganization, including backups during the nightly rest periods, was revised. “It didn’t go as quickly as planned,” Pongratz says. “So we had to adjust it eight weeks before going live.”

The migration itself was deliberately scheduled for the Easter weekend of 2022. The entire inventory from the mainframe had to be converted, technically checked, cleaned up, and migrated to Linux. “We had four days to solve any problems,” he says. “In the end, it took 48 hours to transfer the complete data set.” 

In order to be prepared for problems, logistics and communication also had to be prepared. “For the absolute worst-case scenario, where all of our pre-implemented safeguards fail, we prepared to roll back to the old system,” says Pongratz. Schell adds: “We had 1,000 employees in use to test in all areas, including agencies and brokers.” In addition, the German banking supervisory authority Bafin was informed.

Effort and ROI

The core project team consisted of around 500 employees while around 3,000 people worked at times in various phases, and the budget was a low, three-figure million euro amount. Bearing that in mind, the project plan is for it to pay for itself after three to four years. “We’ve been running the platform for a year now and can see exactly how it compares to the mainframe costs,” says Schell. “We save a double-digit million amount in operation.”

According to the CTO, trust in business was achieved by measuring all relevant transactions of a user from a department before and after. “In the test before going live, we showed that the new processes are high-performing in the desired areas,” says Schell. And after a short time, every transaction on the new platform was demonstrably faster than it has been on the mainframe.

According to Pongratz, the modern architecture and access to the latest tools drive the innovative power of the company. Resources can now be used more dynamically and allocated more easily. And developers no longer have to wait for batch jobs.

The project also contributes to the overarching IT strategy as Schell wants to consolidate applications outside of ABS and switch off legacy systems. “It’s the preliminary stage for cloudification of the environment,” he says. “We’ve achieved very stable operations and are now considering whether and how we will migrate them to the cloud.” But the common cloud hyperscalers would first have to develop suitable solutions that map the performance requirements of the system.

Assessing the challenges

Besides the technical aspect, managing the human element was also a big challenge. In the mainframe world, Allianz had built up a lot of application know-how that would remain essential for the new target platform, so this knowledge had to be preserved.

The existing team was supplemented by experts, and colleagues from the “old world” received further training in order to take them and their expertise along into the Linux environment. But there was fear among employees who had worked on the mainframe for decades. 

“Change management was a big topic,” says Schell. “If you don’t manage it well, it can torpedo a project.”  

Therefore, the workforce was involved in the project early on. “We managed to get the whole organization committed to one goal and make it clear that every person will be important for the new world,” says Pongratz. The colleagues were trained in courses or together with internal and external experts.

In the project phases, there was also a bit of a crunch. “You have to be careful not to copy the mainframe on Linux,” Pongratz says. Certain mechanisms would have to be transferred to the new world, but they worked differently there. It was therefore important, for example in quality assurance, to check whether the applications were built Linux-native with a view to the cloud and not according to legacy principles.

In addition, executives such as department and team leaders were made responsible for sub-projects. And in totality, the project affected everyone at Allianz in Germany because everyone works with ABS, which is a system with 300 interfaces. “They worked according to the motto, ‘You build it, you run it,’” says Pongratz. “It’s in your own interest to take your employees with you.”