What should a cloud migration checklist include?

Include scope, dependencies, data, access, licensing, backups, target validation, cutover order, acceptance tests, rollback criteria, monitoring, and decommissioning.

Should a small team move everything at once?

Usually no. Start with one well-understood workload that has clear users, data boundaries, ownership, success criteria, and a practical rollback path.

What is the difference between rehosting and replatforming?

Rehosting moves the workload mostly as-is. Replatforming changes selected infrastructure components while keeping the application largely intact.

How do I reduce migration downtime?

Build the target early, pre-sync data, rehearse the runbook, freeze writes when required, complete a final sync, and prepare reversible routing changes.

What should trigger a migration rollback?

Use predefined conditions such as failed authentication, data-write errors, unavailable critical integrations, unacceptable latency, or an exceeded migration window.

How should rollback handle new data created after cutover?

Plan whether writes remain frozen, target changes are synchronized back, or a defined data-loss window is accepted. The method must match the workload’s RPO.

When can the source environment be decommissioned?

After business approval, successful normal usage, verified backups and restore, stable monitoring, clean DNS and access records, and the agreed warranty period.

How does Raff support workload migration?

Raff provides Linux and Windows Cloud Servers with private networking, storage, object storage, snapshots, and backup options for migration target architectures.

Cloud Migration Checklist: Cutover and Rollback

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.

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.

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.

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.

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:

Text

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.

Define rollback before cutover

Rollback criteria must be specific.

Examples:

users cannot authenticate
data writes fail
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 Cloud Servers can host Linux and Windows migration targets. A practical Raff migration may combine:

Cloud Servers for compute
Private Cloud Networks for internal application and database traffic
Volumes for compatible persistent block storage
Object Storage for files, archives, and backup objects
Data Protection for snapshots and scheduled backups

Choose the target size from the workload’s measured behavior and migration headroom. Verify current plans and product capabilities on the live product pages rather than relying on historical prices.