Cloud migration checklist: dependencies, cutover, and rollback

A cloud migration checklist turns an application move into a series of decisions you can verify: what is moving, what it depends on, how the data stays consistent, when traffic can switch, and how service will recover if something fails. Each checkpoint needs an owner, evidence, and a clear reason to stop.

Use this checklist for an application or workload moving from on-premises infrastructure or another cloud provider. For moving folders between storage accounts, our cloud-to-cloud file-transfer guide covers tools and destination-copy checks. An application migration also involves identity, networking, databases, background jobs, and operational responsibility.

1. Define the scope and cloud migration strategy

Write down the workload name, business owner, technical owner, source environment, target environment, and intended outcome. List what stays behind. A customer portal may move while its identity provider, payment service, and reporting database remain elsewhere.

Choose the approach for each workload. Google Cloud's migration guidance distinguishes rehosting with minimal changes, replatforming with selected changes, and deeper application redesign. Moving and redesigning at the same time expands the set of things you must test.

Set measurable acceptance criteria

Replace “works in the cloud” with observable outcomes: named user journeys pass, data checks reconcile, response times stay within an agreed threshold, and the operations team can restore service. Record the current baseline under representative load so the comparison is meaningful.

Separate the maintenance window from recovery objectives

AWS defines RTO and RPO around tolerable interruption and data loss. Recovery time objective (RTO) is the acceptable time to restore service; recovery point objective (RPO) expresses the acceptable age of the recovered data. These are requirements to test, not guarantees from a backup product.

Document the planned migration outage separately. State whether the cutover must preserve every acknowledged transaction, and how you will prove it. Agree on these limits with the people responsible for the service before selecting a migration method.

2. Map dependencies before choosing migration waves

Inventory the application, data stores, infrastructure, and connections between them. Google's migration-planning documentation places workload discovery and dependency mapping before grouping work into migration waves.

Check beyond the main server list:

• Identity providers, service accounts, certificates, encryption keys, and secret locations.
• DNS names, firewall rules, allowed IP addresses, private routes, and third-party callbacks.
• Databases, shared file systems, object storage, and local directories used as persistent storage.
• Queues, scheduled tasks, email delivery, reporting jobs, and monitoring agents.
• Licenses, supported operating systems, runtime versions, and external support contacts.

For each connection, record its direction, owner, and expected behavior during the move. A service that starts successfully can still fail when its nightly job calls an overlooked database. Group tightly connected components where practical, or test the connection that will span the old and new environments.

3. Prepare the target cloud environment

Check that the destination can run the workload before scheduling production cutover. Confirm regional availability, service quotas, processor architecture, operating-system support, storage behavior, and required licenses. Test the selected configuration rather than assuming that similarly named resources behave identically.

Validate access, networking, and configuration

Microsoft's workload-preparation guidance calls for compatibility checks and tests of authentication, connectivity, and functionality. Include both a normal user's journey and service-to-service access in your checks.

Verify that the migration team can reach the necessary systems without sharing administrator passwords. Store secrets through the approved mechanism, check certificate names and expiry dates, and confirm that logs and alerts reach the people on call. Keep the tested infrastructure and configuration definitions under version control.

Budget for the overlap period

Estimate the cost of running both environments, transferring data, keeping backups, collecting logs, and obtaining support. Assign an owner to each temporary resource and a review date. Cloud migration does not establish a saving by itself; compare the actual operating cost after stabilization with the original baseline. Use our compute pricing guide to compare the full configuration cost, including running time and any separate storage or transfer charges.

4. Plan a consistent data migration

Choose how each database, file store, and queue will reach the destination. A full copy during a planned outage is simpler than continuous replication, but it may require a longer interruption. Replication can reduce the final transfer, while adding configuration, monitoring, and compatibility work.

Record where writes are allowed at every stage. Include background jobs and integrations that can change data even when the user-facing application is in maintenance mode. Define how you will pause those writers and confirm that pending work has reached the intended state.

Check consistency across components

A storage snapshot may miss data still held in memory. For example, the Amazon EBS snapshot documentation explains that snapshots capture data written to the volume, which may exclude application or operating-system caches. Use the database or application's documented backup procedure and coordinate related files with it.

For an application that stores uploads separately from database records, test that restored records still point to the right files. Copying both components successfully does not prove that they represent a compatible point in time.

Reserve time for data validation

Compare schemas, record counts, relevant contents, and business totals using methods suitable for the data. Counts alone cannot detect a changed value in an otherwise equal-sized table. AWS DMS validation, for example, compares source and target rows for supported databases and consumes additional resources and time.

Document exclusions, transformations, and unresolved mismatches. The data owner should decide whether the evidence is sufficient to proceed. Keep a record of the final synchronization point so later checks refer to the same state.

5. Prove recovery and write the rollback plan

Restore a backup into an isolated environment and run the critical application checks there. Record the backup identifier, credentials and keys needed, elapsed time, and result. Our cloud backup guide explains the distinction between retaining a copy and having a usable recovery process.

The rollback plan needs named decision-makers, failure triggers, steps, and a deadline. Include time to execute the reversal and verify service before the allowed outage ends. Test access to the source environment instead of assuming it will still be available.

Plan for writes accepted at the destination

AWS separates rollback before and after new data arrives. Once users have written to the destination, the source database may be stale. Redirecting traffic alone does not preserve those changes.

Agree on a tested way to reconcile destination changes, restore them, or repair the new environment. Record which system is authoritative and prevent unintended writes to both copies. If the recovery path cannot preserve accepted transactions within the agreed limits, resolve that gap before enabling production writes.

