A 4-Step Path to Escape from Legacy Mountain

On visibility and navigation by risk and return

If you came here for the silver bullet to get rid of your legacy code base in one painless flash — sorry, that’s not how life works in this universe.

I’m just gonna give you an outline, a template, some abstract guidance. Necessarily so, because situations differ starkly and details matter. And your legacy mountain will not melt away by itself. Anyone promising you a one-size fits-all solution is being naive or disingenuous.

Escape from Legacy Mountain

Recently, Dion Hinchcliffe and I discussed some of the pernicious issues underlying the IT industry’s legacy problems. These include lack of visibility, structural underinvestment, and immature software economics models. And we identified some of the solution elements that CEOs and CIOs need to make meaningful progress on freeing their organisations from legacy issues that may obstruct their digital transformation:

• CEOs need to identify which strategic objectives are threatened by legacy IT and must provide air cover to the CIO and IT staff that sets out to confront this challenge.
• CIOs need to obtain visibility of their IT landscape, including detailed technology footprints and inter-system dependencies, and provide economic clarity regarding required resources, ROI, and inherent risk of renovation options.

With the solution elements above in place, planning one’s escape from Legacy Mountain can start.

Risk and Return

In our consultancy practise at the Software Improvement Group, we have advised hundreds of customers on their legacy software and helped them safely navigate conversions, migrations, and decommissioning efforts. Based on this experience, we have observed that successful paths for dealing with legacy software have one important thing in common: they continuously navigate a delicate balance between risk and return.

• Risk: Each change in your legacy code base comes with a risk. The risk of breaking something, leading to corrupted data, service outage, an unintended alteration of behaviour. The more difficult the change, the higher the risk. Difficulty is determined by many factors, most notably coupling, i.e. the degree to which the area of code you are changing is connected with other areas.
• Return: Also, each change in your legacy code base is an investment (of effort) with a potential return. The return are the future benefits of the change, which may include higher business agility, reduced operational cost and risk, or simply regulatory compliance.

Start with visibility

By default, both risk and return of changes in your legacy landscape are uncertain variables. Getting them quantified up to a minimal level of certainty is an investment in itself. Some of this investment needs to be done up-front, before making any changes. Some of this investment can be done at each change, gaining visibility as one goes.

But for now, let’s not get into the particulars of making risks and returns of legacy changes visible, and just imagine a sufficient level of visibility for now. With that data, your legacy systems can be mapped into 4 quadrants along the risk and return axes:

Mapping legacy systems on the dimensions of risk (complexity, coupling) and reward (ROI).

So, in the lower-left corner, systems are easy to change because they are not too complex and loosely coupled. But replacing or renovating them holds limited returns, because for instance they are small, stable, and require very little maintenance work. In the upper-right corner are highly-complex and tightly-coupled systems where lots of costs can be saved and lots of high-value change requests are waiting.

Escaping legacy mountain in 4 phases

Given visibility into risk and return, your legacy renewal efforts should run through the following 4 phases.

1. Practice: Start with some practice runs. Select systems with low risk. This definitely means they should be small, limited complexity, and very loose coupling to the rest our your landscape. Any changes you make on these systems may be low ROI, but your main objective is to gain experience and confidence. Get your processes and technical solutions for migration, conversion, commissioning into shape. Let tiger teams form and become effective. Book some early successes. Cause your first disruptions and learn how to recover from them.
2. Gain momentum: After your practice runs, move on to systems with higher ROI, but stay on the side of low risk and difficulty. You can scale your process, tools, and teams to work on more systems in parallel. Make sure you have measurements in place to track progress and detect unexpected obstacles. These measurements can not be limited to human-generated progress reports — they must be based on direct observation of changes in your legacy code base.
3. Main thrust: Now you are ready to move to the right-side of the chart, taking on the systems that are high on complexity and coupling. Your teams, technology, and processes have been hardened. Measurements are in place. You can pull this off. Since you are taking higher risks, be sure to manage expectations of users and enlist the support of your business leaders. This is where the air cover from the top is most essential.
4. Last push: It may be tempting to stop here. Most returns are in. Why continue to reap diminishing returns against similar costs? Still, it is essential to finish the job. The ROI is not to be found in the remaining systems themselves, but in the clean slate overall that you will have. Keep them alive, and you will have fruitful soil for new legacy to grow. Go the last mile.

Finite program or continuous discipline?

So what happens after running through the four stages sketched above? Your next challenge is to convert from a time-bound campaign to a continuous activity. Ultimately, legacy renewal should be part of daily life rather than a short-lived program. And it should be done in short cycles rather than as a high-risk endeavour.

In fact, we see that not many organisations that start an ambitious legacy renewal program get beyond the inventory stage, and fewer are able to run their entire program successfully.

So, be sure to set the right ambitions at the start. If your first iteration over the phases I sketched will take you longer than 2 years, better get back to the drawing table. Carve out a smaller scope to work on, or settle for renovation or encapsulation of some of your legacy applications, rather than wholesale replacement.

At the Software Improvement Group, we have believe that legacy renewal has to be approached in a lightweight, iterative, measurement-led
fashion, reliant on your own staff as much as possible as well as
on strong connections to the rest of the organisation. We see four elements any successful organisation should have in place:

1. Make good use of measurements to create the required visibility.
2. Be capable of working in short iterations based on these measurements.
3. Rely for a large part on good connections to the rest of the organisation to quickly identify whether it is meeting their needs and where there may be opportunities for improvement.
4. Give people the mandate to improve things they see themselves directly (empowerment).

I gave you fair warning at the top. Only a rough outline, no silver bullet. Depending on your situation, the actual path to escape from Legacy Mountain may be rough and steep. And it should be iterative.

Take a look at the 3-pager attached below, or let me know if you’d like to discuss how legacy renewal can be done successfully in your organisation.

Joost Visser is CTO at the Software Improvement Group, Professor of Large-scale Software Systems at Radboud University, and author of O’Reilly books “Building Maintainable Software” and “Building Software Teams”.