Lift-and-shift versus replatforming migration

WHAT THIS TESTS This checks familiarity with the migration 6 Rs and the core trade-off between migration speed and the depth of cloud value captured.

A GOOD ANSWER COVERS Rehosting, or lift and shift, moves an application to the cloud essentially unchanged, often as VMs. Pros: fastest, lowest engineering effort and risk, good for tight deadlines, data-center exits, or migrating many apps quickly; it can be partly automated. Cons: it carries existing inefficiencies along, does not exploit managed or elastic services, and frequently fails to lower cost on its own. Replatforming, sometimes called lift-tinker-and-shift, makes a few targeted changes during migration, such as moving from a self-managed database to a managed service or containerizing, to gain real cloud benefits without a full rewrite. Pros: better cost and operational gains. Cons: more effort, testing, and risk than rehosting.

COMMON WRONG ANSWERS Equating lift-and-shift with refactoring or re-architecting. Claiming rehosting automatically saves money. Saying replatforming means rewriting the application. Ignoring that the choice depends on timeline, risk tolerance, and business value.

LIKELY FOLLOW-UPS What are the other Rs? When would you refactor instead? How do you decide per application? What hidden costs follow a pure lift-and-shift?

ONE CONCRETE EXAMPLE A company exiting its data center in six months rehosts a hundred legacy apps as EC2 VMs to hit the deadline. For its busiest app, it replatforms by moving the self-managed MySQL onto RDS, gaining automated backups, patching, and failover, while leaving the application code mostly untouched, a measured step up in value for modest added effort.