TL;DR: Decide per workload on two axes: how much the application can change before the deadline, and how much it costs to run as-is in the cloud. Lift-and-shift when the deadline is hard and the app is stable; rebuild only where cloud-native properties (elasticity, managed data) change the business case; re-platform selectively where a managed service removes real operational burden.
How to approach it
Reject the premise that one strategy fits the portfolio; mature migrations are mixed. Then give your two deciding axes explicitly and place an example workload on each. This question tests judgment under constraint, so constraints belong in your answer.
A strong answer
Lift-and-shift (rehost). Move the machine images or convert to instances with minimal change.
Choose it when: the deadline is external and immovable (data centre lease ends, acquisition divestiture), the application is stable and poorly documented (change risk exceeds hosting savings), or the team owning it has dissolved. A billing system that works and has nobody who fully understands it should move as-is; refactoring it mid-migration risks the business itself.
Cost honestly: measure the run rate using actual sizing, licensing and transfer costs. Rehosting minimizes application change but still needs migration engineering, testing and cutover work; it is not zero-cost development. The classic mistake is judging lift-and-shift by its end-state efficiency when its actual job is de-risking a deadline.
Refactor or rebuild. Refactoring changes the existing application; rewriting replaces it. Either may adopt managed databases or event-driven integration, but cloud-native operation does not require microservices.
Choose it when: elasticity changes the economics materially (seasonal workloads paying for peak hardware year-round), the platform blocks product plans (monolith where every release needs fleet-wide coordination), or the current technology is unsupportable. The condition that keeps this honest: rewrite scope must be bounded by team capacity measured in quarters, not years, and funded by someone accountable. Rewrites that drift into multi-year limbo while the old system still runs are a recognised enterprise tragedy; if you cannot name the quarter it lands, do not start it yet.
Re-platform (lift-tinker-shift / replatform). Move mostly as-is but swap selected layers: database engine to a managed equivalent, VMs to containers, cron to a scheduler service.
This is where most real migrations settle, applied selectively: take managed-service wins where they remove genuine operational pain (patching cycles, backup tooling, licence management) and leave application code alone. Each swap needs its own compatibility check (stored procedures versus managed SQL dialects being the classic trap).
A decision procedure: inventory workloads and score each on change tolerance (can it be modified safely before the deadline?), operational pain (how much toil does as-is migration preserve forever?), and value at risk (what does a failed migration cost?). High pain plus high stability argues lift-and-shift now, re-platform later from a safe position. Migrate in dependency order with the boring low-risk systems first to build organisational muscle, saving crown jewels until the pipeline is rehearsed. And define exit criteria per wave: cutover date, rollback plan, observation window, then decommission the source. The graveyard of half-migrations running both environments forever is the true failure mode, and it comes from not forcing the decommission step.
What interviewers probe next
"How do you price the comparison?" Match unit-for-unit over three years including licences, storage growth, egress during and after migration, and the engineering time each option consumes. Cloud pricing tools model the infrastructure; the engineering time people forget.
"Where does data gravity bite?" Large datasets with tight compute coupling: moving data once is fine, but chatty cross-system calls after migration make egress and latency permanent taxes. Co-locate systems that talk constantly.
"Who decides?" A named owner per workload with a published target and date, reviewed monthly. Committee-driven migrations stall exactly at the hard decisions this framework exists to force.
Common mistakes
Choosing by ideology ("cloud-native or nothing") instead of by constraint. Deadline reality beats architecture aspiration every time.
Boiling the ocean: big-bang cutover of interdependent systems. Wave-based migration with rehearsals exists precisely because big-bang fails.
Forgetting the people. The team that ran the old system holds undocumented knowledge; their involvement decides whether month two works.