6. Rehearse the complete migration process

Use a representative environment and data volume to rehearse the sequence, including rollback. Measure the steps that determine the outage: stopping writes, final synchronization, validation, traffic changes, and restoration. A small sample transfer will not establish the duration of a much larger production move.

Test sign-in, permissions, a complete business transaction, uploads, reports, and background processing. Check expected load, failure alerts, and the first scheduled job after cutover. Make sure test activity cannot send real customer emails, create charges, or trigger other production effects.

Turn the rehearsal into a runbook. Each step should state who acts, what they do, how success is checked, and what happens on failure. Have someone other than its author follow it and resolve unclear instructions before the production window.

7. Make an explicit go/no-go decision

Microsoft's migration-planning guidance recommends tested rollback procedures, measurable checkpoints, and defined authority. At the readiness review, require evidence rather than a verbal “ready.”

• Scope: the workload and dependency owners have confirmed what will move.
• Target: access, connectivity, monitoring, and critical user journeys pass.
• Data: synchronization and validation meet the agreed criteria.
• Recovery: a restore and the relevant rollback path have been rehearsed.
• People: operators, decision-maker, support contacts, and communications are available.
• Time: enough of the change window remains to recover and verify service.

Record the decision, outstanding risks, and who accepted them. An unresolved critical dependency or untested recovery path should keep the migration pending.

8. Cut over using the approved sequence

Freeze unrelated deployments, notify the agreed contacts, and confirm the runbook version. Stop or control the source writers as planned, complete the final data synchronization, and check the destination before directing production traffic to it. Microsoft's execution guidance describes both planned-downtime and replication-based approaches.

Account for cached routes and existing connections

A DNS change is not an immediate switch for every client. DNS TTL controls caching, and local caches can delay visible changes. Prepare any TTL adjustment in advance, account for existing cached records, and observe traffic reaching both environments.

Apply the tested policy for old connections and background workers. Confirm the authoritative write location before enabling production writes, then run the acceptance checks again. If a stop condition occurs, the named decision-maker should use the documented rollback or repair path.

9. Stabilize the workload and verify operations

Check application errors, latency, resource use, queue depth, failed jobs, and user reports against the baseline. Confirm that backups now cover the destination and that its restore procedure works. Assign owners to defects rather than treating successful traffic routing as completion. Once the workload is stable, use our monthly cloud cost optimization checklist to compare recurring spend and cost per completed job with the original baseline.

Choose an observation period that covers the workload's relevant business cycle. A daily process may be visible quickly; a monthly report requires another way to test or observe it. Keep the source protected, with access restricted and obsolete writers disabled, while the agreed fallback period remains open.

10. Retire the source after acceptance

Microsoft's decommissioning guidance separates acceptance from removal of the old environment. Obtain the workload owner's approval, preserve required records and recoverable backups, and confirm that no remaining service depends on the source.

Then remove obsolete routes, accounts, temporary migration access, and unneeded resources through the approved process. Review licenses, subscriptions, storage, and monitoring so abandoned components do not keep generating bills or alerts. Update the architecture record, support instructions, and recovery documentation.

Example: a small application migration with a rollback deadline

This is a hypothetical planning example, not an executed migration or a benchmark. Consider an appointment service with a web application, database, uploaded documents, and a worker that sends notifications.

Before the change window

The team rehearses a consistent database-and-files transfer, tests sign-in and appointment creation, and prevents test notifications from reaching customers. It records how to stop the worker, identify the last committed transaction, and restore the source. The application owner requires preservation of every acknowledged booking.

During a 60-minute maintenance window

Suppose the rehearsal requires 25 minutes for rollback and 10 minutes for verification, including the team's contingency allowance. That leaves a latest rollback decision at minute 25: 60 minus 25 minus 10. These numbers are illustrative; use measured timings for your own workload.

If data validation is unresolved at that deadline, the lead stops the attempt while the destination still has no production writes. After destination writes begin, a return to the source requires the separate, rehearsed data-reconciliation path. The earlier rollback timing must not be assumed to cover that different procedure.

Cloud migration checklist questions

How long does a cloud migration take?

Estimate from discovery, remediation, data volume, transfer tests, rehearsals, and the permitted change window. The time needed to copy data is only one part. Use a representative pilot to replace assumptions with measured durations.

Can a cloud migration have zero downtime?

Some architectures support a gradual traffic shift and continuous replication, but the application, database, clients, and routing must all support the approach. Treat a downtime target as something to demonstrate under test. Do not infer it from a provider's availability commitment.

When is the migration finished?

When the workload meets its acceptance criteria, operations can monitor and recover it, and the agreed source-retirement decision is complete. Keep the evidence with the runbook so the next migration starts from what the team learned.

Plan a CPU workload pilot on Hivenet

For an API, background worker, or development service that does not need GPU acceleration, review when a CPU-only VM fits the workload. Confirm the available configuration, location, price, networking, and provisioning route with Hivenet before scheduling the pilot.

Test a representative workload in an isolated environment. Compare response times or job duration, memory use, and total running cost with the source. Include the dependencies that will stay elsewhere, and prove that you can recover the application and its data.

With a self-managed VM, your team operates the application and maintains its software, access controls, and backups. Hivenet's VM and container guide explains the operating-system control each environment provides. Review the billing rules and stopped-instance retention limit when planning the pilot and fallback period.

To scope the next step, talk through your CPU workload with Hivenet. Bring the dependency list, runtime requirements, estimated memory and storage needs, preferred location, and acceptance criteria.

‍