Lift and Shift or Rebuild, and How to Decide

For most systems in most businesses, moving them across as they are is the right first step. It is faster, it is cheaper to plan, it changes one thing at a time, and it is the only approach with a believable way back if the day goes badly.

Rebuilding earns its place on a small number of systems: the ones whose load varies wildly, the ones already being changed every month, and the ones where a licence or one piece of the design is the reason the running cost is high. Everything else is a candidate for moving first and improving later.

The uncomfortable half of that answer is what happens after the move. Lifting a system across unchanged means you now pay cloud prices for a workload shaped like a server: switched on all the time, sized for a peak that happens twice a year, licensed by processor, and patched by you. Renting that shape of workload does not make it cheaper, it only moves it onto somebody else's hardware.

So the real decision is which systems get a second step, when, and out of whose budget.

A date you can hold. If a lease is ending or a hardware support contract is running out, moving things unchanged is the only approach with a delivery date anybody should trust. Rebuilds slip. Half the requirements get rediscovered in the middle, and no estimate survives that.

One variable at a time. When a system is moved unchanged and then misbehaves, the list of suspects is short: the network, the storage speed, the machine size, the name resolution. When a system is rebuilt and moved in the same step, everything is a suspect, and the argument about whether the fault is in the new code or the new platform can run for weeks while the business waits.

A way back that is simple to describe. The old environment is still there, switched off rather than dismantled, and going back means pointing traffic at it again. Anyone who has run a cutover at midnight knows what that is worth. A rebuild has no equivalent, because the old system knows nothing about what happened in the new one.

And it buys learning. Your team gets a working environment, real bills, real monitoring and real access problems to solve, on a workload they already understand. That is a far better place to start rebuilding from than a whiteboard.

An always on machine sized for peak is the most expensive way to run anything in the cloud. On your own hardware that waste was already paid for and invisible. On rented hardware it appears on an invoice every month, and that is why cost conversations follow migrations around.

Licences behave differently too. Software charged by processor core or by server can cost noticeably more when the machine is oversized, and some vendors price differently depending on where the software runs and whether the underlying hardware is shared. Read those terms before sizing anything. This is one of the few places where a licensing question genuinely changes the architecture.

The operational work stays with you. Patching, backups, tuning, the storage that keeps filling, the certificate that expires on a Sunday. A managed database or a managed file service takes that away. A machine you lifted across does not, and the team who hoped the move would give them their evenings back will notice.

None of that makes lifting and shifting wrong. It makes it a first step with a bill attached, and that bill is what funds the second step if you let it.

When the load is spiky. A system that sits idle most of the time and goes very busy for a few hours is the case cloud pricing was designed for, and you only collect that benefit if the thing can actually shrink when it is quiet. A ticketing system that sells out an event, a payroll run, a seasonal retail site: each of those can pay for a rebuild in running cost alone.

When the code is already changing every month. If a team is shipping to it regularly, the rebuild is not a separate project competing for funding. It becomes a series of changes to work they are doing anyway, and that is how these things get finished rather than proposed.

When one component is the whole problem. Sometimes the answer is not to rewrite an application but to lift one piece out of it. Move the file storage to object storage. Move the scheduled jobs off the machine that also serves users. Put the heavy reporting queries on a replica. Each of those is small, reversible, and removes a real constraint.

And when the alternative is moving something that is already failing. If a system falls over most months, lifting it into a new environment gives you the same system falling over in a place where fewer people know how to fix it. Repair it, replace it, or leave it where it is until you can do one of the two.

In practice, most successful moves are neither extreme. The application goes across roughly as it is, and one or two things underneath it get swapped for managed equivalents on the way. The database becomes a managed database. The shared drive becomes object storage. The scheduled task becomes a scheduled job on the platform.

That works because those swaps are contained. An application talks to its database through a connection string, and if the new database speaks the same language, the change is small and testable in an afternoon. The same is true of file storage in an application that already writes through a single library.

It stops working when the swap reaches into the code. Applications that use vendor specific database features, or that write files to a local path in four hundred places, will fight you. Find that out during the assessment by reading the code rather than by asking the vendor, because the vendor answers about the supported configuration and your copy has been modified.

Decide these one component at a time and write the reason beside each decision. A year from now somebody will ask why the reporting database was left as a plain machine, and the answer should not depend on who is still in the building.

Do this per system rather than as a company wide policy, and use questions with factual answers rather than opinions. How often does this code change. Is the vendor still supporting this version. Does the load vary during the day or across the year. What does the licence cost and how is it counted. How much of the running cost is the machine and how much is the software. Would anybody notice if it stopped for a morning.

Two answers do most of the sorting for you. A system that never changes and runs at a steady level should be moved as it is, and then probably left alone for years. A system that changes constantly and has real peaks in its load is worth rebuilding, and the team who work on it should be the ones doing it.

The ones in between are where judgement is needed, and the tie breaker that works best is who owns it. Work that lands on a team with capacity and knowledge gets finished. Work that lands on a team already at their limit becomes a document.

Be suspicious of any assessment that recommends rebuilding a large share of the estate. That usually means somebody counted technical debt without asking what the business can absorb in a year.

Sometimes the decision has already been made by something outside the technology. A lease is ending. A hardware maintenance renewal has been quoted at a figure the board will not sign. A building is closing. In those cases rebuilding is not available for most systems, whatever the architecture review would prefer.

Say so plainly and early. A project that pretends there is a choice when there is not spends its first two months in design workshops it cannot act on, and then does the lift and shift anyway with less time than it started with.

What you can protect under a deadline is the small set of things that would be painful to undo. The account structure. The network address ranges. Who gets administrator rights and how. Where the logs go. Those are cheap to get right at the start and genuinely expensive to change later, and they take days rather than months.

Everything else can be improved after the deadline has passed, provided somebody has written down that it will be.

We will optimise it later is the most reliably broken promise in this kind of work. Nobody was lying when they said it. Once the systems are running, the urgency drains away and the team moves to whatever is on fire next.

Three things make the second step actually happen. Put it in the same business case as the move, with its own budget line, so it is funded rather than hoped for. Give each system a named owner and a review date at the moment it lands. And measure the running cost per system from the first month, so the case for the second step is a number the owner can see rather than an argument an engineer has to win.

It also helps to size the second step honestly. Swapping a database for a managed one is a few weeks of work for most applications. Rewriting an order management system is a year and a permanent team. Putting both in the same list under the word optimisation is how the second one quietly kills the first.

Review the list once a year and be willing to close items off. Some systems will still be running unchanged in five years, and that is a legitimate outcome as long as somebody chose it rather than forgot about it.