Legacy Migration Strategies

What do you think of when you hear about a legacy system? A machine in a corner with a broom handle holding the power switch on because the switch slips to off when nobody’s looking, and they don’t want to be the person to remove it.  Perhaps it is a user account management system that sits on a Sun Ultra 5, while heavily locked down, still requires the user administering accounts to be root in order to add users and copy the updated password files.  It could even be a system where you have a team (in-house or outsourced) that spends the majority of their time handling incidents resulting from failing hardware to failing services. 

Except for the first case where it was more superstition, the rest vary from having one critical person that knows how the system works and became indispensable to being very costly to maintain up to and including your best people spend most of their time keeping the business operating.  What happens when it is time for that one person to retire, or you can no longer find the failing part even when using eBay or Craigslist? 

Your options fall somewhere on the scale of: 

  1. Do nothing and maintain the status quo
  2. Transition over to something new (aka lift and shift)
  3. Replace it with something new (refactor)

Each installation is different with its own challenges and constraints. However a cost benefit analysis can still be made with factors such as how much is it costing the organization to maintain the status quo to support it with manpower and downtime when there is an incident to the license fees associated with maintaining the current software stack. When transitioning, there will be the cost to maintain the old system, bring up the new system, and the associated costs to build out the infrastructure required to port things over. There is an additional cost to provide the intermediate transition layer required however what you get in exchange is a smoother transition to the new world.  Lastly replacing the system outright will give you the benefits of a newer system that is supported, but at a much steeper transition cost in business interruption. 

Another way to look at it is that doing nothing is too painful currently. Starting fresh with something new is too disruptive to your day to day operations. Finding that middle layer, when done properly can lead to a smoother transition, but can add much complexity and build up an organization’s technical debt resulting in something far more expensive than just out right replacement.

Surprisingly enough, there are a couple of distributed systems design patterns that come to mind when it comes to helping with this middle case as outlined by Microsoft’s Azure Architecture Guide:

In the Anti-Corruption or Translation Layer, there is a service that is introduced to act as a shim between the Legacy system and the new services that will replace it.  It is the responsibility of this layer to act as an interface and translate the communication between the old legacy system to the new interface that will be used going forward. Another way of using this is to provide an interface that is specific to your business and agnostic to the underlying technology implementing the desired functionality.  One example of this would be a database interface service that provides an abstract querying mechanism regardless of the type of database being talked to whether it is Oracle DB or Microsoft SQL Server.

For the Strangler strategy, this entails having new services replacing the functionality of the old system bit by bit until the old system has been replaced and can be safely decommissioned. If the legacy system being converted is a web based application, then this can be done using a combination of web proxies to route the requests between the two, however care will still need to be taken to ensure the underlying data is either updated once in the case that there is a single source of truth for the data, or properly replicated between both systems until it is time to decommission the legacy system.

More than likely though, the approach that will be taken for the transition will be a combination of the two patterns to ensure a safe and easy transition. One thing to bear in mind is, just like the scaffolding for a new building, these pieces are designed to last just long enough to enable an orderly transition. When left behind, it will substantially increase the complexity of the environment, and result in gaps where nobody knows what is supposed to stay and what is supposed to go.