The Great Modernization Challenge

CloudFrame’s CEO Venkat Pillay has spent years navigating the complexities of enterprise modernization, working closely with organizations that have struggled with failed transformation efforts. As a leader in the field, he has witnessed firsthand the skepticism that stems from repeated disappointments in modernization approaches. Drawing on his experience, he sheds light on the real challenges businesses face—not just in technology, but in overcoming cultural and operational resistance to change.

Scepticism in the Market

While mainframe modernization as a general concept is almost as old as the mainframe itself, more modern Java-based modernization strategies have been around for almost thirty years. That’s about half as long as the mainframe. In that time, every major corporation has been pitched a variety of modernization solutions that came with big promises but ultimately failed to deliver. Sometimes, that failure was spectacular. I remember one particular bank suffered a catastrophic failure of their modernization efforts which cost them millions to recover from. ?

As a consequence of numerous grandiose claims blowing up in people’s faces, skepticism is deeply rooted, and understandably so. Organizations have learned the hard way that most approaches simply don’t work for them.

The Micro Focus Approach

When Micro Focus came on the scene in the mid-80s with their CIS COBOL (a version of the language that could run on microcomputers), they introduced one of the first partially successful modernization strategies by allowing companies to translate their existing applications to CIS COBOL, which they could then shift off of the mainframe and reduce MIPs consumption and consequently operating costs.

While successful on the hardware cost savings front, this solution could never truly replace the mainframe. CIS COBOL applications were only as reliable as the machines and operating systems they ran on, which at the time wasn’t saying very much. So the mainframe remained, because it worked, and because it was reliable. The Micro Focus modernization approach gained some traction, but was never hugely successful.

?

The ‘JOBOL’ Experiment

The earliest attempts at COBOL to Java conversion were based on the use of a shim layer and resulted in Java that looked and operated like COBOL. This meant that the code retained COBOL’s procedural characteristics and did not use object-oriented principles. Due to many high-profile failures, the derisive term “JOBOL” followed soon after.

These JOBOL conversions did work on a limited scale, but maintainability just wasn’t possible. JOBOL is essentially unmaintainable, as only the vendor who provided the solution can ever change. Worst of all, JOBOL conversions left clients reliant on proprietary runtime libraries licensed by the software company that handled their “modernization.” This type of vendor lock-in is something very few organizations want to deal with. Surprisingly some software companies continue to offer JOBOL conversion as a modernization solution. ?

?

Vendor Lock-in: A Dealbreaker

JOBOL peddlers aren’t the only ones that come packaged with vendor lock-in. A surprisingly high percentage of modernization providers lock in their clients, either intentionally or due to poor quality software. Many companies have been burned by vendor lock-in before, and they’re not willing to go down that road again. Lock-in usually results from either a “lift and shift” approach, which comes with its own set of problems, or a poorly implemented conversion methodology. A true conversion of COBOL to Java should not rely on third party run-time software . If it does, then it’s not a true conversion, and as such, it will be difficult if not impossible to maintain—just like JOBOL, but without the catchy name. Companies that tried to implement this approach quickly realized that their so-called "modernized" system was just as rigid and outdated as the original.

?

The “Lift and Shift” Dilemma

Many have tried the "lift and shift" approach—what Gartner calls "rehosting." This is a migration strategy where applications and workloads are moved from a legacy mainframe environment to cloud systems without making significant changes to their underlying architecture or code, which reduces the time and complexity of the migration process. While it offers a relatively quick path to modernization, it does not exploit the capabilities of distributed/cloud architecture, nor does it address the inherent limitations of legacy systems. With this approach, legacy applications can be maintained in their original COBOL, with the lift-and-shift software layer mirroring the adjustments on their rehosted counterparts. This approach not only comes with the previously mentioned limitations, it also has a limited lifespan due to COBOL developer attrition—COBOL SMEs are retiring and no one is being trained to replace them.

Limitations aside, “lift and shift” has proven to be a reliable modernization strategy. But at this point, everyone who could successfully use this solution to move their workloads off of the mainframe has already done it. Those who haven’t typically have massive, complex portfolios that don’t allow for easy migration. For them, rehosting isn’t a real solution—it’s just a stopgap that doesn't address the underlying challenges.

The Cloud-Native Illusion

Organizations want their mainframe applications to magically become cloud-native, but the reality isn’t that simple. Mainframes were built for monolithic architectures, not the distributed environments that the cloud requires. The idea that you can just lift a monolithic mainframe system and expect it to perform like a cloud-native application is wishful thinking.

Mainframes scale vertically—it’s like putting a bigger engine in a Ferrari. The cloud, on the other hand, scales horizontally—think of an army of ants moving something together. To get better performance, add more ants. These two architectures are fundamentally different, and trying to force one into the mold of the other leads to failure.

The Future: AI and Equivalence

The key to successful modernization isn’t about forcing old systems into new paradigms—it’s about leveraging the right technologies in the right way. AI is going to play a crucial role in this, but the challenge remains the same: how do we ensure a seamless, reliable transition while preserving the functionality that businesses so critically depend on?

I founded CloudFrame to answer that question, and I invite you to learn more about what we do.

?