Managing Technical Debt From Legacy Systems Not Moving To Cloud
In recent blogs about the legacy technical dilemma and strategic decisions in managing legacy IT, I advised that companies need to reconcile themselves to the fact that they will continue to have significant legacy estates that will take a long time to move to the cloud and, therefore, will have legacy technical debt for the foreseeable future. It is not unusual for companies to have layers of efficiency-focused legacy technology 30 or more years old. That debt will continue to accumulate because companies need to invest in updating those systems to avoid significant business risks. The question is what to do about this technical debt.
Risks of not investing in legacy systems
Three areas of deficiencies affect legacy systems and necessitate investments to bring them up to capabilities for current business needs. The older the system, the more investment it may take to update it to meet current needs, and the more the technical debt will build.
The first area is security, and, increasingly, it is the most compelling of the three arguments. Inconveniently, legacy systems process vital functions in businesses, but companies often overlook this when it comes to security; hence, they are vulnerable to attack. There are so many new threats to technology systems today, and companies uncover threat vectors that they need to patch or accommodate. In addition to the current architecture, security technology is ever-changing; and new technologies emerge, driving the need to reinvest in security for the existing architecture.
Security for legacy applications is where companies least likely want to invest. The mindset now is to invest in the cloud and in platform technologies that improve competitive capabilities. Nevertheless, companies need to identify, anticipate, and close the security risks in legacy technology by investing in legacy environments.
A second argument is exacerbated by the headlong rush into a data-driven world. Almost every company is now engaged in some significant digital transformation. The kinds of data that companies wish to capture now, and the ways data are exposed to multiple systems today, are different than the data flows anticipated when companies built their older systems. Legacy systems house and generate data that is important to the rest of the enterprise, particularly to the platforms companies are building that drive the way they compete and deliver improvements in customer experience.
Increasingly in our emerging data-driven world, all systems are connected through the data channel. Therefore, companies need to continually invest in evolving their legacy systems.
The third argument is the need to increase performance and enhance functionality as business needs evolve. Hence, companies need to invest in adjusting legacy technologies to handle the new functionalities, new volumes, and increased performance.
What is different now than in the past is the level of investment companies need to make in their older systems. Historically, the level of investment to maintain these systems was very modest. That is changing now. Although the level of investment is now higher, companies cannot ignore it. Antiquated hardware that is fragile and breaks sometimes debilitates an entire company.
Why cloud does not eliminate legacy technical debt
Technical debt is more intense in legacy systems that companies do not move to the cloud, so companies sometimes think that transferring them to cloud environments is the way to manage their debt. Indeed, it may lower the degree of technical debt; but moving to the cloud does not necessarily eliminate the debt. In fact, applications that are refactored and not rearchitected often merely transfer the debt to the new cloud environment, and in some cases, the loss of context can inadvertently increase the debt.
Companies often erroneously believed all they needed to do to eliminate their legacy technical debt was to refactor their applications to the cloud and refactor the applications to run in the cloud. Although this can increase the flexibility of a refactored stack and extend its life, the stack often carries with it the architectural limitations of the legacy stack, which can end up obscured through new layers of abstraction and automation. Thus, it instantly creates new tech debt, which makes working with that stack as frustrating and expensive as the previous legacy non-cloud stack.
Another problem is not all applications can be refactored or moved to the cloud, at least not immediately. They are too expensive or too risky to move, or there is no funding to move them. Companies want to put their money into technology that delivers business value; but the business value for investing in refactoring legacy workload systems is modest compared to the alternative investments in growth platforms and developing new capabilities.
Although all companies would like to quickly move completely to the cloud, it is a rare occurrence in which they can do so in a short time period. Many workloads will stay in their legacy formats for long periods. So, companies need to invest in those legacy estates on an ongoing basis to ensure they have no deficiencies in the areas of security, data flow, and performance.
Three approaches to the problem of investing in legacy systems
The question companies face is how to justify investing in legacy systems with the huge investments they need to make in digital transformation and the business increasingly demanding they generate value from the investment. It is increasingly difficult for companies to make the case that they must spend millions of dollars to modernize legacy applications so they can build new functionality on those foundations.
Three arguments are the basis for companies’ approach to this dilemma.
Approach #1: Option Values
In this approach, companies argue that they need to invest the money to create option value for future capabilities. The option value argument borrows from the world of finance, where investments position the investor for possible changes in the future. The vehicle companies use to value options is complicated and difficult to calculate. It is difficult to argue that a company needs to make significant investments in IT under somewhat ambiguous and deferred gratification.
The argument that CIOs and CTOs used to date is less sophisticated and argues that the digital transformation that companies are undergoing as they pivot into technology-driven companies requires that the technology stack must be first transferred into the cloud. With the full tech stack in the cloud, the company will be in a better position to serve the business in the future.
However, with many, if not most, companies having already allocated significant capital to this endeavor and still facing large estates of legacy technology that has yet to be moved or refactored, this argument is increasingly difficult. It looks to become even more problematic as the probability of recession increases.
Approach #2: Risk
The risk argument is that the antiquated legacy systems are increasingly too risky to leave unsecured and without investment. This may become a compelling argument over time. But it flies in the face of the fact that with an ongoing investment (which is often substantially less than an investment to refactor and move the applications to a cloud environment), companies can mitigate risk by investing in security, data, and performance moving forward.
Companies often pair the risk argument with the option value argument, but it is still a difficult argument. The two arguments together are often insufficient to generate the organizational commitment and funding on the scale necessary to migrate and refactor legacy applications.
Approach #3: Crisis
This argument is similar to the argument that the Obama administration used in the 2008 financial crisis when it pushed through health care reform: “never waste a crisis.” This argument seeks to use critical investments that the business supports to slice off portions of the remaining legacy stack. It often accurately points out that companies must modernize the foundational technology for this new capacity to succeed.
Basically, this approach cuts slices out of the legacy pie or foundation piece by piece and, over time, eliminates more and more of the legacy estates. This argument can often be compelling. However, it can be a slow and frustrating process, and companies need to acknowledge this fact in their argument and accommodate that slower pace if they adopt this approach.
The desirability of modernizing the technology stack is clear, and the benefits, although often diffuse and difficult to quantify, are real and substantial. Frustratingly, the last mile of the journey is the most difficult; it is the hardest portion of the journey for funding and building institutional support.
CIOs use all three approaches for determining how to manage legacy technical debt. The first two are difficult arguments to make for decision-makers. The third argument is more powerful but only resolves part of the legacy issue. As the cost of capital rises and the economic outlook worsens, many companies will need to recognize that they will have legacy technical debt for the foreseeable future.