Cloud migration checklist: every step from inventory to cutover

A cloud migration checklist is the ordered list of proof you need before and after you move an application. A cloud migration follows six steps: inventory every application and dependency, pick a strategy per workload (the AWS 7 Rs), build a secure landing zone with cost controls, migrate in waves starting with low-risk workloads, rehearse the cutover with rollback criteria, then optimize and shut down the old environment. Rollback criteria come before the first wave, and the cutover and shutdown steps repeat for each production wave.

This guide gives each step an owner and the evidence that proves it is done, on AWS, Microsoft Azure or Google Cloud. If you want senior help with the plan or the move, our cloud consulting services cover both.

The cloud migration checklist at a glance

These six cloud migration steps each end with evidence. A step is done when a named person can show the proof in the last column.

Copy the table into your cloud migration project plan, or use it as a cloud migration plan template and add one row per workload. In a small team one person may hold several of these roles, but every row still needs a name beside it.

A cloud migration checklist is not one straight line. Set rollback criteria before the first wave, then repeat steps 5 and 6 for every wave that reaches production.

This order broadly matches what the three big providers publish. AWS describes three phases: assess, mobilize, then migrate and modernize. Google Cloud describes four: assess, plan, deploy and optimize.

Step 1: Inventory every application and dependency

List everything that runs, including the parts nobody thinks about. A dependency that is missing from the list stays hidden until the old address stops answering.

• Applications. Every app, its owner, its users and how much downtime it can tolerate.
• Data stores. Databases, file shares and object storage, with their size and how fast they change.
• Scheduled work. Cron jobs, batch runs, queues and anything that fires once a month.
• Connections. Domain Name System (DNS) records, certificates, secrets, firewall rules and every third-party integration that knows an address.

Keep the app list in one shared file. A missed job is the classic failure: a monthly export that runs on an old server, appears on nobody's list and breaks after the server is gone.

Microsoft's planning guidance says to map internal and external dependencies before you create migration groups. When you are unsure how critical a link is, it says to keep those components together. Each group should also include supporting pieces such as load balancers, DNS records and caching layers.

While you are here, record a performance baseline. Google Cloud's assess phase includes app performance benchmarks, and without them nobody can say later whether the new environment is slower. Check each runtime and database against a software end-of-life tracker too, so you do not carry an expiring version into the new setup. Keep the finished inventory, because it is useful again if a buyer or investor later runs technical due diligence.

Step 2: Pick a strategy per workload with the 7 Rs

Give every workload one of the seven strategies AWS groups as the 7 Rs, with a written reason. Agree the goals first, because each reason should point at one. The AWS checklist for small and midsized businesses says to write clear objectives and key performance indicators (KPIs) and decide how you will measure success.

Rehost vs refactor is the choice that shapes the budget most. The AWS guidance on migration strategies calls refactoring the most complex and costly of the seven. For large migrations it recommends refactoring only when the other options are not acceptable, and modernizing after the move.

A move and a redesign at the same time give you two sources of failure and no clean way to tell them apart. Put the redesign on your plan to reduce technical debt instead.

Look for retire candidates first, because they cost nothing to move. AWS suggests checking usage data: apps averaging below 5 percent processor (CPU) and memory use are what it calls zombie applications, and those between 5 and 20 percent over 90 days are idle ones. Both are worth questioning before you pay to move them.

Step 3: Build a landing zone with cost controls

A landing zone is the prepared environment your workloads move into: accounts, identity, networking, logging and guardrails. Build it before the first workload moves, because every workload after that inherits it.

For a startup this can stay small, but five things should exist before anything moves:

• Identity. Single sign-on, multifactor authentication and least-privilege roles.
• Infrastructure as code. Templates in version control, tested by deploying the whole environment from scratch in a sandbox, as Microsoft advises.
• Logs and backups. An activity trail and tested restores, turned on from the start.
• Cost controls. Budgets with alerts, and tags for owner and wave, so spending can be traced during the move.
• Compliance and governance. Note the compliance rules that apply to your data, and put a governance owner in place before workloads deploy, as Microsoft's organization guide advises. If customers ask for audits, start with SOC 2 for startups.

