Rehosting – aka Lift and Shift – is the relatively simple mechanism of copying application and data “bits” from outside AWS, into AWS. A classic example is copying virtual machines (that contain applications and data) and storage files (just data) across the internet or via some other mechanism, into a pre-deployed target AWS account.
But beware: just like the movie, The Fly, you will probably be transporting more than you think into your cloud, and the results might be not what you expect.
This is the third in a five-part series covering the practical realities of migrating applications to AWS:
In this post we explore the Rehosting migration method in the same consistent manner as the other three methods using the following outline:
If you want to access the whole series in one sitting, you can go get the Cloudsoft white paper:
Rehosting is the (currently) the most common migration method (40% of all migrations according to Forrester) due to its relative simplicity and speed compared to Replatforming and Refactoring. This method is the staple activity in a large legacy migration scenario where the organization is looking to quickly implement its migration and scale to meet a compelling event such as evacuating a datacenter or hosting provider.
It is also the simplest of the migration methods because, in essence, it is just “copying and pasting bits” from a non-cloud source to AWS. Of course, there is more to it, but that is the central tenet of Rehosting.
Most Rehosting can – and should – be automated with tools such as AWS Server Migration Service (SMS) although you may prefer to do this manually as you learn how to lift-and-shift your legacy systems to AWS.
Often Rehosting is chosen because it is the most immediately convenient in response to a pain point or compelling event, rather than it being the “best of breed” migration method (none of the methods is “best of breed”, there’s only the “right tool for the job”.)
Common examples of drivers for Rehosting are:
If it’s simple, quick and cheap and you have a lot to do: of course Rehosting is going to be very favourable. That is, IF, you have factored into the plan and budget all of the post-migration work to integrate into AWS. And the fact that you’ve also lifted and shifted non-cloud tools, processes and people into AWS.
A common compelling event is the immediate evacuation of a datacenter or hosting provider.
To a hammer everything is a nail. To a Rehosting “specialist” everything should be lifted-and-shifted: especially vendors who sell lift-and-shift tooling.
The available staff are familiar with virtualization and infrastructure-as-a-service so Rehosting matches their skill sets (whereas Replatforming and Refactoring need more skills).
Applications may be Commercial Off The Shelf (COTS) packages contained in virtual machines.
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 thru expensive analysis.
Some environments are not well managed (on purpose) but are still important. It’s easier to lift-and-shift these to limit interruption.
However, the simplicity of Rehosting means it solves none of the cloud migration objectives of integrating with higher-order cloud services for better security, resilience, agility and cost reduction.
It’s a rule-of-thumb with cloud migrations that the more you put into the migration, the more benefits you get. But it costs you time, cost and effort to get there, and sometimes you are blessed with none of these!
If the organization 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 virtualized and easily accessible), then Rehosting can be the initially fastest and cheapest migration method.
Organizations may also find that applications are easier to re-architect once they are already running in AWS. This happens partly because your organization will have developed better skills to do so and partly because the hard part – migrating the application, data, and traffic – has already been accomplished.
The business benefits of Rehosting are the limited 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 cloud integrations later.
Rehosting appeals because it is at the simple end of the migration spectrum. But it isn’t without its risks and opportunity costs.
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 process through Rehosting.
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”
Just copying the applications and data without understanding what’s in them means you are pulling everything into AWS, including malware or insecure configurations.
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)
If the application has a problem outside the cloud, known or unknown, it will likely problems bring that problem to AWS. Retiring technical debt is a big plus of more advanced migration methods like Replatforming and Refactoring, or drop-and-shop technique of Repurchasing.
The steps to migrate an application by rehosting are as follows. If automation is used it is a good sign: it means the application and all its components are well understood and easily migratable. If automation is not possible, it suggests the application is not well understood and possibly fragile, leading to a risky migration and a brittle end product.
As a Rehost is a simple, well-known process compared to Replatform and Refactor, it has a simple shape:
This is always variable depending on the application, but the time components are normally consistent across migrations:
Most migration plans will have some Rehosting in them, but this method shouldn’t be applied uniformly and unthinkingly across the whole application landscape. It’s an awesome tool for the right job, but once your applications and data are in AWS there is still work to be done to integrate it, disentangle from the also migrated non-cloud tools, processes and people. It can be like the movie the fly when you transport something unsuspected with you into AWS.
Our advice to everyone considering Rehosting is to get some education on the following resources, and choose a partner like Cloudsoft to help you where needed.