Cloud Migration

A migration that copies the current architecture verbatim into a new provider ships the current architecture's problems to a new address, plus a new set of provider-specific quirks nobody has learned yet. The move itself is rarely the hard part; deciding what to actually change during the move is.

Every workload deserves an explicit choice among the 6 Rs before it gets touched, and every cutover deserves a rollback plan tested before the migration is called done. Decide what you're changing on purpose, and prove you can go back before you can't.

1. Assign each workload one of the 6 Rs, deliberately

The 6 Rs — retire, retain, rehost, replatform, repurchase, refactor — are a forcing function against defaulting everything to "rehost" (lift-and-shift) because it's the least work upfront. Rehosting is often correct for low-value or soon-to-be-decommissioned systems; it's usually wrong for anything that will live for years, because it carries forward architectural debt at cloud prices instead of on-prem prices.