Cloud Migration Checklist: What to Do Before You Move

Migrations rarely fail during the migration. They fail because of something that was not discovered beforehand — an application nobody knew depended on a local server, a licence that does not transfer, a data volume larger than the transfer window allowed.

This checklist is the preparation work. It is unglamorous, it takes longer than the move itself, and it is the difference between a weekend cutover and a three-month recovery.

Discovery

• Complete application inventory — everything the business runs, including software one department installed years ago and nobody else knows about.
• For each application: vendor, version, licence terms, whether a cloud version exists, and whether the licence transfers.
• Data inventory — what exists, where, how much, and how fast it grows.
• Identify data with retention or residency obligations.
• Map integrations. Which systems talk to which, and over what.
• Document current authentication. Where accounts live and how users sign in today.

The single most valuable output is the dependency map. Applications rarely stand alone, and the failure mode is moving one thing successfully and breaking three others that quietly depended on it.

Decide the approach per workload

Not everything should move the same way, and deciding per workload rather than wholesale avoids most of the expensive mistakes.

• Rehost — move as-is to cloud infrastructure. Fastest, cheapest to execute, and inherits every existing inefficiency.
• Replatform — move with modest changes, such as a database moving to a managed service. Moderate effort, meaningful ongoing benefit.
• Replace — retire the application in favour of a cloud-native equivalent. Highest disruption, frequently the right answer for file servers and email.
• Retain — leave it where it is. Some applications should not move, and accepting a hybrid outcome is better than forcing one.
• Retire — a meaningful proportion of what a discovery finds is no longer used at all. Every retired application is migration effort saved.

That last category is worth taking seriously. Discovery routinely finds servers running applications nobody has opened in years.

Identity first

Identity is the foundation and should be settled before anything else moves. Decide whether you are running cloud-only identity or a hybrid arrangement synchronised with on-premise Active Directory, and understand the implications of each.

• Clean up before synchronising. Migrating a directory full of stale accounts, duplicate objects and inconsistent naming carries the mess into the new environment permanently.
• Audit group membership and administrative rights while you are in there.
• Plan MFA rollout as part of the migration rather than afterwards. Deploying it during a change everyone already expects is significantly easier than introducing it later as a new imposition.
• Decide how service accounts and shared mailboxes will be handled. These are where migrations get messy.

Network and bandwidth

• Measure current internet capacity and model what post-migration usage will look like. Traffic that used to stay on the LAN now crosses your connection.
• Establish whether a secondary connection is needed. When everything is cloud-hosted, an internet outage becomes a total outage.
• Calculate the initial data transfer time honestly. Terabytes over a modest connection can take weeks, which affects the cutover plan.
• Check latency to the chosen region for anything sensitive to it.

Before cutover

1. Take a verified backup of everything being moved, and confirm it restores. This is your genuine rollback position.
2. Define the rollback plan explicitly — what triggers it, who decides, and how long it takes. A migration without a rollback plan is a one-way commitment.
3. Agree success criteria in advance. What does "working" mean, specifically, and who confirms it.
4. Pilot with a small group. One department, real work, for long enough to surface problems.
5. Communicate to staff: what changes, when, what to do if something breaks, and who to contact.
6. Schedule sensibly. Avoid month-end, quarter-end, and your industry's peak period.
7. Confirm licensing is in place and assigned before cutover rather than during it.

After cutover

• Verify backups in the new environment. Cloud platforms provide availability, not backup — this is a separate arrangement and it is frequently forgotten.
• Right-size resources after 60 to 90 days of real usage data. Initial provisioning is always generous.
• Review security configuration. A new environment starts with defaults, and defaults are rarely what you want.
• Decommission the old environment deliberately, once you are genuinely confident. Not before — and not never, because paying for both indefinitely is a common and expensive outcome.
• Update documentation to reflect what now exists rather than what used to.

The most common post-migration failure is simply stopping at cutover. The environment works, everyone moves on, and nobody verifies backups or reviews the configuration until something goes wrong six months later.