5 AWS Migration Strategies

In 2021, a large-scale migration of roughly 340 applications from a private data center to AWS was executed under an aggressive timeline. The original estimate was 18 months, later reduced to 9.

The deadline was met by applying the right strategy to each workload. Around 40% were lifted and shifted for speed, 12% required full refactoring, and 8% were retired, delivering outsized cost savings.

Choosing the wrong AWS migration strategy remains one of the costliest mistakes in cloud projects. Refactoring unnecessarily inflates budgets, while lifting and shifting without foresight embeds long-term technical debt into higher cloud costs.

This article breaks down the five AWS migration strategies, when to use each, a practical comparison framework, and a few contrarian insights often overlooked. If a move to AWS is on the horizon, consider this a practical playbook.

Why AWS migration strategy matters more than the migration itself

The migration is the easy part. The strategy is what determines whether AWS makes you faster or just more expensive.

Our team have audited dozens of cloud migrations, and the pattern is consistent. Teams that plan strategy per application succeed. Teams that pick one approach and apply it across the portfolio struggle. AWS itself documents this through the 7 R's framework (rehost, replatform, refactor, repurchase, retire, relocate, and retain), of which we will focus on the five that cover most real-world cases.

According to Flexera's State of the Cloud reports, managing cloud spend is the top challenge for organizations year after year, and a lot of that spend is locked in by migration choices made years earlier. A bad strategy decision in week 4 of your migration becomes a $400K annual line item in year 3.

For broader context on this shift in thinking, the writeup on moving from cloud spend to cloud strategy covers how enterprises are reframing migration as a business decision, not an infrastructure project.

With strategy framed properly, let me walk through the five approaches I use, starting with the fastest.

Strategy 1: Rehost (Lift and Shift)

Rehost is exactly what it sounds like. You pick up an application from on-premises or another cloud, drop it on AWS EC2, and change as little as possible. This is the strategy I default to when speed matters more than optimization.

When I use rehost:

• The application is stable and not slated for major changes
• The data center contract is ending and we have weeks, not months
• Compliance or audit timelines force a hard deadline
• The team needs a quick win to build migration momentum

The trade-off is real. Rehosted applications usually run 15% to 25% more expensive on AWS than they did on-prem in year one, because you keep the same architecture without picking up the elasticity AWS provides. That premium typically disappears once you optimize, but only if you actually go back and optimize.

The right tooling here matters. AWS Application Migration Service (MGN), CloudEndure, and Carbonite handle the heavy lifting. For a closer look at the options, the top 5 AWS migration tools walks through what each is good for.

Rehost is the on-ramp. The next strategy is what most migrations actually graduate to.

Strategy 2: Replatform (Lift and Tweak)

Replatform is the strategy I see deliver the best return for the least pain. You move to AWS but swap a few components for managed services along the way. The application logic stays mostly the same.

The classic moves I make in a replatform:

• Self-managed PostgreSQL or MySQL becomes Amazon RDS
• Self-hosted Redis becomes Amazon ElastiCache
• Apache or Nginx behind a static load balancer becomes Application Load Balancer plus Auto Scaling
• Manual deployments become Elastic Beanstalk or AWS App Runner

Each swap removes operational burden without forcing a code rewrite. I have seen teams cut their on-call alerts by 60% just by moving to RDS, because patching, backups, and failover stop being someone's weekend problem.

A note on Auto Scaling specifically: most replatformed applications benefit immediately from horizontal scaling, but only if they were stateless to begin with. The AWS Auto Scaling guide is worth reading before you commit, because retrofitting statelessness during migration adds weeks.

Replatform handles the moderate case. For applications where AWS-native architecture genuinely changes the economics, refactor is the move.

Strategy 3: Refactor (Re-architect)

Refactoring means rebuilding the application to take advantage of cloud-native services. This is the strategy with the biggest upside, the longest timeline, and the highest risk.

I refactor when one of three things is true:

• The current architecture genuinely cannot meet future scale or performance needs
• The application is core to the product and worth long-term investment
• The team has the skills and bandwidth for cloud-native development

The targets in a refactor usually include:

• Monolith broken into microservices on Amazon ECS, EKS, or AWS Lambda
• Synchronous workflows replaced with event-driven patterns using SNS, SQS, or EventBridge
• Custom data pipelines moved to AWS Glue, Kinesis, or DynamoDB Streams
• Batch jobs replaced with serverless using Lambda or Step Functions

