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:
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 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:
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.
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:
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.
Rehosting appeals because it is at the simple end of the migration spectrum. But it isn’t without its risks and opportunity costs:
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:
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.
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.
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.