A cloud migration needs an inventory, a cost model, tested backups, a cutover runbook and a decision about rollback. Neither a universal budget nor a standard number of weeks can tell you whether your application is ready to move.
Reviewed 16 October 2026: removed unsupported small-business price and timeline ranges, universal maintenance windows, savings percentages and an unverified retailer anecdote. The checklist retains the planning steps and makes data consistency and rollback conditions explicit.
What is cloud migration?
For this guide, migration means moving an application, dataset or service from its current environment to another cloud environment. It may involve keeping much of the design, changing selected components, rebuilding parts of the application, replacing it with SaaS, or deciding not to move it.
AWS describes several migration strategies, including rehosting, replatforming, refactoring, repurchasing, retaining and retiring. These are options to assess, not a ranking from cheapest to best. Rehosting can preserve existing limitations, while refactoring introduces a different engineering project and risk profile.
Phase 1: Assessment
Request an inventory before approving a destination or date.
| Inventory | Questions to answer |
|---|---|
| Applications and owners | What runs, who uses it, and who can approve a change? |
| Data | Size, growth, sensitivity, retention, consistency needs and export format? |
| Dependencies | Databases, DNS, payment services, email, identity, APIs and network allowlists? |
| Constraints | Software licences, supported versions, hardware and contract restrictions? |
| Operations | Monitoring, support hours, deployment process and tested recovery procedure? |
| Baseline | Current cost, performance, error rates and important transaction behavior? |
Set acceptable service interruption and data loss with the business owner. Confirm that the people handling the migration can access the registrar, cloud accounts, repositories, backup systems and encryption keys they need.
For an existing cloud bill, the cloud-cost guide helps establish a baseline without assuming a fixed savings percentage.
Phase 2: Planning
Group systems according to dependencies and data flows. A pilot can reduce uncertainty, but an arbitrary order such as “databases before applications” is unsafe when components depend on one another. Identify what must move together and what latency is acceptable while environments are split.
AWS’s pre-cutover guidance recommends documenting connectivity, dependencies, timing, owners, testing and rollback in a runbook. Rehearse that runbook to establish your own duration estimates.
Build a quote from identifiable work rather than an industry average:
- Assessment and remediation tasks, estimated hours and rates.
- Infrastructure setup, testing, training and documentation.
- Data export, transfer, storage, replication and import charges.
- Parallel operation of old and new services.
- Licence, contract and support changes.
- Work to restore or reconcile data if rollback is required.
- A separately stated contingency based on unresolved risks.
Use the migration cost calculator as a scenario worksheet, not a supplier quote or evidence of a normal market price. Verify the assumptions against your actual inventory and provider terms.
Define acceptance criteria before moving: critical functions work, data reconciliation passes, performance meets agreed targets, access controls are checked, and support and recovery are ready. A migration need not make everything faster to be successful if another documented goal justifies it.
Phase 3: Preparation
- Restore a representative backup into an isolated environment.
- Confirm the backup includes data, configuration and recovery dependencies.
- Protect company-owned destination accounts and assign named access.
- Prepare networking, DNS, certificates, monitoring and required integrations.
- Test the target with representative workload and business transactions.
- Record the cutover, acceptance and rollback decision makers.
- Communicate the maintenance window and support contacts.
- Rehearse timing and update estimates from the results.
The Backup Health Check can prompt questions, but its result cannot establish that your data is recoverable. A restore test provides different and necessary evidence.
Phase 4: Migration execution
Have the technical owner document how new writes are handled: pause them, replicate them or use an application-specific transition. Confirm final synchronization before routing users to the destination. Test critical functions and integrations, not only whether the homepage opens.
AWS’s cutover guidance distinguishes rolling back before new writes from rolling back after the new environment has received transactions. Redirecting traffic to an old database after new orders arrive can lose or conflict with those orders. A usable plan must explain data reconciliation or replication and the conditions where fixing forward is safer.
A low-interruption migration may be possible for a particular application, but replication, application changes and testing are prerequisites to assess. Do not promise zero downtime or a standard four-to-eight-hour window without validating the specific system.
Phase 5: Post-migration
Check transaction success, error rates, latency, scheduled jobs, backups and billing. Assign owners to issues and monitor through the workload’s relevant cycle, which might include invoicing, payroll or a seasonal peak.
Keep the old environment only as long as the agreed recovery, retention, security and contract plan requires. Leaving both running indefinitely can create cost and access risks. Keeping it switched on is not sufficient rollback protection if its data is stale.
Decommission after documented acceptance, required data retention, tested recovery and an agreed rollback closure decision. Revoke unused access, remove routes and secrets, cancel resources and check the next bill. There is no universal one-week or thirty-day decommissioning rule.
Common challenges
When timing or cost changes, identify the dependency or assumption that changed and update the plan. When performance falls, compare it with the baseline and investigate the limiting component. When tests fail, use the pre-agreed stop, rollback or fix-forward criteria rather than letting the maintenance window drift without a decision.
When to get help
Bring in relevant experience where data consistency, unfamiliar platforms, licensing, regulation or availability requirements exceed the team’s capability. Agree concrete deliverables and responsibilities. The server-management evaluation guide helps compare operational proposals, and the cloud architecture guide covers the destination design.
