# Cloud Migration Checklist for Small Businesses and Nonprofits

> A cloud migration checklist is a step-by-step list of the tasks needed to move workloads safely to Azure, AWS or Google Cloud. It covers inventory and assessment, strategy and business case, landing zone and security setup, a pilot migration, wave-based cutovers with testing and rollback, decommissioning, and post-migration optimization. Following it reduces downtime, surprises and cost overruns.

- URL: https://www.desaiinfo.net/cloud-migration/cloud-migration-checklist
- Publisher: Desai InfoTech (https://www.desaiinfo.net)
- Last updated: 2026-10-17
- Topics: cloud migration checklist, cloud migration plan, cloud migration steps, server migration checklist, migrate to cloud checklist, cloud cutover plan


## Key takeaways

- Inventory every server, application, data store and dependency before choosing a migration approach.
- Build the landing zone with identity, networking, security and cost controls before the first workload moves.
- Migrate a low-risk pilot first to validate tools and runbooks.
- Every cutover needs a test plan, a go or no-go decision and a rehearsed rollback.
- Do not decommission old systems until data, backups and retention requirements are verified.

A cloud migration involves dozens of small tasks across technology, security, people and contracts. Missing one can mean a broken application on Monday morning. This vendor-neutral checklist works whether you are moving to Microsoft Azure, Amazon Web Services or Google Cloud. It is part of our [cloud migration services](https://www.desaiinfo.net/cloud-migration) guidance.

For platform-specific detail, see the [Azure migration checklist](https://www.desaiinfo.net/azure-consulting/azure-migration-checklist), [AWS migration checklist](https://www.desaiinfo.net/aws-consulting/aws-migration-checklist) or [GCP migration guide](https://www.desaiinfo.net/gcp-consulting/gcp-migration-guide).

## What are the phases of a cloud migration?

A cloud migration has seven phases: assess, plan, prepare the landing zone, pilot, migrate in waves, decommission and optimize. The checklist below follows that order.

| Phase | Key output | Typical duration |
|---|---|---|
| Assess | Inventory, dependency map, baseline costs | 1-3 weeks |
| Plan | Strategy per workload, waves, business case | 1-2 weeks |
| Landing zone | Secure, governed cloud foundation | 1-3 weeks |
| Pilot | One workload migrated, runbooks validated | 1-2 weeks |
| Migration waves | Workloads cut over and signed off | 2-12 weeks |
| Decommission | Old systems retired, contracts closed | 1-2 weeks |
| Optimize | Right-sized, cost-controlled environment | Ongoing |

## Phase 1: Assess

Assessment establishes exactly what you have, how it connects and what it costs today. A thorough [cloud readiness assessment](https://www.desaiinfo.net/cloud-migration/cloud-readiness-assessment) covers this in depth.

- [ ] Inventory all servers, virtual machines, operating systems and versions
- [ ] Inventory applications, owners and business criticality
- [ ] Map dependencies: databases, file shares, integrations, ports, scheduled jobs, license servers
- [ ] Collect performance data (CPU, memory, disk, network) over a representative period
- [ ] Measure data volumes and growth rates
- [ ] Document current costs: hardware, licenses, hosting, support, power
- [ ] Review software licensing for cloud eligibility and portability
- [ ] Identify compliance requirements for regulated or sensitive data
- [ ] Assess internet bandwidth at each site

## Phase 2: Plan

Planning turns the inventory into decisions, a schedule and an approved budget.

- [ ] Agree business goals and success measures
- [ ] Choose the target cloud platform and regions
- [ ] Assign a strategy to each workload using the [7 Rs](https://www.desaiinfo.net/cloud-migration/cloud-migration-strategy-7rs)
- [ ] Group workloads into waves by dependency and risk
- [ ] Define recovery time and recovery point objectives for each application
- [ ] Build a total cost of ownership comparison
- [ ] Create a risk register and communication plan
- [ ] Agree maintenance windows with the business
- [ ] Confirm nonprofit program eligibility with providers, if applicable

## Phase 3: Prepare the landing zone

The landing zone is the secure foundation every workload lands in. Build it before migrating anything.

- [ ] Account, subscription or project structure with separate production and non-production
- [ ] Identity integration with single sign-on and multi-factor authentication for all administrators
- [ ] Least-privilege role assignments; no shared admin accounts
- [ ] Network design: address ranges, segmentation, firewalls, private endpoints
- [ ] Site-to-site VPN or private connectivity to remaining offices
- [ ] Policy guardrails for allowed regions, required tags and encryption
- [ ] Centralized logging and security monitoring
- [ ] Backup policies configured and tested
- [ ] Budgets and cost alerts at account or subscription level
- [ ] Infrastructure defined as code where practical

Our [hybrid cloud networking](https://www.desaiinfo.net/networking-services/hybrid-cloud-networking) guide covers connectivity patterns between offices and the cloud.

## Phase 4: Pilot migration

A pilot proves the method on a workload where problems are tolerable.

- [ ] Select a low-risk, representative workload
- [ ] Install and configure migration tooling
- [ ] Replicate, test and cut over following a written runbook
- [ ] Measure performance against the on-premises baseline
- [ ] Record lessons learned and update runbooks

## Phase 5: Migrate in waves

Each wave follows the same pattern: replicate, test, decide, cut over, verify.

**Before cutover**

- [ ] Replication or data sync running and healthy
- [ ] Test migration completed in an isolated network
- [ ] Application owner has tested functionality
- [ ] DNS changes prepared with reduced time-to-live values
- [ ] Users notified of the maintenance window
- [ ] Rollback plan documented and rehearsed
- [ ] Go or no-go meeting held with named decision makers

**During and after cutover**

- [ ] Stop changes on source systems and complete final sync
- [ ] Switch DNS, connection strings and integrations
- [ ] Run smoke tests and user acceptance checks
- [ ] Confirm backups and monitoring are active on new resources
- [ ] Keep source systems available, but powered off or read-only, until sign-off
- [ ] Provide visible support for users on the first business day

Moving large databases or file sets needs its own planning; see the [data migration guide](https://www.desaiinfo.net/cloud-migration/data-migration-guide).

## Phase 6: Decommission

Decommissioning removes cost and security risk, but only after verification.

- [ ] Stabilization period completed with no rollback needed
- [ ] Data verified complete and accessible in the cloud
- [ ] Retention and legal hold requirements met
- [ ] Final backups of source systems archived if required
- [ ] Servers and drives securely wiped or destroyed
- [ ] Licenses, support contracts and hosting agreements cancelled or reassigned
- [ ] Documentation and network diagrams updated

## Phase 7: Optimize

Optimization starts the day the first workload lands and continues indefinitely.

- [ ] Right-size virtual machines based on actual cloud metrics
- [ ] Schedule non-production resources to shut down outside working hours
- [ ] Apply reserved capacity or savings plans for steady workloads
- [ ] Review security posture recommendations
- [ ] Hold a monthly cost review for the first quarter

[Post-migration optimization](https://www.desaiinfo.net/cloud-migration/post-migration-optimization) covers this phase in detail.

## What are the most common cloud migration mistakes?

The most common mistakes are skipping discovery, building without a landing zone and lifting servers without right-sizing.

- Incomplete dependency mapping, causing post-cutover failures
- Weak identity security on new cloud accounts
- Underestimating data transfer time over office internet links
- Forgetting licensing rules for software moved to the cloud
- Decommissioning too early, before data is fully verified
- No owner for cost monitoring after go-live

## How Desai InfoTech uses this checklist

Desai InfoTech runs migrations with this checklist as the backbone, adapted to each client's platform and risk tolerance. To start with a clear picture of your environment, request a [free cloud assessment](https://www.desaiinfo.net/free-cloud-assessment) or [contact us](https://www.desaiinfo.net/contact).

## How to migrate to the cloud: steps

1. **Assess:** Inventory workloads, dependencies, data, licensing and current costs, and document business goals and constraints.
2. **Plan:** Choose a target platform, assign a migration strategy to each workload and group workloads into waves.
3. **Prepare the landing zone:** Configure identity, networking, security policies, logging, backup and budgets in the target cloud.
4. **Run a pilot:** Migrate one low-risk workload end to end to validate tools, runbooks and performance.
5. **Migrate in waves:** Replicate, test and cut over each wave with a go or no-go decision and rollback plan.
6. **Decommission:** Verify data and backups, meet retention requirements, then retire old servers and contracts.
7. **Optimize:** Right-size resources, apply pricing commitments and review security and cost regularly.

## Frequently asked questions

### How long does a cloud migration take for a small business?

Small environments with file shares and a few servers typically take 3 to 6 weeks end to end. Environments with 5 to 15 servers and line-of-business applications commonly take 6 to 12 weeks. Larger estates, multiple sites or applications that need replatforming can take several months. Planning and testing usually take longer than the data transfer itself.

### What is the most commonly missed step in a cloud migration?

Dependency mapping is the step most often underdone. Applications frequently rely on hard-coded server names, scheduled tasks, file shares, license servers, printers or integrations that nobody documented. When one of these is missed, the application fails after cutover. Discovery tools plus interviews with the people who use each application catch most of these.

### Do we need to rebuild Active Directory in the cloud?

Not necessarily. Many small organizations synchronize on-premises Active Directory to Microsoft Entra ID, then gradually move devices and applications to cloud identity. Some legacy applications still need domain services, which can be provided by a managed domain service or domain controller virtual machines in the cloud. The right answer depends on which applications depend on traditional domain authentication.

### Should we migrate everything at once?

Rarely. Migrating in waves, starting with a low-risk pilot, lets the team validate tools and procedures and limits the impact of any problem. Very small environments with only a couple of servers can sometimes move in a single planned weekend, but even then a test migration beforehand is strongly recommended.


## Related

- [Cloud Readiness Assessment: What It Covers and How It Works](https://www.desaiinfo.net/cloud-migration/cloud-readiness-assessment)
- [The 7 Rs of Cloud Migration: Choosing a Strategy for Each Workload](https://www.desaiinfo.net/cloud-migration/cloud-migration-strategy-7rs)
- [Data Migration Guide: Moving Databases and Files to the Cloud](https://www.desaiinfo.net/cloud-migration/data-migration-guide)
- [Post-Migration Optimization for Cost, Performance and Security](https://www.desaiinfo.net/cloud-migration/post-migration-optimization)
- [Azure Migration Checklist for Small Businesses](https://www.desaiinfo.net/azure-consulting/azure-migration-checklist)
- [AWS Migration Checklist for Small Businesses](https://www.desaiinfo.net/aws-consulting/aws-migration-checklist)