In a previous blog, I described heritage systems as those that are likely crucial to business operations but have a high cost of business change. A heritage system could be on-premises or cloud-hosted, it could be one or ten years old, it’s all about their complexity and the risks associated with making changes. 

And sometimes, you can’t avoid big changes to one or more heritage systems, 

• Run costs can become unaffordable. Third-party licences and hosting costs can mount up sometimes. I once worked with a company where the licence cost to upgrade a third-party e-commerce system was tens of millions, and the previous upgrade path had been abandoned.
• Risk profiles can expand. The common example here is unpatched security vulnerabilities, which leave you exposed to cyber threats.
• Cloud provider exit. This is usually due to a rival provider offering an incentives-laden contract. I’ve seen it a few times, and the discounts on a multi-year contract can be appealing.
• Data centre exit. Contract expiry or contract termination are the common causes here. I visited one organisation where a senior leader had decided to move offices post-pandemic, only to learn afterwards it constituted a data centre exit because their mainframe systems were self-hosted on-site.
• Unacceptable performance. A service may be un-reliable or badly built. Running it well operationally on a heritage platform may not meet your desired availability.
• High feature demand is required. High feature demand for a service is not viable in a heritage system (See our previous blog). To unlock this feature demand, something has to change.

Simplifying the AWS 6Rs

Amazon Web Services (AWS) offers 6 migration strategies for deciding on how to deal with heritage systems. Their 6Rs model is well-know and has some great advice. However, it’s technical in scope, it’s written by architects for architects. Most importantly it doesn’t cover the effort required for different migration strategies. This effort is often at the front of our customers’ minds, be that cost or expected delivery time. Here we present an effort oriented alternative, a simpler decision tree for technology leaders to determine cost-effective options for managing their heritage systems.

Click to view the heritage decision tree diagram.

Our decision tree outlines the same 6Rs as AWS but we also ask vital questions about business change and business demand and arrange migration strategies in terms of cost and timeline. Migration strategies are not created equally and will require different amounts of time, cost and effort to implement. When supporting our customers we start with the low-cost low-effort option of retain, moving through core questions to identify the most effective solution, with rewrite as the final, most time and cost-intensive option. It’s also why we prefer to use language like rewrite in our decision tree – to emphasise the effort involved in a heritage service modernisation.

In order of migration effort,  we think about heritage systems as:

We hope you find this decision tree helpful. We’d love your comments, please feel free to reach out on LinkedIn if you would like to discuss further!