A cloud migration checklist reduces the chance that a workload moves successfully at the infrastructure level but fails at the business level. The safest migration starts with a complete dependency inventory, a tested target environment, explicit cutover and rollback criteria, and post-migration validation before the source system is retired.
For a small team, the goal is not to move everything at once. It is to move one well-understood workload without losing data, access, integrations, or the ability to recover.
Raff Technologies uses the same principle when thinking about workload migration: make the plan operational before making it ambitious. The most useful migration document is not a long strategy deck. It is a checklist and runbook that tells the team what moves, who owns each task, how success is verified, and what happens if the cutover fails.
Cloud migration checklist: quick version
Use this phase checklist before the detailed planning sections below.
1. Discovery
- Migration owner assigned
- Workload boundary defined
- Users and business workflows identified
- Application, database, files, jobs, DNS, certificates, and integrations inventoried
- Licensing and identity dependencies reviewed
- Current backup and restore process verified
- RTO and RPO agreed
2. Plan
- Migration strategy selected: rehost, replatform, refactor, replace, retain, or retire
- Target architecture selected
- Data migration method selected
- Downtime window approved
- Acceptance tests documented
- Rollback criteria defined
- Rollback decision owner assigned
3. Build
- Target compute, storage, network, and access configured
- Firewall and private-network rules validated
- Application and runtime compatibility tested
- Monitoring and logging configured
- Backup policy configured
- Restore tested on the target design
4. Rehearse
- Runbook tested in sequence
- Task owners confirmed
- Expected duration recorded
- Final data synchronization rehearsed
- DNS or routing change rehearsed where practical
- Business acceptance tests rehearsed
- Rollback path tested or validated
5. Cut over
- Readiness confirmed
- Writes frozen where required
- Final backup completed
- Final data synchronization completed
- Target services started and checked
- DNS, load balancer, or user access path changed
- Acceptance tests passed
- Migration owner approved continuation
6. Validate
- Login and authorization work
- Expected records and files exist
- Read and write workflows succeed
- Integrations and notifications work
- Scheduled jobs run
- Monitoring and alerts are active
- Backups complete successfully
- Performance is within the agreed range
7. Roll back or stabilize
- Rollback criteria checked explicitly
- New data created after cutover is accounted for
- Source remains controlled during the warranty period
- One environment is clearly authoritative
8. Decommission
- Business owner approves the migration
- Target backups have been restored successfully
- Warranty period is complete
- Old credentials, firewall rules, and DNS records are removed
- Data retention requirements are met
- Old licenses and subscriptions are closed where appropriate
Cloud migration plan template
A useful cloud migration plan can fit into one shared table. Copy this structure into your project tracker, spreadsheet, or runbook.
| Field | What to record |
|---|---|
| Workload | Application or service being moved |
| Business owner | Person who approves business readiness |
| Technical owner | Person responsible for the migration |
| Users | Teams, customers, or systems that depend on it |
| Source | Current server, provider, region, or environment |
| Target | New VM, service, network, storage, or platform |
| Dependencies | Database, DNS, APIs, file shares, identity, jobs, licensing |
| Data migration method | Offline copy, pre-sync + delta, replication, export/import |
| Downtime window | Approved cutover period |
| RPO | Maximum acceptable data loss |
| RTO | Maximum acceptable recovery time |
| Acceptance tests | Checks that prove the workload works |
| Rollback trigger | Specific condition that stops the migration |
| Rollback method | How traffic, users, and data return to the source |
| Decision owner | Person authorized to continue or roll back |
| Warranty period | Time before the source is retired |
The template should be specific enough that another engineer can understand the migration state without relying on memory or chat history.
Migration begins with scope, not server provisioning
“Move the application to the cloud” is not a complete scope.
Define exactly what is moving:
- application runtime;
- database;
- files and uploads;
- scheduled jobs;
- DNS records;
- certificates;
- user accounts;
- secrets and API keys;
- monitoring;
- backups;
- integrations;
- licensing dependencies.
The migration boundary should be clear enough that the team can say what remains on the source system and what must work on the target system.
Choose the migration strategy
Common migration strategies include:
| Strategy | What changes | Best fit | Main risk |
|---|---|---|---|
| Rehost | Move the workload mostly as-is | Stable applications needing a faster move | Carries old design problems forward |
| Replatform | Change selected infrastructure components | Workloads that benefit from a new database, proxy, storage, or runtime model | More testing and operational change |
| Refactor | Redesign application architecture | Workloads whose current design blocks scale or reliability | Highest delivery risk and effort |
| Replace | Move the business process to SaaS or another product | Commodity workflows that are expensive to operate internally | Migration and vendor-dependency trade-offs |
| Retain | Keep the workload where it is | Hardware-linked, unsupported, or low-value systems | Continued responsibility for the old environment |
| Retire | Decommission the workload | Duplicated or unused systems | Hidden users or dependencies may remain |
Small teams usually reduce risk by separating migration from modernization. Rehost or lightly replatform first when the workload is stable, then improve the architecture after the move has been validated.
For a narrower provider-to-provider VM move, see VPS Migration Checklist. It covers server inventory, data synchronization, DNS cutover, and rollback without assuming an application redesign.
Select a safe first workload
A good first migration has:
- a known owner;
- documented users;
- clear data boundaries;
- limited dependencies;
- a measurable success condition;
- a practical rollback path.
Good early candidates often include a website, staging environment, internal dashboard, automation service, isolated business application, or self-hosted tool.
Workloads such as email, identity infrastructure, shared file systems, payment systems, and undocumented legacy software usually require deeper discovery before cutover.
When the source is an office server with multiple business roles, use Office Server Replacement Guide to decide which workloads should move first and which should remain local.
Build the dependency inventory
A migration fails when an undocumented dependency remains connected to the old environment.
Inventory these areas:
| Area | Capture |
|---|---|
| Application | Version, runtime, packages, startup process, service accounts |
| Database | Engine, version, size, extensions, users, connection strings |
| Files | Paths, permissions, ownership, growth, sensitive data |
| Network | Public IPs, private IPs, firewall rules, allowlists, outbound access |
| DNS | Records, TTLs, certificates, redirects, mail-related records |
| Automation | Cron, Task Scheduler, CI/CD, report jobs, cleanup jobs |
| Integrations | APIs, webhooks, identity providers, CRM, email, payments |
| Access | SSH keys, RDP users, VPN, admin accounts, emergency access |
| Licensing | Windows, database, commercial software, activation requirements |
| Recovery | Backup method, retention, restore procedure, current RTO and RPO |
| Operations | Logs, metrics, alerts, dashboards, escalation contacts |
The inventory does not need to be long. It must be complete enough to predict what will break when the source endpoint changes.
Define success before the move
A migration is successful when business workflows operate correctly—not when the target VM boots.
Define acceptance tests such as:
- users can sign in;
- expected records and files exist;
- read and write operations succeed;
- uploads and downloads work;
- scheduled jobs run;
- notifications and webhooks arrive;
- certificates and redirects are correct;
- backup jobs complete;
- monitoring and alerts are active;
- performance remains within an acceptable range.
Assign an owner to each test. The person who understands the business workflow should validate it, not only the person who built the target server.
Establish RTO, RPO, and the migration window
Recovery Time Objective defines how long the workload can remain unavailable.
Recovery Point Objective defines how much recent data can be lost.
These objectives affect the migration method:
| Requirement | Migration implication |
|---|---|
| Downtime is acceptable | Offline copy and all-at-once cutover may be simplest |
| Downtime must be short | Pre-sync data and perform a final delta sync |
| No writes can be lost | Freeze writes or use a controlled replication method |
| Rollback must be fast | Keep the source ready and make traffic routing reversible |
| Data changes after cutover | Plan how new target data would be handled during rollback |
Do not choose a maintenance window only from technical convenience. Confirm business users, application owners, and support contacts will be available.
Protect the source before migration
Before changing production:
- take a current backup;
- verify the backup completed;
- restore it into a separate environment;
- document the restore duration;
- record current configuration;
- preserve access to DNS, certificates, credentials, and licensing information.
A snapshot can provide a useful rollback point, but application-consistent recovery may also require database-aware backups, file copies, and exported configuration.
For a practical way to verify that a recovery point can actually be restored, use the Restore Testing Checklist for Production VMs.
Build and validate the target environment
Create the target before the cutover window whenever possible.
Validate:
- operating-system and runtime compatibility;
- CPU, memory, storage, and network sizing;
- firewall and private-network rules;
- administrator access;
- application configuration;
- database connectivity;
- certificate handling;
- logging and monitoring;
- backup policy;
- time synchronization;
- outbound dependencies.
Test with production-like data where policy permits. Remove or protect sensitive information in non-production environments.
Rehearse the migration
A rehearsal reveals missing tasks and unrealistic timing.
The rehearsal should record:
- task order;
- expected duration;
- owner;
- prerequisite;
- validation method;
- rollback action.
A cutover runbook can be a simple shared table. The value comes from explicit sequence and ownership, not from document length.
Rehearse the most failure-prone activities:
- final data synchronization;
- application startup;
- database connection changes;
- DNS or load-balancer changes;
- SSH or RDP access;
- core business tests;
- rollback routing.
Decide between all-at-once and phased cutover
All-at-once cutover
Traffic and users move to the target in one event.
It fits workloads where the application and data layers must move together or where running both environments is impractical.
The main risks are concentrated downtime and a narrower decision window.
Phased cutover
Traffic, users, locations, or components move gradually.
It can reduce exposure by validating the target under partial load. It also adds complexity when data must remain consistent across both environments.
Use phased cutover only when the application, routing, and data model support it safely.
Define the cutover sequence
A practical cutover sequence is:
Confirm readiness ↓ Freeze writes or ingestion where required ↓ Take final backup ↓ Complete final data synchronization ↓ Start and validate target services ↓ Change DNS, load balancer, or user access path ↓ Run acceptance tests ↓ Monitor and approve
The exact order depends on the workload. A database-backed application may need the app and database cut over together. A static site may require only final file synchronization and DNS change.
DNS planning
DNS is often part of cutover, but it should not be the only rollback mechanism considered.
Before migration:
- confirm who controls the domain;
- inventory all relevant records;
- understand current TTLs;
- prepare target records;
- confirm certificates cover the required hostnames;
- test the target through a temporary hostname or local host override where practical.
Lowering TTL can shorten how long resolvers cache an old record, but it does not create instant global change. Plan for mixed traffic during propagation.
Review DNS for Cloud Applications when A/AAAA records, aliases, TTLs, and failover behavior need a dedicated cutover plan.
Define rollback before cutover
Rollback criteria must be specific.
Examples:
- users cannot authenticate;
- data writes fail;
- a critical integration is unavailable;
- error rate exceeds the agreed threshold;
- latency is unacceptable for core workflows;
- data validation fails;
- recovery exceeds the approved migration window.
Assign one person to decide whether to fix forward or roll back.
The rollback plan must also address data created after cutover. Redirecting traffic to an old database can lose new transactions if the source became stale.
Possible strategies include:
- keeping the target read-only until acceptance;
- freezing writes during validation;
- synchronizing target changes back before rollback;
- accepting and documenting a defined data-loss window.
The correct method depends on the workload’s RPO and data model.
Validate immediately after cutover
Run functional and operational tests.
Functional validation
- login and authorization;
- create, read, update, and delete workflows;
- file upload and download;
- search and reporting;
- notifications and integrations;
- payment or customer-critical actions.
Operational validation
- CPU, memory, disk, and network behavior;
- logs and error tracking;
- backup execution;
- monitoring and alerts;
- certificate validity;
- scheduled jobs;
- security exposure;
- expected billing resources.
Compare target performance with a pre-migration baseline where possible.
Keep a warranty period
Do not immediately delete the source environment.
Keep it available for a defined warranty period while:
- normal business cycles complete;
- scheduled jobs run;
- backups execute;
- users report issues;
- logs and performance stabilize.
During this period, make it clear which environment is authoritative. An old environment that remains writable can create data divergence.
Decommission deliberately
Retire the source only after approval.
Confirm:
- the target passed acceptance testing;
- business owners approved the move;
- new backups were restored successfully;
- monitoring is active;
- data retention requirements are satisfied;
- DNS and firewall records are clean;
- old credentials and access paths are removed;
- source data is securely retained or deleted according to policy;
- licenses and subscriptions are closed where appropriate.
Decommissioning is part of the migration, not an unrelated cleanup task.
Windows workload considerations
Windows migrations may require additional review for:
- Windows Server licensing path;
- Remote Desktop access and user count;
- RDS requirements;
- SQL Server licensing;
- application vendor support;
- domain or identity dependencies;
- mapped drives and file permissions;
- services and Task Scheduler jobs;
- hardware-bound activation.
Confirm technical compatibility and licensing before the cutover window. A Windows application that launches successfully may still have unsupported licensing or multi-user requirements.
How this applies on Raff
Raff can host Linux and Windows migration targets. A practical Raff migration may combine:
- Raff VM for compute;
- Linux VM for Linux applications and web services;
- Windows VM for Windows workloads;
- VPC for private application and database traffic;
- Volumes for compatible persistent block storage;
- Object Storage for files, archives, and backup objects;
- Managed Databases when the database should have a separate managed boundary;
- Data Protection for snapshots and scheduled backups.
Choose the target size from measured workload behavior plus enough migration headroom. Verify current plans and product capabilities on the live pricing page and product pages rather than relying on historical prices embedded in an evergreen guide.
