How to Choose the Right AWS Migration Strategy for Your Business

Cloud migration is not a single decision. It is a series of decisions — about which workloads to move first, how to move them, what to do with legacy databases, how to handle compliance requirements, and how to sequence the work to minimize business disruption.

The organizations that get this right treat migration as a strategic program, not a technical project. They start with a clear strategy, sequence work based on business value and risk, use the right tools for each workload type, and measure outcomes throughout. The ones that struggle start by provisioning EC2 instances and figuring out strategy as they go.

This guide provides the framework for getting migration strategy right before you start.

Why Migration Strategy Matters

The stakes in cloud migration are high. A poorly planned migration can:

• Create downtime during cutovers that were not designed for zero-downtime transitions
• Introduce security gaps when on-premises security controls are not replicated in AWS
• Increase costs in the short term as duplicate environments run in parallel
• Cause compliance failures when data handling requirements are not preserved
• Waste months on the wrong approach — lift-and-shifting an application that should have been refactored, or refactoring something that should have just been rehosted

A well-planned migration:

• Delivers quick wins early to build organizational confidence
• Sequences workloads based on dependencies, not convenience
• Uses the right migration path for each workload
• Maintains or improves security and compliance throughout
• Sets up the cloud environment correctly the first time

The 6 Rs Framework

AWS defines six migration strategies — called the “6 Rs” — that describe the spectrum of approaches for moving workloads to the cloud.

1. Rehost (Lift and Shift)

Move the application to AWS infrastructure without making any changes to the application itself. Run the same software on EC2 that ran on-premises servers.

When to use:

• Applications with inflexible architecture that would require significant re-engineering to change
• Tight migration timelines where speed matters more than optimization
• First migrations where the team is learning AWS before optimizing
• Applications that will be retired within 2–3 years (not worth refactoring)
• Batch-processing workloads that simply need more reliable infrastructure

When not to use:

• Applications that need to scale horizontally (Rehost preserves scaling limitations)
• Applications where you are paying significant ongoing licensing costs that cloud-native equivalents would eliminate (SQL Server on EC2 vs. Aurora)

Tools: AWS Application Migration Service (MGN), VM Import/Export.

Typical timeline: 2–6 weeks per workload.

2. Replatform (Lift, Tinker, and Shift)

Move to AWS with optimizations that do not change the core application architecture. Switch the database engine to a managed service, containerize for consistent deployments, or move to managed middleware.

When to use:

• Applications that can benefit from managed services without significant code changes
• Reducing operational overhead without the risk of a full refactor
• Applications that are stable and well-understood but running on expensive on-premises infrastructure

Examples:

• Move from self-managed MySQL on a server to Amazon RDS MySQL (same engine, managed service)
• Move from a Tomcat application server to AWS Elastic Beanstalk (same application, managed deployment)
• Move from a VM to a container on ECS or Fargate (same application, containerized for portability)

Typical timeline: 4–8 weeks per workload.

3. Refactor / Re-architect

Modify the application code or architecture to use cloud-native services and patterns. This includes breaking a monolith into microservices, adopting serverless, replacing self-managed components with managed services.

When to use:

• Applications with significant scaling requirements that the current architecture cannot meet
• High-value applications where operational efficiency and deployment speed justify the investment
• Applications where significant licensing cost savings are available through architectural change

Examples:

• Break a monolithic e-commerce platform into services: catalog, cart, payment, and fulfillment as independent deployments on ECS
• Replace a scheduled batch process with an event-driven Lambda pipeline
• Migrate from Oracle to PostgreSQL-compatible Aurora, eliminating significant licensing costs

Typical timeline: 3–6 months per workload.

4. Rearchitect (Rebuild from Scratch)

Redesign the application from the ground up using cloud-native architecture. Serverless, event-driven, microservices by default.

When to use:

• End-of-life applications where the codebase is a liability
• Greenfield capabilities where you are designing from scratch
• Applications that need capabilities (scale, resilience, observability) that the current architecture fundamentally cannot provide

