Image: Getty Images/iStockphoto

Why would you ever bother to move an ancient COBOL-based application to the cloud? Sure, it sounds great–from pricey mainframe to cost-effective cloud–but buried in that transition is a lot of effort, far more than most realize. So why bother?

I asked that question of Brandon Edenfield, CEO of Modern Systems, a provider of modernization solutions for legacy application source code, data and platform transformations. Modern Systems worked with The New York Times to move a business-critical application that managed daily home delivery of the newspaper since 1979, supporting a line of business worth more than $500 million annually. The goal? Get it running on Amazon Web Services.

SEE: Amazon Web Services: An insider’s guide (free PDF) (TechRepublic)

Harder than it looks

The problem, as Edenfield told me, and as The New York Times IT team wrote up, “the IBM Z mainframe running the z/OS operating system was expensive to operate in comparison to more modern platforms that had evolved at the company. It needed modernization to reduce operating costs and enable the convergence of the Digital Platform with the Home Delivery Platform.” How expensive? According to Edenfield, The Times was “sitting on the most expensive platform in the market: An IBM mainframe. It’s tremendously expensive. You don’t buy your software, you spend huge amounts of money to re-license it every year.”

Worse, that architecture hampers development all around. First, no one teaches COBOL anymore. Those with the requisite skills tend to be in their sixties, nearing retirement. When they do retire, their knowledge of that language (not to mention Assembler and the other old-school languages accompanying the application) will leave with them. Second, enterprises tend to lose track of which source code is running in production, making it hard to know how to update the code to meet evolving needs. Third, even if you can figure out how to patch that 20-year old, end-to-end solution without breaking it, a typical enterprise will invest 80% of its brain power on 20% of its assets, with legacy systems chewing up an inordinate amount of that brain power.

SEE: Prepare for serverless computing (ZDNet special report) | Download the report as a PDF (TechRepublic)

So why not just move that application to the cloud and realize 30 to 50% cost savings right off the bat, not to mention getting horizontal scalability and dramatic increases in development agility?

While that sounds great, Edenfield said, such transitions are “a lot more effort than people rationalize it will be before they start.” In fact, depending on the approach, a replatforming (with attendant rewrites) can introduce new risk or, if you do it right, lessen risk. But that risk is real. As Erwin van der Koogh has posited, “Rewrites don’t work. You can’t build a new system that does what the old system does. You don’t even know what the old system does in enough detail.”

As such, Edenfield said, if replatforming were simply a matter of cost savings, “I’m not sure anyone would move.” No, the real benefits run deeper.

But worth the bother

One huge reason for going through the bother is, as Robert Taylor put it, “increasing the pool of operations expertise on the platform itself. Mainframe Ops isn’t a path most take.” Concurring with this view, analyst Krish Subramanian said, many enterprises are working to “Get their legacy and greenfield environments in the same [environment].”

SEE: Hybrid cloud: A guide for IT pros (free PDF) (TechRepublic)

Initially, however, the goal for The New York Times wasn’t to get the Home Delivery application running in any particular cloud–they were just trying to move from COBOL to Java. That shift, which started with the COBOL-to-Java automated conversion (and “which retains functional equivalence and critical business logic while converting core legacy applications to maintainable, refactored object-oriented Java), and included a VSAM-to-relational database conversion, took two years. Along the way, the teams involved realized that it made sense to move to AWS, given that so much of the paper’s applications were moving to the public cloud. This second piece took eight months and, as outlined in a blog post on the AWS site, included the following steps:

  • From Oracle RAC to Oracle EE
  • From Isilon to EFS
  • Upgraded Control-M from version 7 to version 8
  • Upgraded from FTP to SFTP/S3
  • Rebuilt CI/CD pipeline (from Puppet to Ansible)

With the move to AWS complete in 2018, The New York Times “benefited from maintenance and enhancements including promotion code table expansion, premium Home Delivery (HD) with new digital and paper offerings, and AWS cost optimizations.” Looking back, the NYT’ IT team stressed that “If The New York Times had its cloud strategy already in place before starting the mainframe migration, the company would have chosen to migrate the mainframe directly to AWS, avoiding the extra work for designing and implementing the on-premises…deployment.”

The Times now has the benefit of running this application on its common technology stack (Java and Oracle on AWS), not to mention the whole thing costing 70% less each year to operate than its old IBM mainframe.

What about your apps?

So which apps belong in the cloud? According to Edenfield, “Every application has a reason for living in the cloud.” While it may make sense to allow apps that are going to die anyway, to die, and you may have other apps that don’t really serve current business needs, most apps make sense running in the cloud.

But if you do, according to Edenfield, make sure you prioritize testing. “Everyone underestimates this part,” he said, but testing “ended up being the most time-consuming and underestimated part of the project by far (70 to 80% of the time),” according to The New York Times blog. As such, “Test cases need to be granular enough and automated.”

If The New York Times found significant value in moving its ancient COBOL-based application to the cloud, chances are that you will, too, with your old-school apps.