Most companies today have a strategy for—or at least some goals surrounding—digital transformation. But as much as a coherent digital strategy is recognized as a necessity in today’s business world, many companies still struggle to achieve their digital goals. One common barrier they face is their dependence on legacy software. Removing this barrier has the potential to accelerate a company’s digital transformation, but it is important to understand that there are a number of options when dealing with legacy applications:
Option 1: Replace
The simplest option conceptually—though often not the quickest or most cost effective—is to replace the existing application with a commercial off-the shelf solution. This is often a good option when an application’s functionality is no longer aligned with the business’s strategy or functional requirements. Although the process is conceptually simple (just buy new software!), COTS solutions often require a lot of work to integrate with existing systems. The complexity and risk increases with the number of legacy applications and databases and how central the application is to core business processes.
Option 2: Traditional Rewrite
The next option to consider is a traditional rewrite of the software. A traditional rewrite goes through the full Software Development Lifecycle, including specification, detail design and development. This option will provide modern, cloud-ready technology and the flexibility to add new features and functionality. Unfortunately, traditional rewrites often fail; even successful rewrites are frequently delivered past their due date and well over budget.
Legacy systems often have decades worth of embedded business logic hidden within their code that even subject matter experts may have difficulty discovering. The burden on the company becomes, therefore, not only to define the target architecture, gather test cases, develop a new application, and integrate the application into their existing IT ecosystem, but also to retroactively specify the existing functionality and business logic that have been achieved through countless cycles of development, improvement, and debugging.
Without this knowledge developers are basically left reinventing the wheel, contributing to cost and time overruns. A lack of functional equivalence may only be discovered at the end of a months or years long project. Therefore, while the desire to build the ideal replacement application from the ground up is undoubtedly enticing, it is important to keep in mind the risk it entails.
Option 3: Modernize the Legacy, Wrapper to the Cloud
This is a common intermediate step, a digital-era version of the classic lift and shift. The legacy applications are modernized to make them maintainable without actually transforming the code. The result is still written in the legacy programming language but is in a variety that can be maintained using modern IDEs for the time being. Wrappers and middleware can be used to combine and integrate these applications with some modern digital technology or to migrate them as is to cloud environments.
While this may be a cost effective solution in the short term, and may be desirable in situations where speed is more important than long-term maintainability and security, such a solution increases a firm’s technical debt and doesn’t really solve the problems associated with the legacy software, which remains technically and conceptually unchanged, so much as provide a temporary work-around. In the long run, the firm is still dependent on disappearing legacy skills and burdened with a higher total cost of ownership.
Option 4: Automated Code Transformation
The automation reduces human error, increases speed by 3 to 4 times compared to the traditional rewrite, and may or may not include automated database modernization/migration. This process covers not only the transformation itself but also verification that the business rules have been preserved during the process. This option appeals to many IT leaders, because it accelerates their digital transformation efforts while simultaneously reducing the risk of failure.
When choosing a partner for this type of modernization project, it is critical to consider the code quality of the output. For instance, many providers will provide quick automated code translation from procedural languages to modern languages which nonetheless retains the procedural flavor of the original rather than producing truly modern, object-oriented code (In the case of a COBOL to Java translation, this is known as JOBOL). Be sure to choose a partner who uses tools such as SonarQube or CAST to measure code quality.