Here is a made-up example. A small team runs one web app on two old servers. One server holds the app. The other holds the database. A nightly job sends reports by email. The team wants to move all of it to a public cloud. Their question: what should we check before we switch real users over?

We read the migration guides from AWS, Microsoft Azure and Google Cloud. Here are seven checks, each tied to the page it comes from.

Word key

  • Workload: an app plus the servers, data and settings it needs to run.
  • On-premises: servers you own and run yourself, for example in your own office or data center.
  • Dependency: anything your app talks to. Think of a database, an outside API, a login service or a DNS record.
  • Cutover: the moment real users switch from the old system to the new one.
  • Rollback: going back to the old system when the new one fails.
  • RTO (Recovery Time Objective): the longest your service may be down before it must be back.
  • RPO (Recovery Point Objective): how much recent data, measured in time, you can afford to lose.

Check 1. Do you know everything the app touches?

Google Cloud splits a migration into four phases: assess, plan, deploy and optimize. The first phase, assess, means listing your apps, finding their dependencies, working out total cost of ownership and measuring how the apps perform today.

Microsoft's Azure guide says to map internal and external dependencies before you group anything. It also says to check that each group has its supporting parts, such as load balancers, DNS records and caching layers. Parts that talk to each other closely and need fast replies should move together.

Our advice: write one list per app. Put every server, database, scheduled job, outside API and DNS name on it. In our example, the nightly report job is easy to forget, because nobody sees it run.

Check 2. Which kind of move fits this app?

AWS names seven migration strategies, known as the "7 Rs":

  1. Retire: switch the app off, because nobody needs it.
  2. Retain: keep it where it is for now.
  3. Rehost ("lift and shift"): move it to the cloud with no changes.
  4. Relocate: move many servers at once to a cloud version of the same platform.
  5. Repurchase: swap it for a different product, often a SaaS tool you rent.
  6. Replatform: move it and make some changes, such as using a managed database.
  7. Refactor or re-architect: redesign it to use cloud-native features.

AWS calls refactor the most complex and costly option. For large migrations, AWS suggests rehosting, relocating or replatforming first, then improving the app after the move. Google Cloud notes the trade-off. A rehost is usually the quickest move, but the app is not tuned for the cloud afterwards.

In our reading, a small app with no urgent need for change is often a good rehost candidate. The choice is still yours to make per app.

Check 3. What does "working" look like today?

Google Cloud's assess phase includes setting performance benchmarks for each app. Azure's guide asks you to define success criteria, such as performance numbers and user acceptance checks, before the move.

Our advice: measure the old system for at least a normal week. Note response times, error rates and peak hours. After cutover, compare the new system against those same numbers. Without them, "it feels slower" is hard to prove or disprove.

Check 4. Who keeps which part safe after the move?

AWS calls this the Shared Responsibility Model. AWS handles security "of" the cloud: the hardware, software, networking and buildings that run its services. You handle security "in" the cloud.

How much you handle depends on the service. On a virtual server like Amazon EC2, you patch the operating system and your apps. You also set up the firewall rules, which AWS calls security groups. On services like Amazon S3, you still manage your data, its encryption options and who has access. Google Cloud describes the same split for its platform.

Our tip: write a short table with one row per service you will use, and one column each for "provider" and "us".

Check 5. How much downtime and data loss can you accept?

AWS defines RTO and RPO in its disaster recovery guide. It also says your organization sets these numbers, based on business needs. A payroll system, for example, may matter much more just before payday than just after it.

Azure's guide gives two ways to migrate. A downtime migration is simpler, but users face a planned outage. A near-zero downtime migration keeps data copying until the switch, but takes more setup and testing.

Our advice: agree on the RTO, the RPO and the downtime window with the app's owner, in writing, before you pick a method.

Check 6. How will the data travel?

Azure lists four ways to move data. ExpressRoute is a private, dedicated link. A VPN is an encrypted tunnel over the internet. Data Box is a physical device that Microsoft ships to you. The plain public internet is meant only for data that is not sensitive. Google Cloud offers similar tools, such as Storage Transfer Service, Database Migration Service and a shipped Transfer Appliance for very large datasets.

Our tip: do a test copy of real data first. It shows how long the full copy will take on your network.

Check 7. Can you go back if it fails?

Azure says to set rollback rules and steps before any migration starts. First, agree on what "failed" means, for example failed health checks, high error rates or slow responses. Then write the rollback steps for that workload. Last, test them in a staging setup, so you know they work.

The same guide gives an order that lowers risk. Move simpler workloads first. Move development and test setups before production. Keep migrations away from busy business periods, such as a product launch or a financial close.

Tick these off before cutover day

  • [ ] Every app has a written list of servers, data, jobs, APIs and DNS names.
  • [ ] Each app has a chosen strategy from the 7 Rs, with a short reason.
  • [ ] You have a week or more of "before" numbers to compare against.
  • [ ] Your team knows which security tasks are yours on each service.
  • [ ] The app owner signed off on the RTO, the RPO and the downtime window.
  • [ ] A test data copy ran, and you know how long the full copy takes.
  • [ ] The rollback plan has clear triggers and passed a test run.
  • [ ] Cutover is set outside your busiest business dates.

Bring these questions to your cloud team or partner

  1. Which dependencies did we find, and which ones might we have missed?
  2. Why did we pick this strategy for this app, and not a simpler one?
  3. Which numbers will tell us the new system works as well as the old one?
  4. Who patches, watches and controls access for each service after the move?
  5. What exactly triggers a rollback, and who makes that call?

Read the docs yourself

Codewave Consulting LLC wrote this checklist from public cloud provider guides. Please treat it as general information, not professional advice about your own systems. Each workload is different, so have a qualified engineer review your own setup, data and risks before you move anything. We are an E-Verified employer. We proudly support H-1B visa sponsorship for qualified resources. Eligibility is reviewed individually; sponsorship does not guarantee a role, selection or government approval.

About us: Our Michigan-based team at Codewave Consulting LLC works as a Direct Vendor for Whirlpool. Next to IT staffing, we work on custom software, cloud migration and infrastructure, AI and workflow automation, and digital product engineering. See what we do at codewaveconsulting.com.