Determine the approach
Many organizations and applications suffer from one or more of the risks previously mentioned. When faced with multiple risks, prioritize the biggest barriers above others. From there, figure out the best strategy to resolve the legacy issues.
The US government spends a reported $80 billion, nearly three-quarters of the annual federal IT spend, maintaining and operating legacy systems each year. Concerned about NASA‘s burgeoning obsolete tech, in 2016, Congress asked the space agency to detail plans for modernizing mission-critical systems, including:
Identify the top three critical legacy systems.
Share detailed replacement plans.
Monetize the projected spend to run the systems.
State the year it began using the oldest programming languages.
List the size of legacy codebase.
Quantify the staff fluent in each code language.
Two systems noted in the response dated back to the 1950s. As of 2020, NASA is still executing the plan.
Learning from the NASA story, take inventory of what’s outdated and identify the top three critical legacy systems. Then, determine which systems offer the least risk or the fewest blockers. Based on our experience, here are five ways to approach modernizing.
Cloud migration
Many IT leader’s and team’s workload involves migrating an existing application to the cloud. Does migrating to the cloud add value? Absolutely. Is it the key to fixing legacy issues?
No.
Typically, moving to the cloud involves a large number of resources struggling to manage problematic on-prem environment maintenance with workarounds, which causes slow testing and delivery mechanics. Offering cloud alone does not resolve core legacy issues of an inflexible architecture, inaccessible business functions, or need to scale. The application, flaws and all, just relocated.
The execution: Treat cloud migration as the first step in a multi-phase effort to:
Provide cloud at scale to an otherwise unscalable application in the short-term.
Allot time for a proper refactoring effort or replacement software.
Open the opportunity for a new tech stack and support options.
In-place upgrades
Systems not running the current version risk security holes (e.g., CVEs), support, and overall system fragility issues. Legacy systems older than N-2 or N-3 require dependency software such as Java 6 or .NET 3.5 to be loaded on workstations or hosts. Older software applications with dependencies chance conflicting with newer versions or operating systems and polluting other applications in the organization’s ecosystem. Getting an older system updated to a supported version is an important step to address compatibility and usability issues of legacy applications.
The execution: Migrate to a more current version still supported by the vendor and compatible with any dependent products involved in the solution. Understanding the implications and roadblocks of performing in-place upgrades to current tools helps IT leaders map out the next move with minimal disruption to the organization.
Rearchitect
Rearchitecting is a lot like renovating an older home. The builder decides to tear the home down to the studs, repurpose the foundation or some existing elements with long-term value, and rebuild the remainder of the home using contemporary measures. Similarly, rearchitecting software repurposes good patterns when possible and rebuilds using modern standards. This approach enables enterprises to exploit the enhanced capabilities of a new tech stack.
The execution: Rewrite code and functionality, shifting to a new tech stack. Rearchitecting requires an entirely new blueprint to show the builders how to approach modernizing the system. Like renovating a home, refine the work required by targeting specific areas to address.
Refactor
This technique alters the existing code structure while keeping the application’s behavior intact. A common pitfall of refactoring is stakeholders expecting immediate feature parity. The desire for full parity often results in failure. The scope gets too wide, the work takes too long and costs too much—leaving business partners unsatisfied. Manage refactoring work closely with strong teams at the helm to effectively resolve technical debt, improve features, and scalability. Build alignment from the cross-functional team and stakeholders to determine if the features being rewritten are still valid and necessary before executing. Prioritize the timing of feature delivery and develop a clear roadmap to manage expectations and results.
The execution: Create a service blueprint to map out the current product and what needs improvement. Take the existing application and break it down into bite-size increments, then optimizing existing code without changing external functionality. Slowly refactor the code aspect until complete.
Rebuild or replace
When an application contains elements worth salvaging, rebuild and rewrite code, while still preserving scope and specs. In other words, rebuild a pre-existing solution, leveraging the knowledge gained from the legacy software. If nothing’s worth saving, retire and replace the system—either building or buying something entirely new with clearly defined requirements. Both initiatives include additional barriers and complexities impacting the decision (e.g., team composition, processes, technology choices, and scale of investment).
The execution: Decide whether to build new, buy on off-the-shelf, or customize an existing product. Each option relies on deep knowledge of business processes. Use story mapping to define requirements of the new product and understand the outcomes the business wants. Add a service blueprint to document any viable elements worth repurposing.
Don’t risk losing critical information. Include legacy data migration as part of any change.