You’ve got a deadline to leave a data center, a budget that won’t budge, and a stack held together by tribal knowledge. Cloud migration is the easy part. Choosing how to move each app is the real fight. Pick wrong and you either carry every bad habit with you or stall for quarters. Here’s the playbook I use.
The three core paths (quick primer)
You have three default choices. I treat the other Rs (retire, replace, rebuild) as portfolio options, but day to day, these three decide your timeline and risk. Understanding these distinctions up front keeps you from over‑investing or under‑delivering:
- Rehost: move as‑is to IaaS. Fastest path, minimal change, limited upside.
- Replatform: “lift, tinker, shift.” Swap parts for managed services or containers.
- Refactor: change code and architecture for cloud‑native features.
Pros and cons you actually feel in delivery
Two short points before the lists. First, speed hides long‑term cost; modernization hides near‑term delivery risk. Second, you can mix strategies across the portfolio.
Rehost (lift‑and‑shift)
Here’s what you gain and lose when you move fast:
- Pros: quickest exit from data center; least regression risk; simple rollback.
- Cons: cloud bills may rise; legacy ops remain; hard to adopt autoscaling.
Replatform (lift, tinker, shift)
This is the “balance play,” giving you some modernization without a full rewrite:
- Pros: better reliability/cost via managed DB/cache; often container‑ready; moderate effort.
- Cons: scope creep danger; partial vendor lock‑in; testing still required.
Refactor (modernize code/arch)
You’re betting on the future, trading short‑term velocity for long‑term control:
- Pros: unlocks autoscaling/serverless; long‑term cost control; removes tech debt.
- Cons: most time and risk; bigger test scope; needs stronger engineering capacity.
How I choose per application (decision criteria)
I answer these questions in order. If a criterion is a hard constraint, it can override the rest.
Use these prompts to filter decisions through business, technical, and human lenses:
- Deadline pressure: must vacate hardware or contract? → bias to rehost now, modernize later.
- Tech health: brittle, tightly coupled, or obsolete runtime? → push to refactor key seams.
- Target capabilities: need autoscaling, managed queues, or serverless? → replatform or refactor.
- Cost posture: strict OPEX control today vs later? → rehost fast, then optimize, or refactor if you can afford runway.
- Team capacity & risk tolerance: limited team or high risk? → avoid big‑bang refactor; pick rehost/replatform.
- Compliance & uptime: strict SLOs, audit trails? → prioritize refactoring for reliability patterns.
Rubric: map signals to a strategy
This table helps make judgment calls visible and defendable when management asks “why not just refactor everything?”
| Signal | Rehost | Replatform | Refactor |
| Hard deadline to vacate DC | ✅ | ||
| Minimal test capacity | ✅ | ||
| Cloud bill already acceptable | ✅ | ||
| Needs managed DB/cache | ✅ | ||
| Wants autoscaling/containers | ✅ | ✅ | |
| Vendor DB license pain | ✅ | ✅ | |
| High tech debt / brittle code | ✅ | ||
| Needs event‑driven/API redesign | ✅ | ||
| Strict SLOs, compliance change | ✅ |
Start with deal‑breakers, score each workload, and resist the urge to refactor everything at once.
The migration journey that actually ships
I rarely pick one path for everything. I phase it so the business sees wins early and the team learns on real workloads.
Phased plan
Follow this rhythm to keep progress visible and momentum steady:
- Wave 1: Rehost the easy apps to free budget and reduce on‑prem risk.
- Wave 2: Replatform the steady‑state apps (database as a service, caches, containers, autoscaling).
- Wave 3: Refactor the high‑leverage apps: those with clear cost, scale, or reliability upside.
Each phase teaches your team a different skill set: ops confidence first, modernization next, deep engineering last.
Scope control for replatform (keep it small)
Replatform creeps because “one small change” becomes ten. I fence it with a hard checklist. Before you begin, share this list across all teams so they know the limits:
- Limit changes to infra swaps: managed DB/cache, containerization, autoscaling.
- Freeze business logic; no domain changes.
- Define a rollback path to IaaS if a managed service blocks you.
- Track a timebox per app and stop at the boundary.
Where refactor pays for itself
Refactor only where the payoff is obvious. Look for these signals first. These patterns usually justify the engineering cost:
- Unstable during peak traffic; needs autoscaling and back‑pressure.
- License or infra cost dominates TCO; need managed services and right‑sizing.
- Frequent incidents trace to tight coupling; need event‑driven seams.
- Release speed stuck due to monolith bottlenecks; need bounded contexts.
Pitfalls I see again and again
Most failures come from ignoring dependencies or trying to do everything at once. Here’s what to call out early and often in planning meetings:
- Big‑bang refactor across the portfolio: split into waves and pilots.
- Unmapped dependencies: directory services, file shares, batch jobs, firewall rules.
- Replatform bloat: swapping five services at once without a strict scope.
- No cutover plan: canary, blue‑green, or feature flags missing.
- No observability: you can’t debug what you can’t see. Budget traces/metrics.
Rollout and risk controls
Migration is delivery engineering. Treat cutovers as product launches. Use these tactics to contain risk and recover fast:
- Canary low percent traffic, bake for hours or days.
- Blue‑green to swap instantly with rollback.
- Shadow traffic to validate responses safely.
- SLOs & error budgets to pace change.
Cost checks at each stage
Cloud spend surprises sink good programs. I keep simple levers visible. Run this list monthly during migration to spot leaks early:
- Tag everything; group spend by app and environment.
- Contrast IaaS vs managed per workload; watch idle resources.
- Turn on autoscaling with reasonable min/max; test scale‑down.
- Cache reads and batch writes to cut noisy calls.
Team model and ownership
The org chart decides your architecture more than diagrams do. Align scope to teams. These principles keep accountability clear after go‑live:
- One owner per app or bounded context.
- Clear pager duty and SLOs; no orphaned workloads.
- Shared platforms (networking, identity, observability) with paved‑road docs.
Quick questionnaire (copy/paste)
Run this for each app before you pick a path. Use this list in workshops to force clarity before committing:
- What’s the hard deadline, if any?
- What’s the current monthly infra + license cost?
- What SLO does the business expect?
- How brittle is deploy/rollback today?
- Which dependencies could block migration (IDP, files, batch)?
- What cloud features are must‑haves (autoscaling, queues, serverless)?
- What’s the smallest safe scope that moves us forward?
- What’s the rollback plan?
- Do we have enough test coverage to change code safely?
- Who owns it after the cutover?
Wrap‑up
There’s no single “right” strategy. There’s the right fit per app and the right sequence for the portfolio. Move fast where you can, modernize where it pays, and protect every cutover with guardrails. That’s how you migrate without turning your roadmap into a year of firefighting.