Security does not move with the workload. The AWS shared responsibility model separates security of the cloud, which AWS handles, from security in the cloud, which you handle, and your share depends on the services you pick. If nobody on your team owns this foundation, DevOps consulting services can set up the pipelines and infrastructure code behind it.

Step 4: Migrate in waves, lowest risk first

Group dependent workloads into waves and move the simplest first. The waves, in order and with dates and owners, are your cloud migration roadmap.

Microsoft's planning guidance gives a practical order:

• Start with less complex, lower-risk workloads, such as internal tools and low-usage apps.
• Move non-production environments before production, so the team can test the process safely.
• Add one or two representative complex workloads to early waves to expose real problems.
• Schedule critical systems after the first waves succeed, and avoid financial close, product launches and holiday seasons.

Give every wave exit criteria. The AWS checklist names three: functional tests passed, performance validated and rollback rehearsed. Set your rollback criteria before the first wave too, because Microsoft says to establish them before any migration or deployment.

The application migration to cloud steps sit inside each wave: deploy from code, sync the data, test, cut over and validate. For any wave that touches production, run that cutover through steps 5 and 6.

Train the team before the first wave. Microsoft's organization guide says to give every team the training, documentation and onboarding materials it needs to understand its role.

Work out transfer time before you commit to dates. Google Cloud's transfer guide says 100 TB takes over 10 days online at 1 Gbps and over 100 days at 100 Mbps, which is where an offline device such as Transfer Appliance becomes worth considering. Microsoft offers Azure Data Box for the same job. Also keep the time a workload spends split across two environments short, as Microsoft recommends, because every link between them is one more thing to break.

Step 5: Rehearse the cutover, then run it

Rehearse each production cutover first, timed, with an owner for each step, then run it for real. Use the rollback triggers you agreed before the first wave, and roll back if one fires.

Choose the method by how much downtime the workload can take. Microsoft's planning guidance separates migration with downtime, which is simpler, from near-zero downtime migration, which relies on continuous replication and needs more setup and testing. Near-zero is not zero: in Microsoft's execution guide, writes still pause for the final sync. A near-zero cutover runs in this order:

1. Freeze changes. Block releases to the source system in your pipeline, with a written path for emergency fixes.
2. Lower the time to live (TTL). Shorten it on your DNS records well ahead, so the switch and any reversal take effect quickly.
3. Start replication. Use the database's native replication and confirm the first full sync finished.
4. Watch the lag. Microsoft's rule is not to go on until replication lag is zero.
5. Copy files and objects. While replication is stable, move unstructured data to the new storage, so less is left for the final cutover.
6. Pause writes. Go read-only in a low-traffic window, because writes during the final sync risk data loss.
7. Finish the sync. Copy anything changed after the pause, then confirm no transactions are pending and replication has fully caught up.
8. Validate the data. Row counts are a quick check, but Microsoft prefers checksums and hash functions.
9. Switch traffic. Make the DNS switch, update load balancers and test the critical paths from end to end.
10. Watch closely. Microsoft says to monitor performance, errors and user access for the first 24 to 48 hours.

Any sync lag left at the moment of the switch means writes that never reach the new database. That is why the last check comes after writes stop.

TTL needs the same care. Amazon Route 53's guide to moving DNS says the typical TTL for a name server (NS) record is 172,800 seconds, or two days, and that without lowering it a domain could be unavailable for up to two days if something goes wrong. It recommends 60 to 900 seconds, then waiting out the old value. Records that point to your servers follow the same logic: the new TTL only counts once the old one has expired.

Rollback criteria to agree in advance

With no trigger agreed, a failed cutover turns into a debate while users wait. Microsoft says to decide with stakeholders what counts as a failed deployment, such as failed health checks, poor performance, security issues or unmet success metrics. Put a number beside each one, name who can make the call, and test the rollback in staging.

