Eon’s founders built and led the AWS Disaster Recovery and Migration services. The seven steps below follow the order a migration wave runs in, and the protection and rollback work starts in Step 3 instead of after cutover.
What are the 7 steps of cloud migration?
Cloud migration has no single official list of steps. The seven in this guide are portfolio assessment, business case and strategy selection, landing zone setup, data protection and rollback planning, wave migration and cutover, validation, and post-migration tuning.
AWS groups the same work into three migration phases, called assess, mobilize, and migrate and modernize.
Step 1. Assess and discover the application portfolio
Discovery starts with an inventory of every server, database, file share, and storage bucket, plus the network connections between them.
Use the dependency map to group applications into waves. Two applications that call each other on every request belong in the same wave. If you split them, every request crosses the link between the data center and the cloud until the second one moves.
Collect utilization and response-time data for at least a full business cycle. Utilization data flags servers with too little traffic to justify moving, and response times give you a baseline to test against after cutover.
AWS Transform assessments can discover your on-premises environment and generate a business case with total cost of ownership projections if you’re moving to AWS.
While you inventory each source system, record whether it has current backups, where those copies live, and how long they're kept. You'll use that list for the pre-cutover backups in Step 4.
Step 2. Build the business case and assign a strategy to each workload
Open the business case with the reason for the move, such as a data center lease ending, a merger, or a mandate to cut infrastructure spend. A lease that ends in nine months leaves little room for refactoring, so plan more rehosting when the date is fixed.
Capture today's full run cost before anything moves, including licensing, storage, and backup. You'll measure post-migration spend against this number, so leave no line item out.
Budget for backup and recovery in the same document. Protection for platform services often goes unplanned because it was never part of the original migration business case.
Then assign each workload one of the 7 Rs and schedule it into a wave. Put low-complexity applications in the first waves, so your engineers learn the migration tooling on systems that can absorb a delay (an internal reporting server, say, instead of the order system).
In a 2021 analysis, McKinsey found that coordination missteps put the average company’s migration spend 14% over plan each year. Give the wave plan one owner and review it every week.
Step 3. Build the landing zone and security baseline
A landing zone is the target environment, set up with its security controls before the first workload arrives. The same idea applies on every cloud: AWS sets one up through Control Tower, Azure through its Cloud Adoption Framework landing zones, and Google Cloud through its landing zone design.
At minimum, it covers:
- Account structure: Separate accounts or projects for production, non-production, security tooling, and backups.
- Identity: One source of identity, with roles scoped per workload and no shared admin credentials.
- Network: Segmented subnets and encrypted links between the data center and the cloud.
- Logging: Audit logs from both sides of the migration, collected in one place.
- Backup policies: retention and scope defined per account before any data lands.
Under the AWS shared responsibility model, AWS handles the data centers, hardware, and network underneath its services. Your data, identities, and configurations stay with you, and so does recovering a table someone deletes by mistake. On Amazon RDS, native point-in-time recovery creates a new database instance, so getting back one deleted table means restoring the whole instance and pulling the table out by hand.
While waves are in flight, identity, network paths, and data span the data center and the cloud. Use one identity provider for both, send logs from both sides to one place, and secure the link between them as production traffic until the last wave lands.
Expect to run two protection tools side by side during that stretch, one for what still sits on premises and one for what has landed, and budget for the overlap in Step 2.
Step 4. Back up source data and document the rollback plan
Back up every source server and database before cutover, and confirm the copies restore. AWS’s cutover guidance puts a final backup of the on-premises system right after the ingestion freeze and before the final data sync.
Write the rollback plan before the change request goes in. It should cover five points:
- Trigger: Which check result sends you back, and who makes the call.
- Time budget: How long rollback takes. If it can't finish inside the outage window, shrink the wave or extend the window.
- Data written after cutover: How new records sync back to the source if you revert.
- Traffic: How DNS or load balancer changes get reversed, and how long clients cache the old answer.
- Verification: Who confirms the source is healthy again.
Protect the new environment as you build it. Replicated servers and new databases start taking writes at cutover, and anything created mid-wave without a policy stays unprotected until someone notices.
In a March 2026 survey Eon commissioned of 583 cloud IT leaders and managers, 72% said migration or modernization frequently or sometimes exposes unexpected protection or governance gaps.
Eon’s Cloud Backup Posture Management (CBPM) addresses that window. It continuously scans for new and updated resources, classifies them, and attaches the matching policy by classification instead of manual tags. Copies sit in logically air-gapped vaults in a separate account from your production environment.
Sigdo Koppers added its Google Compute Engine VMs to Eon as they moved into Google Cloud, so coverage kept pace with the migration. Alejandro Zuniga, IT & Security Architect, said: “I’m truly happy with Eon because they made it easy to get everything protected and keep us in compliance while we migrated.”
Write scope and retention into a backup policy before the first wave. The rollback plan covers only this cutover; your cloud disaster recovery plan takes over once the migration closes.
Step 5. Migrate in waves and cut over
Rehost migrations usually run on continuous replication, which keeps the target in sync while the source keeps serving users. On AWS, AWS Transform MGN runs rehost replication and cutover. AWS renamed the service from AWS Application Migration Service in June 2026.
A typical cutover sequence, in the order practitioners usually run it, looks like this:
- Lower DNS time-to-live values a day or two ahead, so the switch propagates quickly.
- Stop application and database services on the source.
- Run a final data sync for anything not under continuous replication.
- Launch target instances in cutover mode and confirm they're healthy.
- Point DNS at the new endpoints and confirm the change resolved.
- Start application services on the target and apply configuration changes, such as new IP addresses.
For complicated systems, AWS describes a phased cutover, where part of an application’s servers move first and the rest stay on premises. Check whether the on-premises servers can keep working if the database moves ahead of them.
Keep the source environment intact and powered down until Step 6 signs off. In AWS Transform MGN, finalizing a cutover stops replication and discards the replicated data, so hold off on finalizing until then. Yes, you carry the cost of both environments in the meantime.
Step 6. Test and validate migrated workloads
Technical verification confirms instances, services, integrations, and scheduled jobs behave the way they did on the source. Business verification puts real users through real transactions, such as a month-end report or a checkout.
Compare response times and error rates against the baseline you captured in Step 1. If a rehosted app runs slower, check instance sizing and storage throughput before you touch the code.
Run one restore test on the migrated workload before sign-off. Back it up, then restore a single file or database table, using granular recovery where your platform supports it, and compare the result against the source. If the restored data doesn't match, fix the backup configuration before you decommission the source.
Decommission the source only after all three of these hold:
- Regression tests pass.
- Application health holds.
- Performance metrics match the Step 1 baseline.
Take one final backup of the source first, and keep it for as long as your records obligations require.
Step 7. Optimize cost and operations after cutover
Rehosted servers arrive sized for on-premises hardware, so rightsizing is usually the first cloud cost strategy to apply. Commitment discounts and storage tiering come next, after 60 to 90 days of usage data.
Flexera's 2026 State of the Cloud report puts estimated wasted cloud spend at 29%, the first increase in five years. Schedule a rightsizing and waste review once each wave has 60 to 90 days of usage data, and size to peak patterns instead of averages.
Include backup storage in that review. Source backups kept "just in case," replication snapshots, and fresh cloud backups can pile up for the same data. Set an expiry date for every pre-migration copy, and tie retention to the data's class. Sigdo Koppers’ own cost modeling during its move to Google Cloud projected Eon’s backup cost about 38% below native GCP snapshots.
The 7 Rs of cloud migration explained
The 7 Rs are the seven AWS migration strategies. Assign each workload in your portfolio exactly one, based on how much of the application you're prepared to change during the move.
Retire
Retire means shutting an application down or archiving it. AWS lists applications averaging under 5% CPU and memory use, or with no inbound connection for 90 days, as candidates to retire.
Retired systems often hold records you're legally required to keep. Archive those records and name an owner for the archive before the servers go dark.
Retain
Retain keeps an application in the source environment for now. Sound reasons to wait include:
- Residency laws
- A system upgraded last quarter
- An upstream dependency still on premises
- Hardware with no cloud equivalent
For as long as a retained system stays on premises, keep its protection coverage and logging active and include it in audit scope.
Rehost
Rehost, also called lift and shift, moves an application to the cloud with no code changes. The source can be bare metal, a hypervisor, or a different cloud provider. Use it to move large numbers of servers with little compatibility risk, then optimize once the workloads run in the cloud.
Relocate
Relocate shifts a whole group of servers onto the cloud-hosted edition of the platform they already run on, so nobody buys hardware or touches application code. Because the application architecture doesn't change, relocate is the quickest way to get a workload running in the cloud.
The same strategy covers moving instances or objects to another VPC, Region, or account, such as shifting an Amazon RDS instance into a different AWS account.
Repurchase
Repurchase, also called drop and shop, replaces an application with a different product, usually a SaaS equivalent. You still own data migration, identity integration, and network setup. Check the new vendor's export and retention options before you switch the old system off.
Replatform
Replatform, sometimes called lift, tinker, and shift, moves an application with a few targeted changes. Swapping a self-managed SQL Server for Amazon RDS, or packaging a VM-based app into containers, are typical replatform moves.
A managed database comes with its own native backup and retention settings. Amazon RDS, for example, defaults to 7 days of automated backup retention through the console and 1 day through the API or CLI, which rarely matches an on-premises policy. Re-map your backup policy for every replatformed database before cutover.
Refactor or re-architect
Refactor rebuilds an application around cloud-native services to gain scalability and release speed. It takes the heaviest engineering effort of the seven, because the architecture changes while the migration is underway.
Refactored systems usually run alongside the original during the transition, so protect data on both sides for the whole overlap.
AWS migration strategies for large migrations
The seven strategies are the same at any size. What changes in a large migration is which ones you lean on.
When you're moving hundreds or thousands of applications, you can't hand-engineer each one, so AWS steers large programs toward the repeatable, lower-risk strategies: rehost, replatform, relocate, and retire. Refactoring is the last resort, because redesigning an application while you move it adds testing and rollback work to every cutover.
AWS recommends migrating first and modernizing after: get workloads running in the cloud on a strategy that scales across waves, then re-architect the ones worth it once they’re live. A small set of R's also keeps the wave plan repeatable, so each wave runs on the same playbook instead of becoming its own project.
AWS Migration Hub closed to new customers on November 7, 2025, and AWS now points migration planning and tracking to AWS Transform. If your plan names Migration Hub and your account is new to it, use AWS Transform instead. Existing Migration Hub customers can keep using it to finish ongoing projects.
How the 5, 6, and 7 Rs frameworks differ
In 2011, Gartner identified five options for moving applications to the cloud: rehost on IaaS, refactor for PaaS, revise for IaaS or PaaS, rebuild on PaaS, and replace with SaaS.
AWS's Stephen Orban published six strategies in 2016, building on Gartner's five and adding retire and retain. AWS later added relocate to reach seven.
Gartner's 2011 "refactor" meant running an application on PaaS with little code change, which sits closer to AWS's replatform. AWS's refactor lines up with Gartner's rebuild, so the same word can describe two very different projects.
