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:
- Part 1 – A Practical Guide to Understanding the 6Rs for Migrating to AWS
- Part 2 – Migrating to AWS Method 1 – Repurchasing, aka Drop-and-Shop
- Part 3 – Migrating to AWS Method 2 – Rehosting, aka Lift-and-Shift
- Part 4 – Migrating to AWS Method 3 – Replatforming, aka Lift-and-Shape
- Part 5 – Migrating to AWS Method 4 – Refactoring, aka Cloud Native
In this post we explore the Rehosting migration method in the same consistent manner as the other three methods using the following outline:
- Defining what Rehosting is
- Drivers of Rehosting
- Benefits of Rehosting
- Risks of Rehosting
- How to Rehost
- What you need to Rehost
- Rehosting Summary and Next Steps
If you want to access the whole series in one sitting, you can go get the Cloudsoft white paper:
1 Defining what Rehosting is
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.
2 Drivers for Rehosting
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:
2.1 Large number of migrations over time
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.
2.2 Compelling event or pain point
A common compelling event is the immediate evacuation of a datacenter or hosting provider.
2.3 Mono-perspective Rehosting obsessives
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.
2.4 Virtualization and IaaS skillset
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).
2.5 Applications are black boxes or appliances
Applications may be Commercial Off The Shelf (COTS) packages contained in virtual machines.
2.6 Unchanging application
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.
2.7 Test environments
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!
3 Benefits of Rehosting
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.
Summary of benefits to rehosting
- Speed of migration
- Reduced risk (simplicity)
- Broad AWS partner and tool ecosystem
- Application, hypervisor and hardware agnostic
- Can be highly automated with limited or no downtime
- Imports configuration and scripts if these are not documented/hard to reverse engineer
4 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.
4.1 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 process through Rehosting.
4.2 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”
4.3 Rehosted applications are black boxes
Just copying the applications and data without understanding what’s in them means you are pulling everything into AWS, including malware or insecure configurations.
4.4 Unbudgeted/planned post- Rehosting “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)
4.5 Ingest known and unknown problems
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.
5 How to Rehost
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.
- Decide on the Rehosting process for this application, using a combination of AWS Server Migration Service, Data Migration Service and other tools.
- Ensure your staff (or Partner) are experts in these tools and methods.
- Plan the Rehosting, allocating time and effort in the plan and understanding any potential service overlaps and outages.
- Using the preplanned tools, Rehost the application and its data to the pre-determined AWS account.
- Confirm the integrity of the migrated applications and data using techniques such as checksums as well as “eyeballing” the results.
- Test and rollback if needed.
6 What you need to Rehost
As a Rehost is a simple, well-known process compared to Replatform and Refactor, it has a simple shape:
- Tool costs (free from AWS)
- Data moving costs (free to inject in AWS, but maybe bandwidth or other transport costs)
- Labour costs – budget £500-£800/day in the UK for an independent freelancer, but a qualified
- Partners may cost less or more than doing it yourself or via a freelancer, but they should have a consistent and reliable professional service.
- Estimate AWS costs before Rehosting with AWS Simple Calculator
- AWS Migration Hub
- AWS Application Discovery Service
- AWS Server Migration Service
- AWS Database Migration Service
This is always variable depending on the application, but the time components are normally consistent across migrations:
- Time to set up and prepare the target AWS account ready for Rehosting
- Time to copy applications and data to AWS (multiple methods, different speeds and costs)
- Time to verify the migrated applications and data
- Time to reconfigure the migrated applications and “create the stack”
- Testing and go live, don’t forget backout.
7 Summary of Rehosting and Next Steps
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.
- AWS Cloud Migration home page
- AWS Migration Hub to track migrations
- AWS Discovery Service to map your application landscape
- AWS Server Migration Service to perform server Rehosting
- AWS Database Migration Service to perform database Rehosting
- reInvent 2017: An Overview of Best Practices for Large-Scale Migrations (ENT212)