A travel customer I worked with refactored their booking engine to run on Lambda behind API Gateway. Peak load went from being a quarterly capacity nightmare to a non-event. Steady-state spend dropped 34%. But it took 11 months.

The cost discipline piece matters here too. Cost-aware architecture using FinOps, TOGAF, and TBM covers how to bake cost decisions into the refactor itself, not bolt them on later.

Refactor is the heaviest lift. For teams that want modernization without the engineering investment, the next strategy is the shortcut.

Strategy 4: Repurchase (Drop and Shop)

Repurchase means replacing the application with a SaaS or commercial product. You stop owning the system and start renting it.

This is the strategy I push hardest for non-differentiating applications. CRMs, HR systems, ticketing tools, expense management, internal wikis, none of these need to be custom-built or self-hosted in 2026. The companies that build them as a service do it better and cheaper than your team will.

Common repurchase targets I have seen work:

• Custom CRM replaced with Salesforce or HubSpot
• Self-hosted ticketing replaced with Zendesk or Freshdesk
• Custom HRIS replaced with Workday or BambooHR
• Self-built analytics replaced with Snowflake plus a BI tool

The cost calculation here is not pure license vs run cost. You also save the engineering hours that were going into maintaining a system that is not your competitive advantage. In my experience, that hidden saving usually outweighs the license fee.

Repurchase modernizes by replacement. The next strategy modernizes by elimination.

Strategy 5: Retire

Retire is the strategy nobody plans for and everybody benefits from. Before you migrate anything, you find out what nobody is using and turn it off.

In every migration I have run, between 5% and 15% of the application portfolio turns out to be retire-able:

• Reporting tools nobody opened in 90 days
• Side projects from former employees still running on production servers
• Backup applications that were replaced years ago but never decommissioned
• Test environments that became permanent through neglect

The dollar value here is real. In one migration, retiring 22 applications saved more annually than the entire AWS bill for the migrated workload. Avoiding the migration cost was the icing.

The discipline that matters is not technical. It is asking, for every application, do we actually need this. That question often gets skipped because nobody wants to be the one to retire something with a name on it.

If you are interested in adjacent traps, the common AWS cloud cost mistakes driving up bills covers the post-migration version of this same problem.

Those are the five strategies. AWS officially recognizes two more, which I will cover briefly because they sometimes apply.

A note on the other 2 R's: Relocate and Retain

AWS expanded the original 5 R's into 6 R's and then 7 R's over time. The two I have not covered above are:

• Relocate: moving infrastructure to AWS without changing the OS or application, typically using VMware Cloud on AWS. This is useful for VMware-heavy environments where you want AWS scale without re-platforming the hypervisor.
• Retain: deliberately keeping an application on-premises or with the current provider, usually for compliance, latency, or cost reasons. Retain is a real decision, not a fallback.

I find Relocate is rare in practice and Retain is far more common than people admit. Some workloads simply do not belong on AWS, and pretending otherwise is how migrations stretch from 9 months to 24.

With all seven options on the table, the real question is which one fits your specific application. Here is the framework I use to decide.

A contrarian take on AWS migrations

Most AWS migration guides treat all-in on AWS as the goal. I disagree.

The best migrations I have run kept 10% to 20% of the portfolio off AWS, either on-premises or with a SaaS vendor. Forcing every workload onto AWS for ideological consistency is how you end up with $200K of latency-sensitive workloads running poorly because the nearest AWS region is 80ms away, or compliance-bound workloads in regions where the cloud provider does not yet have the certification.

A good migration strategy is portfolio thinking, not platform loyalty. AWS is the right platform for most workloads, but most is not all, and pretending otherwise is how teams get stuck in awkward architectures three years in.

The lesson I keep coming back to: pick the right destination per workload, not the right destination per company. That mindset shift is what separates a migration that delivers from one that just relocates the problem.

With opinion out of the way, here are the questions I get asked most about AWS migration.

Conclusion

Choosing the right AWS migration strategy is the highest-leverage decision in any cloud migration. The five strategies I walked through, rehost, replatform, refactor, repurchase, and retire, are the building blocks. Your job is to apply them per application, not per portfolio.

In my experience, the migrations that succeed do three things consistently. They retire aggressively before they migrate. They default to replatform over rehost when there is bandwidth. They reserve refactoring for the workloads that genuinely need it.

If you want a hand thinking through your own migration strategy, the Opslyft team has supported migrations across SaaS, fintech, and AI-native companies. Either way, start with a portfolio inventory this week. The migration plan flows from there.