What is an on-premise to AWS migration?
An on-premise to AWS migration moves your applications, data, and workloads from servers you own and operate — in your own building or a colocation rack — onto Amazon Web Services' managed cloud infrastructure. Instead of racking hardware, patching hypervisors, and forecasting capacity 18 months out, you rent compute, storage, and managed services on demand and pay for what you actually use.
The hard part is rarely the technology. It is deciding how each workload should move. A monolithic ERP that a business runs on does not migrate the same way as a stateless web service or a database nearing end-of-support. That is exactly the decision the 6 R's framework — AWS's own migration taxonomy — is built to answer.
What are the 6 R's of cloud migration?
The 6 R's are six migration strategies, each describing a different amount of change you apply to a workload as it moves. AWS popularised the model (extending Gartner's original "5 R's"), and it remains the fastest way to sort a messy on-premise estate into a migration plan.
| Strategy | What it means | Effort | Best for |
|---|---|---|---|
| Rehost ("lift and shift") | Move the workload as-is onto EC2, no code change | Low | Deadline-driven exits, VMs that "just work" |
| Replatform ("lift and reshape") | Move with small optimisations — e.g. self-managed DB to RDS | Low–medium | Cutting ops toil without rewriting |
| Repurchase ("drop and shop") | Replace with a SaaS or managed product | Medium | Legacy CRM, email, licensing you'd rather retire |
| Refactor / Re-architect | Rewrite meaningfully to be cloud-native | High | Scaling limits, high-value apps worth the investment |
| Retain ("revisit") | Leave it on-premise for now | None | Compliance holds, hardware not yet depreciated |
| Retire | Decommission it entirely | None | Zombie apps nobody uses but everybody pays for |
A real data center to AWS programme almost always uses several of these at once. The discovery phase — where you inventory every server, dependency, and license — is what tells you which R applies where. Skip it, and you will discover the hard way that a "simple" app talks to four undocumented systems.
When should you use lift and shift versus refactor?
This is the decision founders and CTOs agonise over, usually more than they need to. The honest answer: let the deadline and the business value of the workload decide.
Choose lift and shift (rehost) when:
- You have a hard exit date — a data centre lease expiring, hardware failing, or an acquisition deadline.
- The application is stable and you have no appetite to touch its code right now.
- You want to stop the bleeding fast and optimise after you are safely on AWS.
Choose refactor when:
- The workload is strategic — it is the product, or close to it — and cloud-native scaling directly moves revenue.
- The current architecture actively blocks you: it cannot scale horizontally, or a single database is the ceiling on growth.
- You have the engineering capacity to do it without starving your roadmap.
A pattern we see work well: rehost first to hit the deadline, then replatform or refactor the two or three workloads that actually matter once the pressure is off. The mistake is trying to refactor everything up front — it turns a three-month migration into an 18-month one and the business loses patience long before the benefits land.
How do you migrate from on-premise to AWS, step by step?
A disciplined legacy migration follows a repeatable sequence. AWS frames it as three phases — assess, mobilise, migrate & modernise — but here is the practical version a delivery team actually runs:
- Discover and inventory. Use tooling (AWS Application Discovery Service, or agentless network scans) to catalogue every server, its utilisation, and its dependencies. You cannot plan what you cannot see.
- Assess and assign an R. Score each workload on business value, technical risk, and effort, then tag it rehost / replatform / repurchase / refactor / retain / retire. Retiring dead workloads is free savings — take them.
- Build the landing zone. Set up your AWS accounts, networking, IAM, guardrails, and logging before you move anything. This is where the AWS Well-Architected Framework earns its keep — security and cost pillars are far cheaper to design in than to retrofit.
- Pilot. Migrate one low-risk, representative workload end to end. It surfaces the surprises — DNS, licensing, latency between on-prem and cloud during the transition — while the stakes are low.
- Migrate in waves. Group workloads by dependency and move them in batches, using AWS DMS for databases and MGN (Application Migration Service) for rehosts. Validate each wave against a defined success checklist before the next.
- Optimise and decommission. Right-size instances, adopt reserved or savings plans, and only then power down the old hardware. Running both estates in parallel is expensive, so keep the overlap short and deliberate.
If you want a workload-by-workload template for phases 1 and 2, our cloud migration checklist breaks the discovery and cutover steps into a list you can hand to your team.
How much does an on-premise to AWS migration cost?
There are two costs, and teams routinely conflate them. The migration project cost is one-off: discovery, engineering time, tooling, and the parallel-running period where you pay for both estates. The ongoing AWS bill is what you pay every month afterwards — and it is only lower than your data centre if you right-size and adopt commitment-based pricing.
Rough guidance on the strategy you pick:
- Rehost is the cheapest and fastest to execute, but delivers the smallest ongoing savings — you are running the same over-provisioned VM, now on EC2.
- Replatform costs a little more up front and pays it back through reduced operational toil (managed databases, autoscaling).
- Refactor is the most expensive project but unlocks the biggest long-term efficiency — you pay only for what serverless or containerised workloads actually consume.
The single biggest cost mistake is treating AWS like a rented data centre: lifting and shifting oversized machines and never right-sizing them. We break the numbers down properly in our AWS migration cost guide for 2026. And if you are still choosing a provider, it is worth reading how AWS, Azure, and Google Cloud compare in 2026 before you commit an estate to one.
What are the most common on-premise to AWS migration mistakes?
- Skipping discovery. Migrating workloads whose dependencies you never mapped is how "quick" migrations blow their timeline.
- Refactoring everything. Perfect is the enemy of migrated. Move first, modernise the workloads that justify it.
- No landing zone. Moving workloads into a flat, ungoverned account creates a security and cost mess you will spend a year cleaning up.
- Forgetting the parallel-run cost. Running both estates for months quietly doubles infrastructure spend. Plan the cutover to keep overlap tight.
- Treating it as purely a lift-and-shift. The point of moving to AWS is to work differently, not to relocate the same bottlenecks.
- Under-resourcing the team. A migration competes with your product roadmap for the same engineers. Either protect the roadmap with outside help, or accept it will slow.
How ILMTEC helps
ILMTEC runs on-premise to AWS migrations in fixed six-week cycles: a scoped discovery-and-assessment cycle that assigns every workload its R and produces a costed wave plan, followed by delivery cycles that migrate and right-size. Because we assess before we move, you get a landing zone built to the Well-Architected pillars rather than a flat account you regret. When a migration also exposes a capacity gap, we can place senior India-based engineers alongside your team through Talenlio, so the cloud move never comes at the expense of your product roadmap. Start with a free migration assessment — you will leave with a workload inventory and a strategy map, whether or not you build with us.
