"Lift and shift" is half an insult in many rooms. It sounds like laziness: take the old application, put it on a machine at a provider, done, and the cloud is apparently not to blame when nothing is better afterwards.
The reputation is undeserved, and the alternative has its own way of failing. Rebuilding every application while moving it combines two projects that are hard enough apart, and at the first failure nobody can tell whether the move or the rebuild caused it.
This article sorts the two routes out: what lift and shift really means, what has to change even there, when replatforming pays off, and why the bill after a pure move is regularly higher than before.
The decision is usually made too early
In most projects the answer is settled before anybody has looked at the application. It depends on who is in the room: if the push comes from operations, things get moved; if it comes from engineering, things get rebuilt.
Both answers can be right, and neither is right across the board. The decision is not one for the whole system, it is one per building block. An application made of a web server, a database, a search index, a file store and twelve cron jobs has five decisions, not one, and in practice they come out differently.
The only question that really drives the decision is this: what deadline is there, and what happens if it slips? Anybody leaving a data centre at the end of the year has a different decision to make than somebody who merely thinks the cloud is a good idea.
What lift and shift actually is
Lift and shift means the application runs after the move on the same kind of machine, with the same operating system, the same runtime and the same architecture as before. What changes is the location and the way the machine comes into being.
What it does not mean is that nothing is touched. That misunderstanding is exactly what produces projects that get stuck in operations after the move. Three things always change, and planning without them is planning the move wrongly.
Network and access rights. In your own data centre the network is flat and everything reaches everything. In the cloud there is a VPC, subnets, security groups and a permission system that authorizes every machine and every service individually. That is not a rebuild of the application and it is a work package of its own.
Individual machines failing. A virtual machine in the cloud can disappear without warning, and that is normal. Every application holding state on its own disk has to change something here: sessions, uploaded files, local caches.
How the machine comes into being. A server somebody clicked together in a console is the same problem in the cloud as in the data centre, only more expensive. The move is the one moment when that can be changed without extra effort, because the machine is being created anyway.
Those three points are why an honest lift and shift is not a weekend. It is still considerably less than a rebuild.
When replatforming pays off
Replatforming means swapping a building block for a managed service without rewriting the application. It pays off when the block produces operational work nobody enjoys carrying and the interface stays the same.
Three cases are almost always worth it, and all three share the property that only a connection string changes for the application code.
The database onto a managed service. Backups, failover, minor versions, monitoring: that is the operational load that depends on one person in the data centre and is in the price in the cloud. The application code notices nothing, as long as the major version stays the same. This is also where the most common surprise of the whole move sits, because an older version is often no longer offered at all, which forces the jump.
Files into object storage. A directory of uploaded files is the reason many applications cannot run on two machines. The change is manageable, because it sits in one place in the code, and it solves the state problem from above at the same time.
The queue and background processing. Where a cron job used to check every five minutes whether there is something to do, there is a queue afterwards. That is the block with the largest difference in operations, because it absorbs load spikes and makes retries possible.
What does not belong on that list: splitting the application into services, moving to serverless, and changing the framework. Those are rebuilds, not replatforming, and they do not belong in the same period as a move.
The step that turns a lifted server into an application you can run more than one of is covered in Sessions, uploads, state.
The cost trap: one to one is more expensive
The sentence nobody wants to hear and that is almost always true: an application that moves to the cloud unchanged costs more there than before.
The reason is not pricing policy but a confusion of utilization with capacity. In your own data centre a server is bought. Whether it runs at ten or eighty per cent changes nothing about the cost, which is why nobody ever sized it tightly. In the cloud that very sizing is paid for every month.
Two items come on top that did not exist before. Traffic leaving the cloud costs money, in the data centre it was part of the line. And fast storage costs a multiple of slow storage, while in your own rack both were the same disk.
In practice that means the first bill after the move is not a mistake, it is an honest picture of what nobody measured before. It drops afterwards, exactly to the degree that sizing is brought in line with actual load. What such a curve looks like over twelve months I have written up elsewhere.
What follows for planning is inconvenient and important: anybody justifying the move with savings is justifying it with a result that only appears after the move, and has to say so.
The order I recommend
From all of that follows an order that looks slower and is faster, because it keeps fault-finding short.
- Move, as identically as possible. Same versions, same architecture, only the three unavoidable changes above. The goal is a state where the application runs in two places and you can switch.
- Turn observation on before switching. Without measurements from the new environment, the next step is guesswork.
- Switch, with a way back, and keep it open for a week. The way back is the difference between a migration and an adventure.
- Only then take on sizing. Now there are real load figures, and now the bill drops.
- After that, replatforming, one block at a time. Database, files, queue. Every step shippable and reversible on its own.
The step everybody wants to skip is the fourth. It has the least technical appeal and the highest return per unit of effort of all five.
How you notice you want too much at once
Three sentences from project meetings that reliably indicate move and rebuild have been mixed.
"While we are at it." That sentence opens every extension of a migration project and sounds reasonable every time. It is why six weeks become nine months. The answer to it is not no, it is a date: afterwards, as its own step.
"We cannot roll that back." The moment a step has no way back, it is no longer a migration step. It belongs after the switch, not before it.
"We do not know whether that is the cloud." That is the bill for mixed projects. Moving and rebuilding at the same time leaves two suspects for every failure and no way to separate them.
What the destination of this route looks like in practice is covered in A PHP monolith on ECS Fargate.
The deadline that forces the decision
Finally the case that comes up most often in practice: the data centre contract runs out, the date is fixed, and it is not negotiable.
Then the decision has already been made, and it is lift and shift. Not because it is better, but because a rebuild under deadline pressure produces the kind of decision you regret two years later. What helps in that situation is a clean line: by the deadline, whatever has to move moves, and everything else gets a date after it.
And if no deadline exists, the most honest question is whether the move has to happen now at all. An application running stably on its own hardware, whose operation wakes nobody at night, has no urgent reason to change address. How an AWS migration works when it is due is on its own page, including the question of when it is not.
This article belongs to a series about systems that already exist. The retrospective orders every article in it by situation.
