.webp){kind=logo}
By Balaji Swaminathan
The more you learn about the benefits of cloud-native infrastructure, the more seductive the idea of greenfield rewrites becomes. Imagine being the person to bring your aging infrastructure into the modern era. It’s a career defining achievement. But beware the siren’s call. Deep in the bowels of your legacy system, a dragon slumbers. In this article, CloudFrame’s Chief Scientist, Balaji Swaminathan, discusses the perils of disturbing it.
How it Started
There’s a story I often tell when someone brings up the idea of doing a greenfield rewrite as part of a mainframe modernization strategy. It comes from our work with a major Financial Services company, where we had boots on the ground, sleeves rolled up, doing real, measurable modernization.
We had some solid wins. A couple of high-impact COBOL applications were modernized using code conversion tools that leveraged AI to preserve logic, converted COBOL to Java, and integrated with modern cloud platforms. The work was complex but manageable, thanks largely to the fact that we weren’t trying to reinvent the wheel, just moving it from the garage to the racetrack.
Then one of the application owners—smart, capable, and understandably frustrated by the limitations of legacy COBOL—decided to go all in on a greenfield rewrite. “No more legacy crutches,” he said. “No more compromise. Just a fresh start.” The goal was ambitious: to rebuild the application from the ground up using modern frameworks, cloud-native design principles, and the latest in front-end tooling.
And that’s where things started to unravel.
The Hidden Depths of Legacy
Here’s the thing about these legacy COBOL applications: they didn’t get to be the size and complexity they are overnight. They grew organically, sometimes chaotically, over decades. They’ve been patched, extended, duct-taped, and hot-fixed by multiple generations of developers. The documentation—if it exists—is usually outdated and/or incomplete. And finding a subject matter expert (SME) who understands the entire application is nearly impossible, since that person most likely retired a long time ago.
With the greenfield effort, they quickly discovered just how much tribal knowledge was buried in those legacy systems. A calculation buried in a subroutine. A business rule nobody remembered existed. A data format that seemed arcane until they realized it was supporting a regulatory reporting function that absolutely could not break. These things didn’t show up until much later—after months of design and development. And by then, course-correcting was painful.
Meanwhile, the projects that leveraged COBOL-to-Jave conversion tooling were moving forward. There were compromises, and the code wasn’t “from scratch.” But they had continuity. They had a way to validate functional equivalence. They didn’t have to rebuild the data model. And they could integrate with other applications still running on the mainframe using well-documented APIs and extension points.
Greenfield Isn’t Free
There’s a seductive quality to the idea of a greenfield rewrite. Who wouldn’t want to leave the baggage behind and start fresh? It feels like the bold choice, the modern choice—the one that will finally break the cycle of legacy lock-in. But too often, greenfield turns into a quagmire. Projects balloon. Timelines stretch. Budgets get blown. And the “new” application often ends up being a shadow of the original in terms of coverage or correctness.
This is not to say that greenfield is never the right approach. In some rare cases, it can be. But even then, it needs to be approached with open eyes, rigorous discovery, and a contingency plan. It’s not something you do just because you’re fed up with COBOL or because you read a blog post about microservices.
The Pragmatic Path Forward
Transformation tools—especially those augmented by AI—offer a middle path. They let you bring legacy applications into modern environments without having to deconstruct and rebuild every last bit of business logic. You retain the core value of your existing systems while gaining the flexibility to modernize incrementally. You can move pieces at your own pace, validate functional outcomes, and reduce the risk of massive disruptions.
In this specific case, the greenfield project didn’t completely fail—but it came in years later than planned and delivered far less than originally scoped. By contrast, the projects that used AI-assisted transformation tools were in production and delivering business value within months.
In Summary
Modernizing mainframes is hard. Rewriting COBOL apps is harder. And doing it from scratch, without deep expertise and a full understanding of your legacy system? That’s a gamble that often doesn’t pay off.
Before diving into a greenfield rewrite, ask yourself: do you really know what’s hiding in that legacy system? Can you afford the delays and risk? And are you sure that starting from scratch is the only way forward?
In most cases, a thoughtful, tool-assisted transformation will get you further, faster—and without disturbing the dragon that slumbers deep in your legacy codebase.
