Application Migration Strategies      The 3 R's

The 3 R’s 

Back in 2011, Gartner coined the phrase "the 5Rs", for outlining different cloud migration strategies. More recently this has evolved into the “7R’s” as presented in this AWS blog.

At Codurance we feel that the vast majority of cloud migrations tend to adopt one of just three of these strategies. Each of these strategies presents a different risk appetite for the business and focuses on different timescales and preparedness of the business. 

These 3 R’s are listed below. 

1. Rehosting 

Rehosting (often more commonly referred to as 'lift and shift') generally entails migrating software applications to the cloud with very little (if any) architectural or design changes being made. In effect moving from on-premise compute such as virtual machines to virtual machines hosted by a cloud provider. The organisation then still maintains all the software and services on that virtual machine in the same way as they did previously on-premise.

This strategy is often the best choice when an organisation has a low appetite for a risk. It enables many operations and ways of working to continue 'as is' without the need for widespread changes. Take, for instance, the situation of an organisation needing to migrate infrastructure to the cloud within a tight deadline, imposed by wider business constraints. Rehosting allows for a quick move to the cloud, allowing BAU to continue. While this strategy doesn't truly allow an organisation to leverage the full power of a cloud platform, it does still have benefits, if the business objectives align. 

A practical example would be the migration of a two tier application hosted in a data center to respective EC2 instance on AWS.

2. Replatforming 

What degree of ‘Lift and shift’ does a business feel comfortable with? 

Similar to rehosting, re-platforming is the initial shift to the cloud but the change here is that an organisation is starting to make some changes to its technical landscape, albeit still not meaningfully changing the architecture. Often this involves a slight embrace of cloud-native technologies in the shape of managed services. So, databases might be switched out to the cloud provider's database managed service or an on-premise log aggregation component might be replaced by a managed service for analytics and reporting. When the risk appetite is slightly higher, this is the strategy businesses tend to adopt. 

Many of these cloud native, managed services are inherently elastic by design. This means that by adopting them organisations can start to reap some of these benefits such as auto scalability to handle peaks and troughs in traffic.

Following the same two tier application example, the database virtual machine could be replaced by a managed service such as AWS RDS when migrating to the cloud.

When deciding on which cloud migration strategy to adopt, there are a few factors to consider. For example, perhaps your organisation needs to realise benefits from the cloud within a relatively short period of time. Or, perhaps maintenance costs need to be reduced. In which case, rehosting or replatform would likely be the most appropriate strategy to follow.

Adopting either of the first two R’s - Replatforming, or Rehosting - allows the organisation to see the benefits quickly. Whereas, the 3rd R - Refactoring/Re-articting - as mentioned below, is for businesses that have a cloud migration technical vision. 

3. Refactoring / Re-architecting (and a little bit of repurchasing) 

‘How can businesses benefit from moving legacy applications to the cloud’ references the importance of identifying the business driver(s) behind a cloud migration. These business drivers should then form the basis of a technical vision to ensure alignment with business goals. Doing so, allows organisations to specify the qualities they need technical architectures to exhibit.  Capturing these qualities in the shape of metrics, allows mechanisms to be put in place to ensure that a technical architecture is meeting the outcomes intended.

A ‘lift and shift’ approach, similar to rehosting, often offers a quicker route to migrating to the cloud and so allows fast value realisation as a result, in some areas. For example, reducing maintenance cost of infrastructure. 

However, a rehosting strategy doesn't usually take into account future evolution of an Organisation and whether the current technology landscape supports that. 

This is where the re-architecting strategy comes into play. This is often more future-looking, ensuring that the cloud platform is designed in such a way that it can support evolution on the organisation without the need for wholesale re-designs.

Re-architecting in this way is going to involve changing technology, and systems during this process. The questions that need to be focused, is how does this look in the future, what objectives are being met? For example, if a business wishes to tap into a new market or release multiple new service lines, these rely heavily on the structure and therefore need to be factored into the technical vision for this strategy. Re-Architecting is a more strategic approach for competitive advantages. 

Having a re-architecture strategy however, relies on being a company-wide objective. Moving to the cloud in this way can’t be done in silo, and often factors on having a business purpose. What's the purpose of being in the cloud? And, what are the benefits and measurables you want to achieve? What additional services do you hope to achieve? Visibility or monitoring, lower bars to entry, large data benefits. All of these benefits rely on moving to the cloud strategically. 

Understanding how the business is currently technically performing is also important. If on-premise isn’t working, moving to the cloud won’t be an instant fix. If the organisation is struggling to get a good handle on how it’s managing its on-premise software, it’s likely this will also happen in the cloud. At this point, it’s understanding the road map rather than making the move. 

Updating with a large scale re-architecture strategy

If the technical roadmap of an established business is pointing towards a large-scale re-architecting, it’s a sign something has gone wrong. In the ideal scenario, an organisation would want to expand their services and gradually grow, evolving the platform. However, this is not always the case. If platforms haven’t changed or evolved over the last 5-10 years, they’re often not fit for purpose, halting the possibility of fast responses to the marketplace. 

By re-architecting the organisation wants the system to do something it’s currently unable to do. For example, can it not create a good audit? Can the business monitor performance or security? 

There is a step needed to evaluate these large systems, to understand the current mapping, and evaluate the current services the cloud offers. In this instant business can complete a well-architected review, which from an application perspective reviews how the platform needs to be reorganised, and understand how the current requirements are mapped to the cloud system. Without mapping this out, it is hard to see the full benefits that can be achieved using cloud providers. 

How does Repurchasing fit into this strategy? 

The originally coined 6 R’s mentions repurchasing as its own strategy. However, in this instance it’s been added with refactoring /re-architecting because it sits within the long-term business objectives. It’s about changing how a business interacts with a tool to save on business effort, which doesn’t bring value back to the business. It has no competitive advantage. Take for example Salesforce, for an organisation, by moving to a cloud solution or SaaS it enables the focus to be on pure business value rather than building cost, or technical debt on something that the business isn’t focused on. 

What strategy is right for you? 

When working out the right strategy for your business, it’s important to remember that the business isn’t stuck with just one of these strategies. The Rehosting strategy can often act as a nice first step within an organisation's much wider cloud adoption journey. The cloud migration strategy can then be expanded when the business feels ready, for example, applications can be modernised.

Learn more about the benefit of Software Modernisation as part of a business Cloud Migration Strategy in: Understanding the benefits of Incorporating modernisation into an application migration strategy