How do we choose between lift-and-shift and re-architecting for cloud migration?

Framing this as a single company-wide choice is what makes it hard. Sort workload by workload and the answer usually becomes obvious.

Lift-and-shift is right when

The application is stable, the team that built it has moved on, the licensing transfers cleanly, and the driver for moving is a data centre exit with a date attached. You get out on time, you keep the operational model you already know, and you defer the redesign.

Re-architecting is right when

The workload has variable demand, the codebase is under active development, and the cost of running it flat is visible in the bill. Elasticity is the return here — if load does not vary, re-architecting buys you very little.

The trap in the middle

Partial re-architecture, where a monolith is split just enough to become distributed but not enough to be independently deployable. You take on the operational complexity of microservices and keep the release coupling of a monolith. If you are going to split, split along real ownership boundaries.

A practical sorting exercise

List every workload against two axes: how variable is demand, and how actively is it developed. High on both, re-architect. Low on both, lift and shift. High on one, move it as-is and revisit within a year with real usage data.

Budget for the second pass

Lift-and-shift is not a failure state, but it is not the end state either. Plan the optimisation pass into the following year explicitly, or the cloud bill becomes the thing everyone points at.