Modernization Strategies: Retire, Refactor and Isolate
Large software systems that have been around for a while can be notoriously difficult to modernize.
These applications can be decades old, serve millions of customers, be built on top of multiple technical stacks, have huge code repositories, and can be burdened with a significant amount of technical debt accumulated over the years.
Most initiatives that attempt to rebuild these systems from scratch are expensive, have significant slippage, create customer retention challenges, don’t deliver the business or customer value originally envisioned, and are often prone to cancellation midway through.
Most businesses should avoid these “from scratch” efforts, but these kinds of projects are frequently undertaken regardless of the risks, primarily because of how attractive the idea of starting from scratch sounds (at first).
The allure of a hyper-scalable technical stack, a brand-new user experience, and functionality sure to please current and new customers alike is often too compelling for organizations to resist.
But happily, there are better approaches that offer a lower risk profile for both the business and its customers.
One such strategy is to Retire, Refactor and Isolate (RRI) the legacy platform in order to modernize it.
This approach involves organizing the legacy software ecosystem and its customer-facing capabilities into 3 primary groups:
Group 1 are all the capabilities that after careful analysis, can be retired by the business in the near future. For platforms that have been around for 5, 10 or even 20 years, there are almost always some capabilities that the customer-base no longer has a significant need for and don’t provide strong ROI to the business.
Group 2 are all the capabilities that should be refactored in terms of feature design & technical stack. These are the most critical capabilities of your application ecosystem and the ones your customers rely on the most heavily and drive the most value.
Group 3 are the capabilities that are also useful to your clients, but don’t warrant investment in terms of a feature redesign even though they may suffer from technical flaws. These capabilities should be technically isolated from the rest of the ecosystem.
Let’s examine each group in more detail.
The Retire Group
This aspect of the approach involves looking for opportunities to retire (withdraw from the market) the software capabilities that your customers no longer highly value or don’t provide a clear ROI to the business.
This is a good place to start in planning your modernization efforts since retirement of capabilities produces an immediate reduction in execution risk as no effort must be spent to modernize soon-to-be-retired functionality.
But for older products with many customers and a large ecosystem of features, this list might be difficult to define.
What’s helpful is to take a look at 2 things: your application usage analytics (what features your customers using) and your Sales CRM data (what features sales needs to sell).
Whether you’re using Google Analytics or some other tool, digging in to find out what capabilities your customers actually use (or don’t use) is key.
Combining this information with data from your CRM tool will give you a good idea of what capabilities play only a minimal part in either your company’s sales process, or in post-implementation usage of your application.
Further, the “Retire Capabilities” list should have agreed upon sunset dates. And so you may also need a migration plan for the clients potentially using these capabilities who will need an alternative solution (either yours, or via a partner).
From a technical view-point it is wise to take a deliberate approach to the deprecation of functionality.
In other words, it’s important to take the time to archive code repositories, remove database tables from production, delete non-essential data, shut down VMs, remove SKU’s from CRM tools, and so forth.
This is very helpful in terms of reducing cognitive load on your product and engineering teams. And also enables your team to shed major parts of the legacy baggage.
In the end, carefully thought out capability retirement planning is a powerful way to reduce risk & scope in the process of modernization.
Now let’s take a look at the Refactor Group.
The Refactor Group
Refactoring (or rewriting) the most essential customer-facing capabilities of a large software suite is of course where much of the value-creation of modernization happens.
But it can get tricky.
Everyone from Product, Sales, Engineering, Support, and the Business in general will have views on what capabilities should be modernized.
But, in the end it will mostly boil down to a combination of two things:
(1) What is the Product Strategy in the context of modernization? Is it to optimize for sales growth, customer retention, or some combination of both? The proper balance has to be struck here.
(2) What is the Technology Strategy in the context of modernization? Is it to optimize for velocity, quality, or cost? Again, it’s about striking the right balance between these 3.
Ultimately, the list of “Refactor Capabilities” is very significant in terms of realizing the value of modernization. But it also may be the most difficult to come up with given the strong competing interests.
From a technical standpoint, the team is likely developing new architectures for the refactored capabilities that will solve for the technical debt.
In doing so, the design of the new stack must ensure that the refactored capabilities can still interface with the legacy system.
This brings us to the Isolate Group.
The Isolate Group
These are capabilities that perhaps generate sales growth, help customer retention or provide other valuable benefits for the business, but for one or more reasons don’t make sense to invest in further in terms of UI or functionality redesign.
For example, a battle-tested capability that customers know and love, which requires little by way of on-going feature enhancements.
There are no major benefits to the customer in modernizing this aspect of the system.
However, these components might come with their own technical challenges. Examples of which include:
- Old technology requiring specialized skills
- Unappealing defect rates
- Security issues
- Integration challenges
- Scalability problems
Isolation is one way to address this group of capabilities.
Isolation in this context involves creating a technical separation between these legacy capabilities and the new refactored capabilities.
This separation ensures that the new capabilities are not impacted by whatever ails the legacy stack.
But this has to be handled with care.
The legacy system continues to plays a vital role, because it supports features that customers still use frequently, so major technical changes must be carefully managed.
At the same time, whatever the challenges of the legacy system are is at least part of the reason why you’re in the position of having to modernize in the first place.
By isolating legacy you can defer making your technical debt payments in that part of the ecosystem until you’ve addressed the higher value refactor capabilities.
If that’s not something you can wait on, isolation (technical separation) still enables you to optimize the legacy stack while separately addressing the refactor capabilities.
You can split your teams to accomplish both efforts. This might be desirous from a focus, developer cognitive load, team structure, and management standpoint.
Ultimately the Retire, Refactor, and Isolate approach advocates for eliminating unused capabilities, and then running both the legacy and modern application stacks side-by-side with an interface between them.
This is more advantageous for larger, expensive platforms in terms of additional investment and risk vs. spending enormous amounts of time and money to achieve an idealistic single new system from scratch.
Meaning, don’t throw the Hail Mary pass. It’s rarely worth it.
And regardless, most long-living systems they are very rarely built as a singular structure. They are invariably comprised of multiple smaller systems running side-by-side, developed in different technical styles, by different teams over the years.
In the end, Retire, Refactor, and Isolate is about establishing clear business priorities and minimizing risk for larger platforms before beginning the process of modernization.
Leveraging the RRI framework to do the upfront planning and analysis work in order to determine the 3 groups of capabilities, is a relatively small and yet critical time investment to set the direction for what is sure to be a high-stakes, multi-year effort to modernize your platforms.
