Cloud Migration Real World Observations - The Re-factor and Re-platform of the 7Rs

Many people are familiar with the 7 Rs in cloud migrations – the seven cloud migration strategies advocated by AWS and other cloud service providers:

• Rehost
• Replatform
• Refactor
• Repurchase
• Retain
• Relocate
• Retire

In this blog piece, I would like to share some real-world customer considerations on choosing the Refactor and/or Replatform strategies. 

To give a general definition, the Replatform strategy is the migration approach in which some tweaks (optimisations and modernisation) are performed during the migration to the cloud but the core architecture of the workloads stays. Some examples that given by AWS are migrating server based databases to Amazon RDS, or moving an application to Amazon Elastic Beanstalk – both are cases of moving to fully managed cloud native services. The Refactor strategy, on the other hand, is sometimes referred to as Rearchitect, where more changes are made to the application architecture than Replatform, typically increasing agility and business continuity at the same time. 

There are no black and white demarcation lines between Replatform and Refactor. Often, a level of refactoring is involved in replatform approaches. AWS suggests looking into the following for the degree of changes:

• Is the workload a strategic, revenue-generating one? If so, it is likely that the approach needs to be more careful, with broader considerations and more gate checking? These may make it lean more towards the higher degree change of the Refactor approach.
• How is the operational complexity? Consider this together with the rate of change, whether the application architecture and code are legacy, the funding available, and the timeframe requirement. E.g., lower operational complexity would imply a lesser change approach, while the existence of legacy application code / architecture would suggest that greater changes of refactoring are needed (with the argument that it would be unwise/not suitable to continue the legacy structure in the cloud)

The focus of this piece is not to differentiate between Replatform and Refactor. Rather, I would like to discuss some real world observations on why some customers decide on taking the Replatform or Refactor strategy, instead of Rehost (‘lift-and-shift’) or other approaches. 

Database migration is one of the common drivers. I have had government customers in various Australian states using the cloud migration opportunities to migrate from commercial databases to open-source databases, and from in house server-based databases to cloud managed database services.             

Database licensing cost-saving plays a part in considering whether to choose Replatform/Refactor approaches. Enterprise level, large scale commercial databases come with significant licensing costs. AWS has case studies showing that moving and modernising from such commercial databases to open source cloud database engines may result in 90% cost savings. 

Moving from server based databases to cloud managed databases is often an even bigger consideration. Operating and maintenance complexity reduction – by moving to cloud managed databases - is valued highly by enterprise and government customers. Improved reliability, high availability and reduced or eliminated downtime are viewed favourably as well. Then there are additional benefits of the ease of performance scaling adjustments.

Tools such as AWS DMS (Database Migration Services) and AWS SCT (Schema Conversation Tool) can help with database migrations. I have also had scenarios where a more manual database migration method, such as manual schema conversion, was used with some customers. 

In a nutshell, databases are what/where organisations may choose to make changes while considering the migration to cloud. 

Windows Servers are another common aspect when considering a Refactor / Replatform strategy. Hang on a second, some may ask, wouldn’t it be easier for Windows Servers to do rehosting in migration - after all, they are mature operating systems?

Well, there are other factors influencing the decisions. The customer’s Windows Server fleet may be on outdated Windows versions, so version updates were always going to be part of the server refresh, going to cloud or not. 

Then depending on the licensing agreement, as well as the applications, a strategy will be formed on whether to go for:

• license-included cloud compute (the cloud compute has software license included, so you move to such compute without bringing your own license for that software), or
• leveraging the possible entitlement of existing licensing coverage (Bringing Your Own License - BYOL) 

Replatform or Refactor approach is often favoured when the License-Included cloud compute path is chosen – along the logical thinking line of ‘we are upgrading the servers anyway, so why don’t we use the same opportunity to make more optimisations to the servers and applications so it will be easier down the track.’ Security can also be another consideration.

It is also common that customers decide to migrate to cloud at a time that is synchronised with a major version upgrade of their strategic application(s). Such application version upgrades typically come with a revised prerequisite set on the server’s operating system – such as the version of the Windows Server, .NET version, a number of specific Windows Features, or a total change of OS…etc, that are different to what specified previously. Logically this leads more towards the Refactor strategy. 

In recent years, the journey to Infrastructure as Code (IaC) by almost all organisations has also been influencing the cloud migration strategy that is taken. IaC enables automation of infrastructure which becomes particularly feasible in cloud, comparing to on premises, so this is regarded as one of the key benefits to going cloud. Not surprisingly, this is something people tend to do when planning for cloud migrations. A few primary benefits that IaC brings may include:

• Significantly improve operations productivity
• Safely and securely provision resources at enterprise scale
• Eliminate manual errors
• Increase release  / go to market speeds by multiple folds
• Drive innovation

With all the benefits that IaC can enable, it does need to tap into the life cycle events of cloud resources – the baking of images, the provisioning of not just the subject resources but also the corresponding, associated resources, and beyond these dimensions, the participation of the CI/CD (Continuous Integration / Continuous Deployment ) process. E.g., infrastructure automation being intelligently integrated with the software development process. 

As we can realise, all these will involve innovations, improvements and changes to the ways that infrastructure is being done -  including but not limited to things like how servers are being automatically built dynamically, how appropriate roles can be assumed so the servers can automatically fetch the updated code, correct parameters and environment variables from the secure, encrypted storage, under the governance of the Least Privilege Principle (that only the permissions required to complete a task at the time is granted). When these are achieved together with a cloud migration, the approach to be considered more often than not will be Refactor. 

In previous paragraphs, we discussed a few real world observations on cloud migration strategies. Replatform and Refactor are definitely being adopted in cloud migrations more than before and this trend is likely to continue. However, there are still plenty of scenarios wherein other approaches, such as Rehost, serve the most immediate business benefits at a given time. When there is a hard timeline for a data centre exit (such as due to the expiration of a lease) or a mandatory hardware refresh, Rehost can provide clear, concrete TCO (Total Cost of Ownership) results in a business case analysis, as well as offer certainty through a likely shortened migration project duration. Then once the workloads are in the cloud, further modernisation projects can unlock additional benefits. Composite approaches are also doable, where the majority (for example 80%) of the on-premises servers follow the Rehost path first, helping to realise the primary TCO benefits in the cloud migration, before the final 20% leverages the Replatform / Refactor approach.    

                                                                                                                                             -- Simon Wang