“Move it to the cloud” is easy to say, but a safe migration depends on preparation: workload ownership, dependencies, target architecture, verification and rollback all need explicit decisions. This checklist is tool-agnostic and sized for teams without a dedicated platform department. It complements, rather than replaces, provider and workload-specific guidance.
Quick answer
A lower-risk migration usually uses staged, testable moves rather than one undifferentiated launch event. Inventory the estate, classify each workload, make networking and identity decisions early, define verification and rollback criteria, and monitor technical behavior and cost after cutover. When a step cannot be reversed, document why and require a proportionate recovery and approval plan.
Who this checklist is for
Small and mid-size businesses moving applications, databases or internal tools to the cloud without a platform-engineering team. It doesn't assume a specific provider — the steps are the same whether you're heading to AWS, Azure, Google Cloud or a European alternative.
Phase 1 — Assess
- Inventory everything. Applications, databases, scheduled jobs, integrations, certificates and DNS records all matter. Cross-check owner interviews against DNS, virtualization inventories, monitoring and billing records so the plan is not based on memory alone.
- Classify each workload: retire, retain, rehost, replatform, refactor, rearchitect, replace or rebuild as appropriate. Changing both application behavior and platform in one wave can increase scope and verification needs, so choose the approach from business drivers and workload evidence.
- Find the hard dependencies. Static IP allowlists, on-premises file shares, legacy protocols and hardware licence constraints may materially change the target design. Record owners and validation steps instead of relying on an architecture diagram alone.
- Estimate operating cost with current provider calculators and representative usage assumptions. Include data transfer, backup, logging, support and non-production environments, then define an uncertainty allowance the budget owner approves.
Phase 2 — Plan
- Pick the order of migration: use a representative, lower-consequence workload to test the delivery and operating path before moving a critical one. The first wave should prove the process as well as migrate the workload.
- Define rollback or recovery criteria for every step. “Restore from backup” is incomplete unless restore time, dependencies and data validation have been exercised. An irreversible step requires explicit risk acceptance, recovery planning and an authorized decision owner.
- Decide on networking and identity early (network layout, SSO, secrets management and administrative access). Retrofitting these controls after workload migration adds risk and rework.
- Define success criteria per workload before moving it: what response time, what error rate, what data checks must pass before you call it done. Without this, "done" becomes a feeling instead of a fact.
- Set a freeze window for the final data sync and communicate it early — the business tolerates a planned quiet hour far better than a surprise one.
Phase 3 — Execute
- Use infrastructure as code for repeatable, reviewable environments where the platform supports it. Record any manual step that remains and test whether critical resources can be recreated in an isolated environment.
- Where the architecture permits, migrate or replicate data before directing production traffic. Validate counts, checksums or application-level invariants, then follow the workload-specific read/write cutover sequence.
- Run the old and new systems in parallel and compare outputs where possible. Even a day of shadow traffic catches configuration drift that no test plan would.
- Cut over behind a DNS change with a low TTL (set it down a day or two in advance) so you can retreat in minutes. Keep the old environment running and untouched until the success criteria from Phase 2 have held for an agreed period.
Phase 4 — The week after go-live
- Watch cost dashboards frequently after cutover because usage and telemetry assumptions are now being tested with real traffic. Set budgets and alerts at thresholds approved by the cost owner rather than applying one universal percentage.
- Review alerts that fired vs. incidents that happened; tune both. Alerts that page for non-issues train the team to ignore the one that matters.
- Decommission the old environment through a scheduled, approved change, after rollback and retention requirements have expired. Track parallel-environment cost while both stacks are required.
- Hold a short retrospective: what would you do differently for the next workload? The second migration should be noticeably calmer than the first; if it isn't, the process needs fixing before the third.
Common migration mistakes
- Unnecessarily broad cutovers. Moving many independent workloads in one window concentrates verification, coordination and rollback risk.
- Unplanned rebuilding during the move. Combining migration with major functional change expands scope and requires evidence for both the old-to-new platform transition and changed application behavior.
- Treating cost as a post-launch topic. Architecture, usage shape, data movement, commitments and operational tooling all affect cost. Model them before selecting services and validate the assumptions after launch.
- Leaving security for later. Management exposure, credentials, roles and logging should be part of the target foundation and migration acceptance criteria.
- No owner. A migration with five part-time owners has none. One person coordinates, even if many execute.
The condensed checklist
- Full inventory, including cron jobs, certificates and DNS
- Classify: rehost / replatform / rebuild
- Map hard dependencies (IP allowlists, file shares, legacy protocols)
- Cost estimate with documented assumptions, uncertainty and approved alerts
- Networking, identity and secrets set up first
- Rollback plan and success criteria per workload
- Infrastructure as code from the first server
- Data before traffic; verify with checksums
- Parallel run, then low-TTL DNS cutover
- Daily cost review, alert tuning, scheduled decommission date
Final advice
A migration is a project, not an event. Plan it in small reversible steps, keep the business informed, and don't be afraid to leave some legacy systems where they are — a stable server that costs little and changes never is sometimes the right answer.