Four Challenges Holding Your Z Mainframe Cloud Migration Back

Mainframes are here to stay, but their relationship with business is changing.

It’s not just you. A lot of companies are in a tough spot with their IBM® Z mainframe cloud migration plans right now.

The issue’s not with utility. Over 70% of Fortune 500 companies still rely on mainframe technology in some form or another. Nor is it a reliability problem. Mainframes have been a staple in business for going on 70 years now precisely because they keep on trucking no matter what.

But modern systems are built with distribution in mind, and businesses are more invested— financially and procedurally— in the cloud and associated technologies than ever. Whether a company plans to fully move its mainframe workload to a cloud-based alternative or modify a new system to interface with the legacy tools it has continually used for years, achieving the desired level of interplay takes in-depth, specialized technical knowledge.

The secret is in knowing how to plan and follow through. Third-party software maintenance (TPSM) has grown in mindshare among IT stakeholders in fields like procurement and software asset management because the model helps companies keep their options open and roadmaps flexible as they navigate the challenges of migration.

Here are four common challenges that manifest in almost every mainframe cloud migration.

Mainframe Cloud Migration Challenge 1: The Skills Shortage

The mainframe skills gap we covered in late 2022 hasn’t gone away, and every retiring expert that leaves the workforce potentially creates trouble for companies seeking to carry out complex mainframe cloud migrations.

The skills companies need vary significantly from business to business or even from task to task. For example, fully replacing a COBOL- or FORTRAN-based mainframe app that has served the business for decades with a Java or C++ alternative might take a different set of skills than downscaling the same app and modifying it to feed data to a new supporting system. Even knowing which approach to follow when dozens of takes are possible can be a “legacy” skill with surprisingly high practical demand.

Challenge 2: Missing Documentation

Let’s say a ‘90s-era developer writes some code that’s of huge importance to the company employing them. The developer fails to document small oddities and technical snags, or the ways around them, like “If you turn this setting on while opening a transfer in this time zone, the whole thing might crash.” Eventually, the developer moves on to new pastures in their career, taking the little fixes that’d earned some credibility (and job security) in the workplace with them.

The story’s not just a continual source of workplace scorn (and meme humor) for developers. Stretch it out over a few decades and generations/genres of business technology and you have the foundations of a very serious problem facing pros across the IT spectrum and their employers.

In so many words, the same documentation issues that make legacy code challenging to manage week-to-week also have real potential to cause problems when you’re migrating, to the point it can feel like you’re lost before you get started.

It’s a spicy flavor of technical debt and one companies don’t do enough to guard against – you can’t know what you don’t know.

Challenge 3: Incompatible Technologies and Tech Needs

Consider this setback a combination of issues stemming from the first two. Almost no mainframe implementation is fully aligned with highly idealized megavendor standards. Or putting it another way, almost every mainframe runs a custom, old-version, or generally variable codebase, resulting in difficult-to-solve issues that run the gamut from software security to cloud migration.

For example, a company might be fine with continually upgrading to the latest version of Y mainframe software, but feature requirements might force them to retain X software (also running on the mainframe) on an older version, despite vendor or even internal pressure to move forward. Keeping data flowing between the two could further require an in-house fix, leading to the same documentation and biz-knowledge issues outlined above. No tech problem exists in a vacuum; every issue on this list comes from and spawns another.

The complexity ramps up over time in production and elsewhere, both because tech complexity scales rapidly with dependency, and knowledge of ground-level legacy operation tends to obscure as the talent base grows and evolves. And it can leave businesses to feel like newer solutions, which don’t fully suit their plans but help address pressing issues, are the only way to move forward.

Challenge 4: Disinterested Vendor Support

For megavendors like IBM, your most pressing mainframe challenges are more a question of economics. If your plans don’t involve a move to a newer, officially supported solution, or if your migration is going to cut into their bottom line, there’s a line of thinking that could essentially translate to: “Why should I extend myself to help them move away from my ecosystem, or to enable them to use older versions of my software, which make me less money?”

Thus, you might find the megavendor that was highly motivated to get you into the solution is less helpful – in terms of knowledge and overall access – when it’s finally time for a move. That can result in a lack of assistance, a lack of appropriately prompt help, or even a suggested unwanted upgrade when you assume the answer will be easier to find. And that’s never a good hill to climb during a complex mainframe cloud migration.

Sidestep Mainframe Cloud Migration Challenges with Third-Party Software Maintenance

Let’s distill the challenge. Whatever their implementation looks like, and however far along they are in developing or realizing their plans, a company undergoing a mainframe migration or transformation ultimately seeks to move away from:

• Growing complexity that makes it difficult to reconcile their past and current technology usage trends, internal or customer-facing.
• Added costs of maintaining the status quo, balanced against an infrastructure that was built to do just that. The same traits that make mainframes extremely reliable also made them difficult to futureproof against the realities of cloud infrastructure.
• Megavendor lock-in that tends to follow an upgrade the company finds unnecessary – moving to a new software version (and associated contract and price model) just to get a minor, but extremely important, feature upgrade, for instance.

TPSM has built increasing traction among the enterprise and its IT stakeholders because it does things the preexisting IT services model couldn’t, including helping them manage all three without the effort turning into an issue with the equivalent of juggling chainsaws.

Most mainframes have a tremendous amount of life left in them and value left to provide companies seeking long- or short-term mainframe cloud migration assistance.

TPSM providers also help companies determine the most cost-effective way to move forward with mainframe migration and modernization, cost being a primary driver of the enterprise’s mass move to cloud to begin with. Whether you’ve settled on a full lift-and-shift or are open to a more composable model, consulting with a TPSM can open your eyes to possibilities you might not have considered.

There is no such thing as a standard mainframe cloud migration. The variables that make the process complex are a functional requirement of the competitive strengths, operational capabilities, and customer experiences companies rely on. Achieving greater solidarity between the tech estate, current plans, and business needs is possible, but only when businesses have the tools and knowledge to understand all the possible decisions in front of them.

Don’t struggle with baked-in variables that hold Z Mainframe cloud migrations back. Reach out to Origina and start a modernization roadmap on your terms – not your mainframe vendor’s.