I talk to a lot of CEOs, CIOs, and CTOs who feel pressured to replace legacy (aka proven) applications that have served their multibillion-dollar organizations faithfully for 30 or 40 years or more, in a quest for “modernization.” My advice, more now than ever, is never touch a hot stove, and please don’t burn your house down.

While CEOs tend to have a longer lifespan, I’ve seen a great many CIOs and CTOs come and go because they got burned by an ill-thought-out move toward IT modernization and because, in some cases, they figuratively burned down the house, bringing line-of-business applications to their knees and significantly impacting operations—leaving it to their successors to beat a hasty retreat back to the rock-solid legacy systems that some see as old-fashioned.

Some say it’s a build versus buy question. I say it’s a built versus buy question: those legacy applications are already built and running. Yet I’ve encountered C-level executives who just two months after joining a company have made hasty—turned disastrous—decisions to throw out the old in pursuit of the new. But they’re trying to solve a problem that doesn’t really exist. Well, kind of. Yes, there are known issues and problems. However, companies typically don’t invest in solving these known issues and problems and instead kick the can down the road. Then the new CxO comes in and suddenly gets the green light to make the investment, and money that never existed before is now abundant.

Migrate your code to a new platform? Definitely. For years companies have been moving their legacy systems from OpenVMS, IBM AS/400 and AIX, Sun boxes, and other systems onto Windows or Linux, while retaining the original code of their legacy applications.

Apply a modern user interface? Go for it! With browser-based, Windows-desktop, and mobile front ends, you can change the UI at any time, without endangering the line-of-business legacy code that has kept your business prospering for decades, and you can continue to do so for decades to come.

Replicate your legacy data to a modern database? Absolutely. While preserving your existing data and logic, you also make your data available for ETL processing into a data warehouse or whatever other BI environment you choose.

Use modern development tools? Of course. Armed with the right tools, which a good developer can learn quickly, you can take advantage of the myriad developer productivity, code quality, and other features that are inherently present in modern IDEs like Microsoft Visual Studio. Your legacy application being written in DBL, COBOL, BASIC, or the like does not prevent you from using modern tools and development techniques.

It’s Hip to Be Square

When it comes to retaining your bullet-proof legacy systems that have supported your business for decades, I encourage you to have a new appreciation for the steadfastness of DBL, COBOL, and other legacy languages. As the musician Huey Lewis sings, “It’s hip to be square.” When it comes to stability, DBL, COBOL, and the like rock—as in rock solid.

In celebration of COBOL’s 60th birthday in 2019, Mike Madden posted an appreciation titled “Happy Birthday Dear COBOL,” which presented these figures:

• COBOL supports 90% of Fortune 500 business systems daily

• 70% of all critical business logic is written in COBOL

• COBOL connects 500 million mobile phone users daily

• 95% of ATM transactions pass through COBOL code

• 80% of all point-of-sale transactions rely on COBOL

• There are more COBOL transactions executed daily than Google and YouTube searches

• 1.5 million new lines of COBOL code are written every day

• 2 million people work in COBOL

Yet within the industry, there’s a tendency to judge a book by its cover, to see a green screen and cringe, and to risk one’s career by saying, “We’re going to rewrite that application to bring it into the modern era.”

Upon such statements, careers have faltered and business continuity has foundered.

Too often lost in a rush toward the new is the simple fact that you can apply a modern user interface to your legacy application’s code base, usually in a fraction of the time and at a fraction of the cost of replacing the application with something else.

One of the main techniques for enabling this type of enhancement is to create a “services layer” between your legacy code and your new UI. Usually this involves building RESTful web services APIs that expose your application’s business logic and data through modern, flexible, open, and secure protocols.

Once you have this services layer in place, it can be used by any new UI that you choose to build, using whatever tools you decide to use. But be extremely cautious about trying to rewrite the back-end code that has been reliably supporting your business operations, perhaps for decades.

Question: Do you think you can rewrite 35 years of customized applications in three years? Quick answer: No. I’m sure your business applications have been steadily upgraded and customized over the years, involving a vast number of accumulated developer hours. The nuances in that code should be considered your secret sauce. Could it be duplicated in C# or some other language? Yes—but not within a timeframe, cost, or risk profile that most organizations would want to take on.

Gap Analysis: 2 or 3 Years

In the classic American western Butch Cassidy and the Sundance Kid, the two outlaws have been tracked down by a posse. They’re at the edge of a cliff with nowhere to go except a very rough river far below. As Butch tries to talk the Sundance Kid into jumping off the cliff to the river below, Sundance finally confesses: “I can’t swim!” Butch laughs and says, “Are you crazy? The fall will probably kill you.”

That scene comes to mind when considering the essential task of performing a thorough gap analysis before trying to replicate the old legacy code that you think needs to be replaced. Just the gap analysis can take two to three years. That’s the jump. But attempting to create a new application without a gap analysis—using a needs-based approach—is equivalent to the other fate: facing certain death.

When I speak of the “secret sauce” incorporated into your legacy applications over the decades, I’m not talking about something basic like general ledger, accounts payable, or accounts receivable. I’m referring to the more complex pieces, like order entry and inventory management, that involve intricate orchestrations, workflows, and in-depth business knowledge.

For example, we worked with a company that has long provided DIBOL-based software for tracking grain in storage. That might sound simple enough, but the workflows are complex. Looking at just a subset of the tracked elements: upon arrival, the grain is measured for weight, of course, but also for moisture content, which feeds an algorithm to determine yield and value of the grain. Next, the grain is mixed with other grain in silos where it may sit for months or years, and it is tracked as it transfers from one silo to another for shipment. All along the way, there are elements and dependencies worked into the code that could take some years to identify through gap analysis, even before any actual coding starts.

We’ve seen supposed three-year modernization projects drag on for more than a decade, with still no end in sight. And there was no actual need to replace the application: other options were available that would have addressed the requirements more quickly and at a significantly lower cost. The new CxO just felt compelled to replace the application with something “modern.”

But Who Does Legacy?

A common fear is “But I can’t hire old-school developers!”

Any good developer that you hire out of a computer science program, given appropriate time and support, will learn both your environment and the language that you use. Of course, developing in a modern IDE can only help to accelerate that process. Good programmers adapt to a new language quickly.

The real question should be “Who has the business knowledge?”

What generally takes much more time for a new hire to learn is the specifics of your industry, and that learning challenge applies to all developers. This “domain knowledge” about your industry is what your legacy application has wrapped up in its code: decades of carefully acquired and crafted business logic. It’s not hard to find someone who codes. But try to find someone who knows grain elevators inside and out. Or who knows your international shipping regulations, practices, and requirements. Or your consumer-packaged goods business. Or life and casualty insurance. Those legacy systems are vast storehouses of carefully acquired wisdom, set into code as business logic.

You can put an attractive front end (and please do) on anything, through the use of web services and other modern technologies. But it could take years, perhaps decades, to capture and recast the real-life business logic sitting in that legacy code. So the next time someone suggests a multi-year modernization project, just smile and remind them: Sometimes it’s hip to be square.