Migration Strategies

The Six R Strategies

Migration strategy is a per-application decision, not a program-wide slogan:

• Rehost — lift and shift VMs as-is ("wave your magic wand" at infrastructure level). Fastest, no code change, leaves inefficiency intact.
• Replatform — lift, tinker, shift: managed swaps without code changes, e.g., move a database to RDS or put a load balancer in front.
• Repurchase — abandon the software and buy SaaS (on-prem CRM → Salesforce).
• Refactor — re-architect for cloud-native services: containers, serverless, managed queues. Highest cost and longest timeline, best long-term payoff.
• Retain — keep what is on-prem for now (latency-bound or recently upgraded systems); hybridize the connection.
• Retire — decommission everything discovery proves nobody uses.

Choosing Per Workload

Start from inventory, not intuition. For each application record dependencies, license terms, performance profile, and business criticality, then walk the decision:

1. Is it used? No → retire.
2. Is there a SaaS equivalent that fits process and compliance? → repurchase.
3. Must it change for the cloud to pay off (scale, elasticity, release velocity)? Yes → refactor; only a host change needed (OS version, DB engine) → replatform.
4. Otherwise rehost now and revisit after stabilization; retain when regulations or hardware cycles block the move.

A portfolio lands spread across strategies — that spread is the plan, not a failure to pick one.

Pitfalls and Interview Focus

Common failures: deciding before discovery (dependencies and batch jobs ambush the timeline); refactoring everything at once (scope creep eats the schedule — rehost first, optimize later); skipping retire (you keep paying to migrate dead systems); and underestimating data gravity — the bigger the on-prem data, the harder replatform becomes.

Also budget for people: refactor changes how teams build and operate, which needs training and new runbooks, not just new services.

Interview: present a small portfolio, apply the decision tree above, and defend two choices — including one you deliberately rehost now and refactor later. Naming when not to refactor signals seniority.