Think carefully before taking a "rip and replace" approach to legacy technology

710 readers like this.
CIO Digital Transformation 2

Stuck with a lot of legacy software and wondering what to do? Don't just junk it and start over. That advice comes from Wolfram Jost, Ph.D., CTO of digital business platform company Software AG. In the first of a two-part interview with The Enterprisers Project, Dr. Jost offers some thoughtful advice for dealing with legacy technology while addressing digital disruption.

CIO_Q and A

The Enterprisers Project (TEP): You have written that digital transformation needs to be unconstrained by earlier IT decisions – and yet virtually all large organizations are burdened with legacy technology. How do you balance that burden against the need to move forward quickly? How do CIOs determine when it's necessary to "rip and replace" a system and when it makes more sense to find a workaround or a way to integrate it? 

Jost: I think "burdened" is the wrong word to use when discussing legacy technology. It has been said that if you run hardware long enough, it breaks. If you run software long enough, it works. So legacy applications simply work. That is not a burden. That is the distilled business experience of up to half a century. 

TEP: But isn't that also a problem? How can we do business in today's world using technology that's up to half a century old?

Jost: Certainly, digitalization and, say, the Internet of Things demand new digital business processes, but to throw out, to "rip and replace," the software solutions developed over decades would be throwing out the baby with the bathwater to an absurd degree.

It is estimated that 350 billion lines of COBOL code are in operation globally, processing up to 30 billion transactions representing one trillion dollars of business daily. Looking just at the United States, 95 percent of ATM transactions, 80 percent of point-of-sale transactions and over 90 percent of vacation bookings use COBOL. The average American probably interacts with the language more than 10 times a day. 

Stopping digitalization to save money means stopping a watch to save time. Digital Darwinism will be unkind to those who wait. 

To rip and replace these high performance, robust, stable, effective applications would entail – I use the word again – an absurd level of risk and cost. The business logic that sits in these so-called legacy applications has grown over many years and is of huge value and can't be replaced easily. This IT infrastructure, which doesn't appear on any hype cycle, keeps the world running smoothly and will be with us for the next 100 years. 

There is also the issue of the generational change, finding a new generation of programmers to keep these well-oiled applications running smoothly. The average age of a COBOL programmer is currently 55. This generational change will, of course, affect every language eventually. I have already seen articles that claim things like, "Java is the COBOL of my generation, and Go is its successor." This will be a recurring issue in the IT industry.

TEP: With all this COBOL and other older languages in such widespread use, digital transformation is likely to be painful. How can CIOs and other leaders determine when and whether the gains provided by such a transformation will be worth the expense and disruption?
Well, the "when" is now and the "whether" is simply to stay in or go out of business. We are at the cusp of an IT revolution of a magnitude never seen before with enterprises exploring ideas and building applications that will change the way we live for the better.

Digital disruption is the No. 1 paranoia haunting today's management teams. There are many emerging game-changing technologies lurking out there and so maybe a little board room paranoia is not a bad thing. After all, necessity is the mother of invention.

But, digital disruption is just digital innovation in action. It makes the inefficient efficient. It reallocates resources, at a macro and enterprise level, to where they can make the biggest bang. 

TEP: How can IT and business leaders manage that change while still depending on existing legacy technology?

Jost: Every enterprise must have a digital strategy. A digitalization strategy is a strategy for the unknown. That is the most challenging issue facing the CEO. One factor is the incredible shift in power to the customer seen over the last five years. Communicating and interacting through multiple channels, customizing products and services to a market of one, involving customers in product design, coping with customers that can source globally and compare prices globally, providing add-on digital services and the immediate influence of market opinion anywhere in the world, anytime, are all examples of this shift.

A second factor is the industrial internet. The industrial internet will have a much bigger impact on digitizing the world than the social or consumer phase of digitization ever had. And the opportunities will be correspondingly large. We are still in the early stages here and the who, what, how and why of the industrial internet are all wide-open issues. This is why I say CEOs must form a strategy for a future that is largely unknown, evolving continuously. 

The greatest threat is doing nothing. Stopping digitalization to save money means stopping a watch to save time. Digital Darwinism will be unkind to those who wait. 

Minda Zetlin is a business technology writer and columnist for She is co-author of "The Geek Gap: Why Business and Technology Professionals Don't Understand Each Other and Why They Need Each Other to Survive," as well as several other books. She lives in Snohomish, Washington.


Usually businesses do not use a technology which is more than a decade older. There have been immense advancements in technologies for business applications which everyone has to adopt or would have derailed themselves from the fast growing competition.

Today, with Digital Transformation, business has to develop a culture where each application has to be interconnected for the smooth conduct of businesses.