Two IT professionals monitor a futuristic data migration from on-site servers to cloud systems.
Sompo Japan, one of Japan's best-known non-life insurers, has moved a mission-critical mainframe system onto Microsoft Azure. The move used TmaxSoft's OpenFrame7 rehosting software. TmaxSoft said on Oct. 13 that its Japan unit completed the project, and that systems previously running on an existing mainframe were migrated to a Microsoft Azure cloud environment. The announcement is a useful case study in what a large, regulated shop actually does when it wants off the mainframe without rewriting everything.

Two IT professionals monitor a futuristic data migration from on-site servers to cloud systems. What was announced, and when​

The Oct. 13 date is the date of the Korean press report, not the production cutover. A Japanese-language release distributed by Japan TmaxSoft on Sept. 25, 2026 carries the project timeline. It says the project began in September 2021 and went into production in June 2025, after roughly 45 months of development. The system had been running on the mainframe, and was moved to Azure.

The release describes the migrated system as holding a large legacy estate centered on COBOL, JCL and assembler. TmaxSoft's Japan representative calls it a runoff system. That is TmaxSoft's own wording, and the release does not explain it further.

Why rehosting, and not a rewrite​

The release says Sompo Japan weighed several options and chose rehosting over rebuilding or rewriting. TmaxSoft describes the reasoning this way:

  • Long-lived services. An insurer's systems must run stably for years to serve policyholders.
  • Cost rigidity. Mainframe operating costs are hard to trim as system scale shrinks.
  • Ongoing spend. Hardware and software maintenance and renewal require continuous investment.

According to the release, the deciding factor for OpenFrame7 was compatibility with the existing program assets, assembler in particular. That let the insurer keep application changes to a minimum. The stated project policy was to preserve current behavior and keep operations stable after release.

Rehosting here does not mean the applications became cloud-native or were redesigned. The company says assets were reused with minimal modification. It does not describe a rewrite or a move to microservices.

What the Azure side typically looks like​

Neither source discloses Sompo Japan's actual Azure architecture. Microsoft's general documentation shows how OpenFrame deployments usually work:

  • Microsoft's Azure documentation calls OpenFrame a popular rehosting solution for lift-and-shift scenarios. It says an OpenFrame environment on Azure suits development, testing, demos or production workloads.
  • A Microsoft reference architecture uses two Linux virtual machines in an active-active configuration. An Azure Load Balancer spreads traffic across them. OpenFrame emulation software on the VMs provides a zSeries runtime and facilities, alongside an Azure SQL Database.
  • In TmaxSoft's own white paper, OpenFrame online services replace mainframe middleware such as CICS, and OpenFrame Batch with its TJES component replaces the mainframe's Job Entry Subsystem.

That is generic product architecture. It should not be read as a description of this particular deployment.

What is not disclosed​

The public material leaves out most of what an infrastructure team would want to know. It gives no:

  • original mainframe vendor or model;
  • Azure regions, services, database choice or network design;
  • security, identity or disaster-recovery design;
  • code volume, transaction volume or number of applications;
  • testing approach or migration waves;
  • performance, availability or cost figures.

Sompo Japan's quoted comment says it put stable service first and made maximum use of existing assets. It also says mainframe maintenance costs were reduced, and that the savings will go toward digital services and digital transformation. No amount is given, and there is no independent verification.

The sources also do not say Sompo Japan has left the mainframe entirely. They establish the migration of the reported system, not an insurer-wide exit.

What readers can take from it​

Rehosting is not necessarily fast. The reported span is about 45 months from start to production. The release does not say how much of that was pure migration work. It is the stated elapsed time for this project, not a benchmark for OpenFrame in general.

Assembler compatibility mattered. Assembler is often the hardest piece of a mainframe estate to move. Sompo Japan cited it as a decisive factor. Teams evaluating tools should check this early.

The evidence is vendor-sourced. The claims about compatibility, cost reduction and success come from a vendor release and a customer comment carried within it. They are attributed assertions rather than measured results. A fair reading is that a large insurer reports completing a long, careful lift-and-shift to Azure. The cost and reliability outcomes are unproven in public.

The business angle​

TmaxSoft CEO Hyung-yong Lee said the company will position its Japan unit as a base for expanding into Asian markets. The company says it has built its Japanese digital-transformation position around OpenFrame since establishing the unit in 2000. Those are corporate ambitions, not technical details of the Sompo Japan project.

For Azure, this is one more reference point in mainframe migration, a segment where cloud vendors compete for long-running enterprise workloads. For IT administrators with COBOL and JCL estates, the practical lesson is to budget realistically for a multi-year program. They should also ask any vendor for measured results rather than only completion announcements.

 

References

  1. TmaxSoft completes Sompo Japan mainframe rehosting with OpenFrame, migrates to Azure - 디지털투데이 디지털투데이 2026-10-13T01:59:14+00:00
  2. Migrate IBM mainframe applications to Azure with TmaxSoft OpenFrame techcommunity.microsoft.com
  3. TmaxSoft tmaxsoft.com