Saltar al contenido principal
Nube

Refactor, replace or replatform: A mainframe migration cheat sheet for business leaders

Artículo 14 nov 2024 Tiempo de lectura: min
By: Stanley Wood and Ken Gambon

Innovation often occurs at the intersection of technologies, so it’s fitting that the convergence of mainframes and cloud computing is reshaping how modern enterprises do business.

Kyndryl´s 2024 State of Mainframe Modernization Survey Report found that 96% of companies are moving at least some of their workloads (on average 36%) to the cloud. A hybrid approach allows organizations to take advantage of the performance, security and reliability of mainframes while enjoying the flexibility offered by the cloud.

But modernizing or moving mission-critical workloads to a cloud platform is challenging. Mainframe workloads have strict performance and security requirements and are often governed by stringent rules and regulations.

Even if you plan to move an entire mainframe to the cloud, the migration will likely be done in stages. Since workloads and data will be in a hybrid environment during this process, you’ll need to take extra steps to help ensure ongoing access to data, maintain security, and provide fast, low-latency connectivity.

Given these complexities, one of the most fundamental decisions your developers will have to make when migrating your mainframe is whether to refactor, replace or replatform applications. Here’s a cheat sheet with suggestions for when and why to select these popular approaches:

 

One of the most fundamental decisions when migrating your mainframe is whether to refactor, replace or replatform applications.

When to refactor

Refactoring application code is similar to renovating a kitchen. However, instead of changing out obsolete fixtures and appliances to enhance aesthetics and functionality, you restructure existing code to optimize application performance.

This approach makes sense when an application’s original code is generally well written but needs to be updated to a newer programming language. A prime example is converting COBOL to Java or .NET so an application can run natively on the public cloud or with dedicated, distributed hardware. Although the refactored application functions much like the original application, the updated code should improve overall efficiency, quality, usability and maintenance.

It’s worth noting that refactoring can take longer than other migration approaches because IT teams must fully understand the original code and business logic before converting it to a newer language. However, refactored applications are often easier to maintain than other approaches because there are more available developers with skills in modern languages and frameworks to update the software.

For example, our team is refining commercial processes to refactor applications at scale on Microsoft Azure. We use a portfolio analyzer tool to identify data dependencies and perform discovery on the overall mainframe landscape before converting the original code to modern languages like C#. To help detect and reduce errors, we run applications on both the mainframe and the cloud throughout the migration phase.

Once converted to the new language, refactored applications function like .NET containers running on Microsoft Azure. This approach enables software enhancements while keeping the existing business logic intact.

Refactoring makes sense when an application’s original code is generally well written but needs to be updated.

When to replace

Out with the old, in with the new is the premise behind the replacement approach to mainframe modernization. Also known as repurchasing, replacement entails completely discarding old applications and starting from scratch with SaaS or off-the-shelf software.

Replacing applications may be viable when older software can no longer meet your business’s current or future needs or has become too complex to support because of modifications made over time. This method eliminates the need to rework existing software and maintain custom code, making it a popular choice when developers lack the time or expertise to refactor older software. But replacement can be expensive, and IT teams must embrace new ways of working when deploying and learning to use the technology.

When Kyndryl established itself as a standalone company in November 2021, our CIO office replaced existing systems with standardized applications and business platforms whenever possible. The goal was to help reduce IT complexity, prevent unwanted technical debt, and lower the total cost of ownership. 

Over two years, we downsized our application portfolio from more than 1,800 business applications to fewer than 360. Ultimately, this technology transformation will play a significant role in lowering Kyndryl’s selling, general and administrative expenses (SG&A) by US$200 to $300 million.

Replacement is a popular choice when developers lack the time or expertise to refactor older software.

When to replatform

If you’ve ever relocated a business, you can appreciate the process of replatforming mainframe applications. Often called “lift and shift” or “move and improve,” replatforming involves modifying older software to work in the cloud without rewriting its core architecture or drastically altering its functionality. 

Replatforming is often the fastest and easiest way to move applications because it requires minimal changes to the underlying architecture and data. Although this approach reduces overall risk, long-term maintenance costs may be higher than replacing or refactoring an application.

We’re currently helping a global communications provider rein in infrastructure costs and derive richer insights from its data by moving critical mainframe applications and data to Microsoft Azure. The cloud-based applications will connect to the customer’s service management platform and support its AIOps self-healing IT estate model. Software that remains on the mainframe will integrate with data from a more comprehensive set of systems for analytics.

By 2026, we project replatforming will reduce the organization’s mainframe operating costs and energy consumption by 70%, leading to savings worth more than US$22 million annually. The ​modernization should also create more seamless customer experiences by streamlining access to data and capabilities with the remaining mainframe applications.​

You’ll need to weigh the pros and cons of each modernization method to determine which approach aligns best with your overall business objectives.
Moving forward with modernization

Regardless of how you approach modernizing mainframe applications, the overarching goal should be to put the right workload on the right platform. By aligning your technology strategy and budget with your company’s long-term business objectives, you can choose a path that optimizes performance and efficiency now and in the future.

Stanley Wood is a Distinguished Engineer and Vice President of Kyndryl’s Microsoft Alliance.
Ken Gambon is a Director and Principal of Global Engineering in Kyndryl’s Applications, Data and AI practice.