Rewrite or rebuild? 5 legacy system upgrade considerations

To rewrite or not to rewrite the legacy system. It’s a perennial question for IT organizations and one that weighs heavy with IT budget, talent and operational concerns. Every week I come in contact with CIOs and CTOs trying to determine the best way to upgrade an aging but mission-critical system or application. After years of helping businesses consider and address their upgrade needs, I have determined there are five main factors IT leaders need to carefully consider when determining whether they are going to rewrite what they have or start fresh with a rebuild.

1. Lagging security updates

Businesses are facing cyber-attacks, data breaches fraud and corporate espionage at eye-opening rates. According to the Kroll Annual Global Fraud and Risk report, 84% of companies in 2017 fell victim to fraud over the course of that year. One of the greatest vulnerabilities to an organization is older, legacy systems in which security updates have been forgotten or fallen behind. Sometimes older systems have fewer users and they get less attention. Other times security patches and updates are no longer available.

A key consideration for businesses asking the rewrite or rebuild question has to be security risks. Can the system and all its data be protected with only a rewrite? Will security and updates face any limitations or support issues if the legacy system does not migrate to the cloud or a hybrid cloud solution? Would a rebuild be essential to eliminating vulnerabilities and protecting data, customers and IP?

2. Cost of system failure

Many business leaders assume a rewrite will be less expensive than a rebuild but that is not always the case. Where the system lives and who will maintain it (is it going to the cloud or keeping to a mainframe?) is key to understanding expenses. Sharing infrastructure costs through cloud solutions is one way to reduce costs. However some legacy applications may already have cloud capabilities and infrastructure costs may not be a factor.

The biggest cost risk is of course that of the failure of a legacy system and the resulting business losses. When a network or technology is older and less efficient than other systems and tools it engages, the risk of failure goes up. That incompatibility with more modern systems and tools can cost a business dearly. The question for the business has to be this: Is rewriting this legacy system enough to guard against future failures? Or, is a rebuild necessary to keep pace with the marketplace and all its technologies?

3. Lack of talent to support older systems

Will the skilled professionals who support your legacy systems today still be around a few years from now? A few months from now? As legacy systems start to thin out, so do the IT professionals who work on them. Technology professionals have learned that the best way to advance and stay relevant is to upgrade their skills and advance with technology. That means finding workers who know and stick with legacy technologies is getter harder and even costlier. A business must examine the talent pool for maintaining a legacy system before settling on rewriting rather than rebuilding. A strong talent pool that will endure makes a good case for rewriting. A rapidly shrinking talent pool has to be considered a cost and a vulnerability risk.

4. Customer retention

Customers are king, and another critical consideration is what happens to them with a rewrite versus with a rebuild. If a system rebuild advances your products or services into new infrastructure and/or forces new compatibility requirements, will your customers be willing to adapt? Will you be burdening them with costs and complexities that could harm the relationship? On the other side of the spectrum, are you slowing your customers down? Are they leaving because of the limitations or risks of your legacy tech? Are you unable to acquire new customers because of system limitations? Look carefully at all sides of the customer equations and consider what approach offers the most to your customers today and the customers you want and need tomorrow.

5. Fear of downtime

Time is always a factor when considering a rebuild versus a rewrite. In some cases, the incremental upgrades of a rewrite offer a good strategy for avoiding major downtime at a critical business juncture. In other cases, a larger, comprehensive rebuild must proceed and the disruption accepted because of the business value of advancing the system. The one trap a business cannot fall into is never taking the steps necessary to upgrade effectively because of fear of downtime. Losing time that you can plan for is far better and far less expensive than unplanned, uncontrolled downtime because of a system failure.

Not all technology advancements across a business can and should be full upgrades or rebuilds. Sometimes a rewrite is exactly what’s right for customers, budgets and time. Other times, the rebuild is what business and innovation demands. The key is knowing how to read the moment, ask the right questions and advance without missing opportunities or leaving customers behind.