Typical timeline: 6–18 months depending on complexity.

5. Retire

Decommission the application. It no longer serves a purpose, or its functionality is covered by another system.

Assessment trigger: Any application that cannot clearly answer “who uses this and why” should be evaluated for retirement. Typically 10–20% of application portfolios in large enterprises can be retired.

6. Retain

Keep the application on-premises or in its current state. Migration is not appropriate — yet.

When to use:

• Applications recently upgraded that are stable and not causing problems
• Applications with regulatory requirements that cannot currently be met on AWS
• Applications tied to hardware that cannot be virtualized
• Mainframe systems that are technically migratable but at cost and risk not justified by current benefit

Important: Retain is a deliberate decision, not a default. Applications should be actively assessed and assigned a retain decision, not just left out of the migration.

Building Your Migration Roadmap

Step 1: Application Portfolio Discovery

Inventory every application in scope. For each, capture:

• Technology stack (language, framework, database, middleware)
• Hosting (physical servers, VMware, colocation)
• Architecture pattern (monolith, N-tier, microservices)
• Dependencies (what does this application call? what calls this application?)
• Business criticality (production revenue, internal tool, development)
• Compliance requirements (HIPAA, PCI, SOC 2, data residency)
• Current cost (infrastructure, licensing, operational)
• Business owner and technical owner

Tools that accelerate discovery: AWS Migration Evaluator, TSO Logic, or RISC Networks can scan your environment and auto-populate this inventory.

Step 2: Assign Migration Strategy

For each application, assign one of the 6 Rs based on:

Complexity assessment:

• How many dependencies does it have?
• How well-documented is the architecture?
• What is the team’s capacity to make changes?

Business value assessment:

• What is the cost of not migrating (license costs, operational costs)?
• What is the value of cloud-native capabilities (scalability, new features)?
• What is the cost and risk of migration?

The dependency map is critical. Applications that share databases or call each other must be migrated in the right sequence. Migrating a front-end application before its back-end API creates a split environment that is harder to operate.

Step 3: Wave Planning

Organize migrations into waves — batches of applications migrated together. Wave planning must account for:

• Dependencies — Applications that share infrastructure or call each other should be in the same wave
• Risk sequencing — Start with lower-risk applications (internal tools, development environments) to build team experience before migrating production revenue
• Decoupling prerequisites — Some applications need dependencies decoupled before migration. If Application A calls Application B, and B is staying on-premises while A migrates, you need an interface between cloud and on-premises (VPN, Direct Connect, or API gateway)

Typical wave structure for a 50-application portfolio:

• Wave 0 (foundation): AWS account structure, VPCs, connectivity, IAM baselines, CI/CD pipelines, monitoring setup. No workloads.
• Wave 1 (proof of concept): 3–5 low-risk, low-complexity applications. Build team skills and validate tools.
• Wave 2–N (production migration): Remaining workloads in dependency order, typically 5–15 applications per wave.

Step 4: Choose Migration Tools

AWS Application Migration Service (MGN) is the primary rehost tool. MGN installs an agent on source servers that continuously replicates data to AWS staging infrastructure. When ready to cut over, MGN launches an exact replica in AWS. Downtime is typically minutes, not hours.

AWS Database Migration Service (DMS) handles database migrations, including heterogeneous migrations (Oracle to Aurora, SQL Server to PostgreSQL). DMS supports both full-load and ongoing change data capture (CDC) for minimal-downtime database cutovers.

AWS Schema Conversion Tool (SCT) automates schema conversion for heterogeneous database migrations — converting Oracle stored procedures, functions, and views to PostgreSQL-compatible equivalents, flagging manual conversion requirements.

AWS DataSync migrates large file data sets (NAS, SMB shares, NFS) to S3, EFS, or FSx with bandwidth throttling and scheduling.

AWS Snowball and Snowball Edge handle very large data migration (50 TB+) where network transfer would take too long or is too expensive.

