Glossary
Lift and shift
Also: Rehosting
A system moves to the cloud almost unchanged, without adapting to cloud characteristics.
The route is fast and low risk because nothing about the application changes. It is the right choice when a data centre contract runs out or hardware is at end of life and the date is not negotiable.
What it does not deliver are the benefits of the cloud. A fixed machine that stood before stands in AWS afterwards, often at a higher price.
The reason for the higher cost is structural. In your own data centre the server is paid for, nobody cares about utilization, and at night it simply idles. In AWS every hour is billed, the empty ones included, and on top you pay for a flexibility an unchanged application gets nothing from. Then there is traffic that used to be free inside your own network and now appears on the bill as egress.
That is exactly why lift and shift is not a destination but a stage. The benefit arrives in the second stage: size the machines to actual demand, switch off non-production at night, managed services instead of self-run databases, object storage instead of large block volumes, and only after that commitments on the then stable baseline consumption.
The order matters. Buying reserved instances or savings plans straight after the move ties you for one to three years to the machine sizes that came out of the data centre, and takes away the largest lever you have. Optimize first, commit second.
A second point that is often missing from the planning: the move is the only moment when everything is being touched anyway. If no foundation is built along the way, meaning account structure, logging, permissions and tags for cost allocation, the new environment ends up as disorderly as the old one, only more expensive.
There is also the case where lift and shift is the right answer permanently: a system that has to run for another three years, gets switched off afterwards and receives no changes in between. Then every optimization is an investment with no return. That judgement should be written down though, because systems with a shutdown date have a habit of outliving it.
How you notice it
- A data centre contract is running out.
- The hardware is at the end of its life.
- There is no time for a rebuild and no budget for downtime.
- The application receives no meaningful changes any more.
Not to be confused with
- Replatforming
- A move with targeted adjustments, without rebuilding the application: a managed database instead of your own, object storage instead of a file server. The usual second step.
- Refactoring / rearchitecting
- The application is rebuilt to use cloud characteristics. The most expensive route with the largest lever, worthwhile for the few systems that are still actively developed.
- Repurchase
- The system is replaced by an off-the-shelf product. Often the cheapest answer for standard functions such as mail, ticketing or time tracking.
- Retire
- Do not migrate, switch off. Almost every inventory turns up systems without users, and they are the cheapest item of the migration.
When it fits
- A data centre contract or maintenance period ends on a fixed date.
- There is no time for a rebuild and no budget for downtime.
- The application is no longer actively developed.
- As a deliberately planned first stage with a date for stage two.
When it does not
- When the system is actively developed and could use cloud characteristics.
- When the migration is justified by cost saving alone: unchanged, it gets more expensive.
- When no foundation is built and the disorder moves along with it.
- For systems running without users: those belong switched off, not moved.
How to approach it
- Take inventory and sort outWhat runs, who uses it, what depends on it. Every system that does not move is the cheapest part of the project.
- Foundation before the first serverAccounts, networking, permissions, logging, tags. The move is the only moment when that comes along without extra effort.
- Move to demand, not to inventoryMeasure actual utilization over several weeks and pick the machine size from that. Taking it over one to one cements the oversizing.
- Move in wavesStart with one uncritical system, completely, including the way back and the days after. The first wave builds the procedure, not the revenue.
- Schedule stage two before stage one startsWith a date and an owner, in the same decision paper. Without a date it does not happen.
- Commitments lastOnly once sizes and consumption are stable after the optimization. Terms bought earlier lock in the old machine sizes.
Frequently asked
Does lift and shift cost more?
Usually yes, at first. A fixed machine costs more in AWS than in your own data centre because you pay for flexibility you are not using. On top comes egress traffic that used to be free inside your own network. That is why the second stage belongs in the plan before the first one starts.
What belongs in the second stage?
In this order: size machines to measured demand, switch off non-production outside working hours, replace self-run databases with managed ones, put data into the right storage class, route traffic through endpoints instead of NAT. Commitments come last, once consumption is stable.
Should you optimize during the move?
Only the machine size, and that is more a measurement than a rebuild. Everything else widens the time window and mixes two sources of error: when something does not work after the move, you want to know whether it was the move or the change.
How long may the intermediate stage last?
Six months is a usable upper limit. After that the environment has settled, new dependencies have grown, and every change becomes a project again. Wait longer and you are no longer optimizing an intermediate stage, you are optimizing a new legacy system.