Migration · Insights ·
Lift-and-shift vs. refactor on AWS: a decision framework
When to move fast, when to replatform, and how to avoid paying twice for the same migration.
“Lift-and-shift” and “refactor for cloud-native” are not moral choices — they are risk and timeline trade-offs. We use a simple framework with clients in Portland and across New England before anyone rewrites production code.
Start with constraints, not buzzwords
Ask four questions:
- How much downtime can the business tolerate? Hard windows favor lift-and-shift with rehearsed cutovers.
- Is the app commercially maintained? End-of-life stacks may need replatforming regardless of preference.
- What is the cost of running as-is on AWS for 12 months? Sometimes “ inefficient but live” beats an 18-month rewrite.
- Who owns operations after go-live? A refactor your team cannot run is not a win.
Lift-and-shift fits when…
- You need out of a data center or colo on a fixed date
- The app is stable, licensed, or hard to change (COTS, legacy Java monoliths)
- You want proof in AWS before optimizing
Trade-off: You import technical debt. Plan a phase 2 optimization backlog (right-sizing, managed services, containerization) instead of pretending phase 1 is the finish line.
Refactor / replatform fits when…
- Licensing or hardware ties you to an unsustainable model
- Autoscaling, zero-downtime deploys, or regional resilience are product requirements
- The team already owns the codebase and CI/CD
Trade-off: Timeline and scope creep. Bound the first release (one service, one region, one path to production).
The pattern that works
We often recommend migrate first, optimize second: get to AWS with rollback plans, then prioritize the top three cost or reliability wins from production metrics — not from a slide deck.
That keeps executives confident and engineers honest about what “done” means.