Step 5: The AWS Migration Acceleration Program (MAP)

The AWS Migration Acceleration Program provides credits, tooling, and methodology support for qualified migrations. Organizations migrating with an AWS Partner (Select Tier or above) that meet spend thresholds are eligible for MAP funding.

MAP has two phases:

Assess & Mobilize: AWS-funded workload assessment, business case development, and migration readiness. Typically $10,000–$50,000 in AWS credits for this phase.

Migrate & Modernize: Per-server credits for each workload migrated, based on migration complexity and source environment. Credits can offset significant portions of the migration project cost.

For smaller migrations (under 50 servers), MAP SMB offers a simplified program with faster qualification. See our AWS MAP Guide for SMBs for details on qualification and claiming credits.

Migration Execution Best Practices

Test migrations before production cutovers

For rehost migrations using MGN: run test cutovers before the production cutover. MGN supports non-disruptive test instances that verify the migrated server functions correctly without affecting the source environment. Catch environment-specific issues (DNS resolution, connection strings, directory paths) in testing, not during the production window.

Maintain a rollback plan

Every migration cutover should have a documented rollback procedure. For rehost migrations, this is usually: if the cutover fails, keep traffic on the source server and don’t decommission until the AWS environment is validated.

For database migrations with DMS CDC replication active, rollback is possible even after cutover by reversing the replication direction — but this needs to be planned and tested in advance.

Parallelize where possible

Multiple unrelated workloads can be migrated simultaneously. If your team has the capacity, running two or three migration streams in parallel significantly compresses the overall timeline.

Do not skip the landing zone

The temptation in fast migrations is to skip establishing a proper AWS account structure, VPCs, and security baselines — “we’ll fix it later.” This creates technical debt that is very expensive to clean up: security gaps in production, no cost visibility, no ability to manage multi-account governance.

Invest Wave 0 properly. It pays for itself many times over.

Common Migration Pitfalls

Underestimating testing time — Migrations almost never fail at the technical layer. They fail at validation: the application migrated successfully but the integration with a legacy system that was not in scope broke something unexpected. Budget testing time generously.

Not accounting for licensing — Bringing Windows Server and SQL Server licenses to AWS has options: License Included (higher instance cost), Bring Your Own License (BYOL), or Hybrid Benefit. Oracle on EC2 has complex licensing rules. AWS Marketplace has license-included options. Get licensing analysis done before, not during, migration.

Migrating security as an afterthought — On-premises security models (firewalls, network zones) do not map directly to AWS. Security Groups, NACLs, IAM policies, and VPC architecture need to be designed for AWS — not recreated as an AWS approximation of on-premises controls.

Forgetting DNS — Cutover failures are often DNS failures. Map every DNS entry that needs to change, who controls the TTL, and how to verify resolution from both on-premises and cloud. Reduce DNS TTLs to 60 seconds before cutovers.

No monitoring before cutover — CloudWatch dashboards, alarms, and log aggregation should be configured and validated before production cutovers. You want to know immediately if something is wrong after cutover.

Estimating Migration Costs

Migration costs have two components: project costs (labor, tooling) and transition costs (running duplicate environments during migration).

Project costs depend on migration complexity:

• Rehost: $2,000–$8,000 per application for assessment, migration, and testing
• Replatform: $8,000–$25,000 per application
• Refactor: $25,000–$150,000+ per application depending on complexity

Transition costs come from running on-premises and AWS environments simultaneously during migration. For each month of parallel running: on-premises costs remain constant while AWS costs accumulate. Minimize this window by compressing migration timelines and planning cutovers for early in the parallel window, not the end.

MAP credits offset a significant portion of both project and transition costs for qualified engagements.

For organizations beginning the migration planning process, see our AWS Cloud Migration Services page covering our migration methodology, team capabilities, and engagement options. For applications that need to go beyond migration into cloud-native redesign, see AWS Application Modernization.

Contact us to discuss your AWS migration strategy →