Migrating on-premise applications to AWS is rarely a simple lift of a server into the cloud — it requires choosing one of six migration strategies (rehost, replatform, repurchase, refactor, retain, retire), assessing dependencies between systems, and deciding what stays on-premise. Clients ask most often about cost, downtime, and what happens if something goes wrong.
Quick Overview
What you’ll learn from this article:
- The six AWS migration strategies (the 6R model) and when to use each one
- The questions clients ask most often about migration cost, downtime and risk
- A step-by-step plan for migrating on-premise to AWS
- How to assess which applications shouldn’t move to the cloud at all
Who this article is for: IT leaders planning an infrastructure migration, cloud architects evaluating a strategy for an application portfolio, project managers responsible for migration budget and timeline.
Reading time: 7 minutes
On-premise to AWS cloud migration: the questions we hear most from clients
“How much will this cost?” has no single answer without a TCO (Total Cost of Ownership) analysis that covers not just AWS instance cost but also data transfer, licensing, team training, and maintenance during the transition period, when part of the system runs on-premise and part in the cloud. Clients often compare only the EC2 instance price to server depreciation cost — overlooking operational costs that, in an on-premise environment, are spread across multiple budgets (power, cooling, data-center space, the maintenance team).
The second most common question is about downtime: “does migration mean the application will stop working?” The answer depends on the chosen strategy. Rehost (so-called lift-and-shift, moving the application without architectural changes) minimizes the risk of errors but requires a downtime window for the final traffic cutover. Migration with real-time data replication and a blue-green strategy can limit downtime to minutes, at the cost of a more complex preparation process.
The six AWS migration strategies (the 6R model)
| Strategy | What it means | When to use it |
|---|---|---|
| Rehost | Moving the application unchanged (“lift-and-shift”) | Time pressure, application not critical to the target architecture |
| Replatform | Minor changes (e.g. migrating a database to a managed service) | Application with a clear optimization point that doesn’t need full refactoring |
| Repurchase | Switching to an off-the-shelf SaaS solution | Legacy application with a SaaS equivalent on the market |
| Refactor | Redesigning the architecture for cloud-native | Strategic application, long investment horizon |
| Retain | Leaving it on-premise | Systems with regulatory constraints or nearing end of life |
| Retire | Decommissioning the application | Duplicate or unused systems found during the pre-migration audit |
How to migrate on-premise to AWS step by step
- Build an inventory and a dependency map between applications — migrating a single application without knowing its dependencies (database, message queue, another internal system) generates the most surprises.
- Assign a 6R strategy to each application in the portfolio instead of applying one strategy to everything — some systems qualify for retire before they ever reach the migration plan.
- Start with a non-critical application as a pilot, so the team gains experience with the migration process before moving to systems with high business risk.
- Plan a coexistence period for on-premise and AWS with a clear data-synchronization strategy — it’s rare to cut over an entire application portfolio in a single day.
- Measure cost after migration over a full billing cycle before judging whether the migration met its budget targets — unoptimized AWS costs (e.g. without reserved instances) often run higher than estimated during planning.
It’s also worth asking early about the cost of transferring data between the on-premise environment and AWS, and between AWS regions during migration — egress fees are often left out of the first budget estimate, and for large volumes of historical data (e.g. migrating a file archive or a terabyte-scale database) they can become a significant share of total project cost. Teams that plan a phased migration can also spread this cost over time instead of moving the entire data volume at once.
The third common question is about what happens if something goes wrong during migration. Good practice is keeping the on-premise environment on standby (not decommissioning it immediately after migration) for a defined period, to preserve a rollback path if the AWS application reveals a problem that testing missed. This transition period generates extra cost (running two environments in parallel), but sharply reduces the business risk of migrating critical systems.
Read Also
- Are Cloud Architect Trainings Worth It? ROI and Career Impact
- Cloud FinOps and cost control: A Practical Comparison of Approaches
Develop Your Skills
Planning an infrastructure migration to AWS and need a team ready for its challenges? Check out our training led by experienced EITT instructors.
➡️ Cloud Migration — Strategy, Planning and Execution — EITT training ➡️ Migrating to AWS — EITT training
Frequently Asked Questions (FAQ)
Does migrating to AWS always lower infrastructure cost?
Not automatically. Unoptimized AWS costs (instance type selection, reserved instances, autoscaling) can run higher than on-premise costs for steady, predictable load. Savings usually show up where load is variable and the cloud lets you pay only for resources actually used.
Which 6R strategy is safest for a first migration?
Rehost (lift-and-shift) — it moves the application without architectural changes, minimizing the number of variables that can go wrong. The tradeoff is no cloud-native optimization, but it’s a solid starting point for a team without prior migration experience.
How long does a typical on-premise-to-AWS migration take?
It depends on the complexity of system dependencies and the chosen strategy — a single application without complex integrations can be migrated in a few weeks using rehost, while a full refactor for a cloud-native architecture is usually a matter of months.
Do you have to migrate the entire application portfolio at once?
No, and it’s usually not worth it. A phased migration, starting with a non-critical application as a pilot, lets the team gain experience and catch process problems before migration reaches systems of high business importance.