Two targets help set those numbers. AWS defines the recovery time objective (RTO) as the longest acceptable delay before service is restored, and the recovery point objective (RPO) as the longest acceptable time since the last recovery point.

Rollback also has an expiry point. Once the new system accepts writes, the old database falls behind, so going back means either copying those writes back or losing them. Decide before cutover which one you accept and how long that decision stays open.

Step 6: Optimize, then shut down the old environment

Keep the old environment as a fallback through stabilization, then tune the new one and switch the old one off. Until you do, you are paying for both.

Microsoft advises keeping the source available, with the ability to revert DNS, and announcing success only once application owners, testers and business stakeholders confirm the workload is stable. Compare results with the baseline from step 1 and the KPIs from step 2. Then tune: the AWS checklist suggests right-sizing instances, enabling autoscaling and matching storage classes to access patterns.

Shutting down deserves its own short list. Export any data you must retain, revoke credentials, remove old DNS records and firewall rules, cancel the contracts and confirm the last invoice. A server left running is a cost, and also an unpatched system that nobody watches. Record what the migration taught you before the next wave starts.

Tools and exit fees by cloud, as of October 2026

Each provider has its own discovery, server and database tools, and all three offer free data transfer to customers who leave, with conditions. Check both before you copy a tool list or a budget line from an older checklist.

Migration tools by cloud

Each cloud has its own tool for each job, and these are the names each provider documents today, after recent changes on AWS. On AWS, discovery runs in AWS Transform, servers move with AWS Transform MGN and databases with AWS Database Migration Service (DMS). On Azure, Azure Migrate handles discovery and servers, and Azure DMS handles databases. On Google Cloud, use Migration Center for discovery, Migrate to Virtual Machines for servers and Database Migration Service for databases.

AWS Migration Hub stopped accepting new customers on November 7, 2025, and AWS Application Discovery Service is also closed to new customers. AWS points to AWS Transform for both, and documents its server tool as AWS Transform MGN.

Database tools cover specific engines: Azure DMS, for example, says it currently supports SQL Database modernization. Confirm your engine and version before you plan around one.

What it costs to move data out

Data leaving a cloud is billed as data transfer out, or egress, and all three providers have an exit offer as of October 2026. AWS offers free transfer out to eligible customers who move all their data, or all of one service, off AWS. Azure offers free egress when leaving, with a credit to claim above 100 GB a month. Google Cloud offers free transfer when you exit and end your agreement for that service.

Outside those programs, ordinary rates apply. As of October 2026, AWS S3 pricing and Azure bandwidth pricing each include the first 100 GB a month. Azure then lists $0.087 per GB for the next 10 TB from North America or Europe over Microsoft's premium global network.

Apply before you move. As of October 2026, the AWS FAQ says not to start until your credit request is approved, and to submit it at least two months before your planned start. The Google Cloud exit program needs an Exit Notice before any data you expect credited, then 14 days pass before a 30-day window to start the move. Build that lead time into your wave dates.

The AWS exit terms give eligible customers outside the EU 180 days to finish the move, and Google Cloud credits the transfer cost on the final invoice for internet transfers. These are exit programs, not a discount on running two clouds side by side, so ordinary rates can still apply if only part of your data leaves.

In the EU, the European Commission says the Data Act removes switching charges, including data egress charges, from January 12, 2027. Until then, providers may still charge for the costs of switching.

How we run cloud migrations

We start with the inventory and the rollback plan. Our cloud migration consulting covers the plan, the data sync, the rehearsal and the cutover itself, on AWS, Azure or Google Cloud, for teams moving between providers or off a single server.

Some moves need a short planned window, and we say so early. Everything we produce stays in your repository and your docs. The work is led by Thanos Gkanas, our co-founder and head of engineering. Every engagement is under an NDA, and the IP is always yours.

Frequently asked questions