Cloud Migration Strategies: 1. Rehosting, aka ‘Lift and Shift’

Rehosting (also nicknamed “lift and shift”) is currently the most common cloud migration method and is often the first step in a migration project.

In this post, we'll take a deeper dive into Rehosting, including:

• Rehosting explained;
• Drivers for rehosting;
• Benefits of rehosting;
• Risks of rehosting;
• How to rehost.

The information in this blog post comes from our Migration eBook: What everyone needs to know about migrating applications to the cloud. You can get your copy here.

Rehosting explained

Rehosting treats a workload primarily as a collection of traditional infrastructure resources—servers (i.e. hosts, hence the name), disks and networks—and strives to recreate the same structure using infrastructure-as-a-service (IaaS) analogues in the target cloud platform: EC2 instances, EBS volumes and virtual networks in VPCs.

Rehosting is favoured for its relative ease, speed and low risk compared to other migration strategies like replatforming and refactoring:

• Software on the migrated hosts runs exactly as before, without modification. From its perspective, nothing has changed.
• IaaS offerings are mature and largely equivalent across cloud providers.
• Tools are mature, having their origins in earlier waves of transformation such as the move to virtualised on-prem environments.

This method is likely to be the staple activity in a large legacy migration scenario where the organisation is looking to quickly implement its migration and scale to meet a compelling event such as exiting a datacentre or terminating service from a hosting provider.

Most rehosting can—indeed should—leverage automation, using tools such as AWS Application Discovery Service, AWS Server Migration Service, and AWS Database Migration Service (DMS).

Rehosting is often just the first step in a migration. Once in the cloud, the migrated applications will require more work to exploit the cloud.

Drivers for rehosting

Rehosting is often chosen because it provides the most expedient response to an urgent business need, rather than optimal long-term outcomes. 

Despite the alluring simplicity of rehosting, it solves none of the cloud migration objectives of integrating with higher-order cloud services for better security, resilience, agility and cost reduction.

Common drivers for rehosting:

• Compelling event or pain point
  An immovable event such as the evacuation of a datacentre or termination of a hosting provider.
• Number of migrations over time
  A large number of applications to be migrated in a fixed time period requires a simple, efficient and highly parallel method.
• Available skills
  The available staff are familiar with virtualisation and infrastructure-as-a-service so rehosting matches their skill sets, unlike replatforming and refactoring which demand more skills.
• Appliances
  Applications may be commercial-off-the-shelf (COTS) packages contained in virtual machines.
• Unchanging applications
  Some applications are in use but have no active roadmap or detail architecture, so it is cost efficient to lift-and-shift them rather than go through the expensive analysis.
• Legacy “black box” systems
  Some environments are not actively managed (possibly on purpose) but are still important. It’s easier to lift-and-shift these to limit interruption.

Benefits of Rehosting 

If the organisation is in a rush because of a compelling event or pain point and you have well-understood applications and data on a cloud-compatible infrastructure (highly virtualised and easily accessible), then rehosting can be the fastest migration method.

Organisations may also find that applications are easier to re-architect once they are already running in the cloud. This happens partly because your organisation will have developed better skills to do so, partly because the hard part—migrating the application, data, and traffic—has already been accomplished, and also because it is much simpler to have test environments configured exactly like production.

The business benefits of the rehosting strategy are the limited project cost, effort and complexity compared to replatforming and refactoring. This is a business-decision trade-off: save money and time now to “get to cloud” and deal with more application modernisation later.

An anti-pattern is to rehost a suite of applications without committing to the subsequent time and effort required to modernise those applications, to realise the benefits of the cloud.

Risks of Rehosting 

Rehosting appeals because it is at the simple end of the migration spectrum. But it isn’t without its risks and opportunity costs:

• Migrating brittle processes
  When you migrate an application then you also inherit the operating system, possibly undocumented configurations, and “non-cloud” people and process with it. These are non-cloud, so it has to be clearly understood that no magic will happen in terms of transforming people and processes through rehosting. 
  
• Inefficient and expensive cloud consumption
  Existing applications outside the cloud are often over-provisioned for peak load, a classic non-cloud approach that will need addressing through resizing later to avoid wasting money—but money will be wasted initially, offsetting the perceived savings with “simple rehosting”.
• Rehosted applications are black boxes
  Just copying the applications and data without understanding what’s in them means you are pulling everything into the cloud, including insecure and brittle configuration.
• Unbudgeted/unplanned post-migration “tidy up and fixes”
  There are always post-rehosting activities to take care of: these cost money, time and effort. Not doing them will also cost money (e.g. over-provisioned resources).
• Ingest known and unknown problems
  If the application has a problem outside the cloud, known or unknown, it will likely bring that problem to the cloud. Fixing technical debt is a big plus of more advanced migration

How to rehost

As with all the migration strategies, work closely with all the stakeholders including finance, governance, application teams, operations and security.

There are excellent tools available to automate much of the rehosting process. These include:

• AWS Migration Hub: a single place to discover your existing servers, plan migrations, and track the status of each application migration.
• AWS Application Discovery Service: to gather information about on-prem datacentres, to plan the migration.
• AWS Server Migration Service: to migrate thousands of on-prem workloads; to automate, schedule, and track replication of live server volumes.
• AWS Database Migration Service: to migrate databases to AWS quickly and securely.

The AWS Migration Hub also helps you to right-size your compute resources, based on the on-prem usage, to lower your cloud costs.

The Database Migration Service is an excellent tool for moving data between database, including when migrating data between different database engines. For example, you can migrate data from SQL Server to MySQL. When using the same engine and version of database on-prem and in the cloud, the native database replication and migration tools may well be a simpler option—particularly if there is in-house experience with using these tools.

A cloud migration will impact many processes and operational runbooks, such as for disaster recovery or responding to server failures. These will need to be addressed, potentially on an application-by-application basis.

Much of the required time for cloud migrations can be non-technical: understanding how the migration of an application will impact other people and processes, and updating other systems that may be impacted by the migration.

It is common for organisations to arrange a security pen-test for the cloud environment. This can often identify security issues that also existed on-prem, as well as new issues in the cloud configuration. The extent to which these are addressed can lead to some aspects of a replatform.

Migration Strategies Blog Series

This is post 2 of our Migration Strategies blog series. We're posting new blogs daily, each exploring a different migration strategy in more depth.

You can get a head start by downloading a copy of our Migration eBook: "What everyone needs to know about migrating apps to the cloud", which explores each of these approaches in detail.

Working with a partner like Cloudsoft

For many firms, deep knowledge of cloud platforms is not a core competency central to their mission. For them, the sheer breadth of cloud services and the nuances of different migration approaches can be hard to untangle. In such cases, working with a cloud partner can de-risk the options and accelerate the firm’s cloud adoption strategy.

Cloudsoft partners with organisations at all stages of the cloud journey: lending crucial strategy advice through the assess and mobilise phases, guiding the selection of migration methods for different workloads, and assisting with the technical planning and implementation of the migration itself. Staffed with experienced application developers, we also frequently continue to work with customers post-migration, refactoring and modernising the migrated workloads.