Whenever I hear that 1980s song “I’m Still Standing” by Elton John, I like to think it’s about the rock-solid dependability of legacy systems. Back there in the shadows of the machine room, the legacy system runs smoothly year after year—for decades—providing the stability that allows an enterprise to grow and flourish. Like the song, it’s still standing after all this time, better than it ever did. But that stability is threatened when the organization starts down the road of leaving a mature, working system in the quest for something new. Under the banner of modernization or digital transformation (often initiated by a new CxO), an organization will sometimes abandon the legacy code that has faithfully supported its line of business operations in the belief that they can replicate rock solid legacy code with a new application. The results can be disastrous.

Given enough time and enough money, it may be possible to capture the decades of nuanced business knowledge, best practices, and mission critical logic that have been crafted into your legacy (aka proven) enterprise code. However, over many years of working with enterprise IT organizations and their CxOs, I’ve seen very few of these projects completed, and I’m not sure if any of those would really be considered “successful.”

In the best-case scenario, the organization recognizes that they’re going down the wrong path early in the effort (often when new CxO #2 enters the picture), and they return to their trusted legacy code. They discover the logic of moving to a modern solution with the code that has kept their business running for decades. Add a modern UI/UX? Yes! Integrate with other systems inside or outside your business? Sure! Go to the cloud? Not a problem! The trick is to add whatever front-end or new functionality you want—while keeping the proven legacy code that runs your operations.

In the worst-case scenario, they continue to run away from their legacy stability as they pour money and time—many years’ worth—into attempting to recreate something that was never broken. The legacy code that keeps businesses thriving has been crafted over the years to the point where just understanding all that it does—and why—would be an extremely challenging, multi-year project in itself. And heaven help a development team that sets out to replace a legacy system without knowing everything that it does. I believe this is the primary reason these projects fail: they require much more time and money to replace functions the project team never fully understood. (For more on this, see my blog post titled “When It Comes to Legacy Systems, It’s Hip to Be Square.”)

$500 Million Trainwrecks

I’m not the only one who has seen the trainwrecks that can happen when perfectly good legacy code is tossed out simply because it’s perceived as being old. (Age discrimination for applications?) Henrico Dolfing, who spoke at our 2022 DevPartner Conference, maintains an entire blog on this topic. Or you can find your own: Google “SAP disasters” or “ERP project fails” or whatever similar phrase comes to mind.

A few years ago, The Register published an article headlined “ERP Disaster Zone: The Most Costly Failures of the Last Decade.” Just one example from their collection: A German supermarket chain spent 500 million euros—about half a billion dollars—to replace its in-house legacy merchandise management system . . . before terminating the project. To the company’s credit, they finally pulled the plug at the half-billion-dollar mark, while others remain trapped by an “in for a dime, in for a dollar” mentality of hoping that success will be somewhere down the road, without realizing just how long and expensive such a road can be. But wow! Half a billion? That’s a lot of money down the drain. And, had the plug not been pulled, it could have been even worse.

The Costs Keep Coming

In my many years of experience, I’ve seen that organizations attempting to replicate the functionality of a legacy application in a new application not only spend significantly more years and many more millions of dollars than initially planned, but they also end up with an application that differs greatly from the plan. As reality beats away at their original aspirations, the glowing vision slips into survival mode: What can we do to keep things at least business functional?

Even if and when the development efforts are declared complete, the costs keep coming.

A legacy system generally has a low base for operational costs. You are dealing with a known quantity. Even a system’s shortcomings are known and can be addressed. But with a new application, you are continually dealing with unknowns, as shortcomings arise because (despite all the time and money invested) the new application doesn’t capture everything that was crafted into the original system.

This means operational costs are higher, and the work-around development costs never really end.

A key question for these “finished” projects is, considering all the costs during the project and the additional costs now required to develop/maintain/support the new system, does the ROI really pan out? Will the new system have enough benefits to warrant all that extra time and money? Especially when you could have moved forward and met your modernization needs at a much lower cost and much less turmoil with your proven legacy code?

One former customer offered a candid reflection on the question of ROI based on his company’s experience. He noted, “Moving to the new ERP system took seven years instead of the planned three; the budget increased by 500%; and we still don’t have the stability or speed of our legacy system.” (For more details about lessons he learned on that project and others, I suggest you read the case study.)

Invest in (and Move Forward with) What You Have

From my experience, here’s how the typical scenario plays out: The legacy (again, the proven) enterprise application that was developed and refined over the years has been fine-tuned and tested and is a rock-solid product servicing the needs of the company. Any issues are known. These may include a desire to update to new hardware or operating environments, move to the cloud, enhance the user interface/user experience, improve data access, provide web access, find skilled resources to continue development and maintenance, and so on.

Yet most companies do nothing to address these known issues—essentially kicking the can down the road. The reasons vary: inertia, thinking that nothing can be done to improve the situation, no one championing a way forward, an “out of sight, out of mind, if it ain’t broke, don’t fix it” mindset, no budget allocation for enhancements, lack of domain knowledge because the original creators and developers have moved on, technology influencers looking for the next shiny toy to add to their skill list or thinking they can save the company money by reducing license and other fees with “their” solution, and many more.

Then one day, the company decides changes are needed. A big budget is allocated, a vision of a perfect new system to replace the old one is presented, project schedules are established, and the project moves forward. Interestingly, these projects used to be projected for two years, and it was fairly easy for companies to pull the plug when they went awry. These days, initial projections for such projects are typically three to four years, though in reality they take seven to ten. With that larger investment, companies have a harder time pulling out when they realize they’re on the wrong course. They feel there’s no turning back, so they throw even more time and money at the project and continue down an unfortunate path.

A new CxO might go into this type of project thinking this predicament could never happen to their company, believing they are doing it differently, but the same outcome occurs time after time. The success rate of such replacement projects is consistently very low.

My advice: Rather than spending a massive amount of time and money creating something new, simply enable your existing legacy system to meet your needs—whether it’s adding a new UI, moving to cloud-based infrastructure, generating user-friendly analytics, or whatever other advancement you’d like. You can be a hero. It will look great on your annual review: Saved the company $500 million and 10 years of misery.

Three Questions to Ask

In an ideal world, the following questions would be thoroughly researched and objectively answered before anyone considers heading down a replacement path:

1. What are the real problems we are trying to solve?
2. Can we solve these problems using our current system?
3. What are the actual costs of alternative choices (money, time, stability, loss of functionality, distractions, the duplicated effort required to continue maintaining an existing system while developing the new one, etc.)?

With almost any legacy system, vendors are available with tools and resources to help achieve the desired results at a fraction of the cost and with a high degree of success. Add a new UI/UX, put your application in the cloud, give data access to executives, train the next generation of developers, have managed services to do the work for you—companies (including many Synergex customers) are doing these things and much more with their legacy systems.

Wouldn’t it be a relief not to have to replicate decades of business intelligence? Knowing that you have it in place and can focus your efforts on extending that critical logic instead of replacing it, you’ll have the best opportunity for a successful modernization project, one that requires a lot less money and provides a superior outcome. Synergex’s investment in our tools and consulting services has a proven track record of ensuring success. In our 47 years, we have never wavered from our primary focus of empowering you to leverage your initial investment in perpetuity. Or as I like to say, your legacy-based applications will still be standing—and thriving—in the year 2100 and beyond.