This article will explain the six common strategies used when discussing cloud migration projects. In 2011, the Gartner group outlined five common migration strategies that provided a great benchmark for discussing and defining a cloud migration strategy in the early days of public cloud adoption. Over time, that strategy has evolved into six definitions, which are commonly used when discussing cloud migration services.
These six definitions are commonly called the six R’s:
Rehost
Replatform
Repurchase
Refactor
Retain
Retire
Every cloud migration is going to be unique and these strategies are not definitive or mutually exclusive. They should be used as guidelines and discussion starters when running a cloud transformation workshop or brainstorming session.
A cloud migration project can easily include elements of all or some of these strategies at various stages:
Rehost, commonly referred to as lift and shift, lifts servers or applications from the current hosting environment and shifts them to an infrastructure in the public cloud. Rehosting and lift and shift is a common strategy for organizations just starting their migration journey. There are significant benefits in running servers on the pay-as-you-go scalable public cloud infrastructure, so it’s a relatively low resistance migration strategy. This is a great strategy for working backwards from a fixed constraint or a hard deadline. In practice, the application or server will be exported via a third-party export tool like VMware vCenter or created as an image that can be exported to a compute instance or a container run on a cloud compute service. Containerized applications make this process a simple exercise since the operating environment isn't included in the container schema. If you are running our monolithic application, rehosting can be a simple way of getting started with cloud services.
Replatforming modifies lift and shift. Replatforming makes optimizations to the application during the migration stage.
Repurchase is often times referred to as drop end shop. This refers to the organization’s decision to move to another product, which sometimes means ending existing licensing and repurposing services on a new platform or service. Examples of this include a CRM system or an industry specific application not designed to run on cloud infrastructures. This is often not necessary with applications written with modern application code since it’s possible to transport the code from one provider to another. The repurchase strategy is often applied when using a proprietary data based platform or proprietary product.
Refactoring or rearchitecting is typically driven by a strong desire to improve services. Reasons for this might be because it is difficult to improve the current environment or it may be a required to improve availability and reliability immediately to meet a specific security or compliance requirements. With refactoring, a lot depends on the nature of service you want to refactor. If it’s not a mission-critical service, it may be possible to re-architect the service during the migration stage. Refactoring is possible during the first phase of migration if you do not have a time constraint, otherwise it’s better done during a later phase.
During a cloud migration process, you may want to retain portions of your IT portfolio. There are some applications you aren’t ready to migrate to the cloud and feel more comfortable keeping them on premise. In this use case, it makes sense to retain aspects of your IT services in its current environment and implement a hybrid or part migration strategy. This also makes sense if current regulatory or constitutional rules require you to store or run aspects of your services or business application on-premise or within specific regions.
Retiring services involves identifying assets and services that can be turned off so the business can focus on services that are widely used and have immediate business value.
These are the six common migration strategies, often referred to as the “Six R’s”.