Checklist: move a workload out of the cloud

Who this is for

Checklist: move a workload out of the cloud is for teams taking an application, a batch job, or a platform service off a public cloud and running it on owned hardware, in a colo cage, on a private cloud, or with another provider. It fits workloads with real dependencies: a database, queues, object storage, identity, scheduled jobs, and a network path to users or other systems. It does not cover a single file share or a basic website move.

You will get the most from it if you own the service or run the platform team that supports it. Finance and security leads should join the inventory and the cutover review. The checklist assumes you can freeze changes for a short window and that you have a target environment to test against. If the target is not ready, stop at the inventory and design steps.

Before you begin

Name one accountable owner and one cutover lead. Put the exit decision, target platform, and success tests in a short document that the team can edit. Success tests should cover latency, throughput, backup restore time, and the path for support at 2 a.m. Vague goals like lower cost or more control are not testable.

Export usage and billing data before you change access. Pull the resource inventory from the provider: AWS Resource Groups, Azure Resource Graph, or Google Cloud Asset Inventory. Save cost reports, network flow logs, IAM policies, and tags. These records show what is actually used and what is only attached to the account.

Check the provider agreement for notice periods, data export terms, and early termination terms. Ask finance to model the run rate after the exit, including hardware refresh, colo power, licenses, support contracts, and staff time. A move that cuts one bill and adds hidden ones is not a win.

The checklist

Work from the outside in. Start with users, DNS, and identity, then move to data, then the compute layer. Run the checklist twice: once as a paper exercise and once in a staging environment. Mark each item as open, done, or not applicable with a name and date.

Treat data movement as a project of its own. Object stores need an inventory, a sync tool, and a checksum pass. Databases need a replication method, a lag check, and a restore test. Queues need a drain plan or a dual-write bridge. Do not assume a snapshot is a migration.

Plan the cutover like a release. Set a freeze window, a go or no-go call, and a rollback trigger. Keep the old system writable until the new one passes the success tests. Then remove access in stages, not all at once.

• Confirm the workload owner, the target platform, and the success tests in one signed-off document.
• Export the full resource list with IDs, tags, regions, network paths, and current state.
• Map every dependency: DNS names, load balancers, identity providers, secrets, queues, object buckets, and external APIs.
• Measure data volume, daily change rate, and the time needed for a full copy plus a delta sync.
• List all egress paths and test the transfer speed from the cloud to the target before you commit to a cutover date.
• Copy object storage with a tool that preserves metadata, then compare object counts and checksums.
• Set up database replication or a controlled export and import, and record replication lag during a busy period.
• Rebuild identity and access in the target: service accounts, roles, key management, and secret rotation.
• Recreate network controls: firewall rules, private routes, VPN or dedicated links, and DNS records with short TTLs.
• Deploy the workload in the target and run a read-only test with production-like traffic.
• Test backup restore, log shipping, alerting, and the on-call runbook in the target.
• Schedule the cutover with a freeze window, a rollback trigger, and a named person who can call a stop.
• After the move, block old credentials, remove old DNS records, and keep the source read-only for an agreed period.
• Decommission storage, snapshots, keys, and accounts only after the rollback window closes and the final backup is verified.

What good looks like

A clean exit leaves no hidden calls back to the old cloud. The workload starts, serves traffic, writes data, and recovers from a backup without using a cloud-only service. Logs and metrics land in the target. Alerts reach the on-call person. The team can explain every network path.

Data checks are boring and complete. Object counts match, database row counts match, and a sample query returns the same result. The backup restore has a measured time. The rollback plan has an owner and a deadline, and the source system is read-only, not silently serving live traffic.

Costs and access are visible. The target has a tag scheme, a budget alert, and a named owner for each resource. Old accounts are closed in a planned order. The exit review lists what broke, what was manual, and what to fix before the next workload moves.

What to do next

Pick one workload with a clear boundary and a real business owner. Run the inventory and dependency map first. Do not start with the largest system or the one with the most unknown owners. A small, well-understood service proves the process and gives the team a reusable runbook.

Set a target date for the paper exercise, then a date for the staging test. Assign the data copy, the identity rebuild, and the cutover rehearsal to named people. Review the open items weekly. If a dependency has no owner, treat that as a blocker, not a task for later.

If you need help shaping the target architecture and a phased plan, Cloudverg's Discovery and roadmap sprint is a fixed price $9,500 over two weeks. It is one option among others. You can also run the checklist with your own team, hire a contractor, or use a colocation provider's migration service. The point is to make the exit explicit before anyone touches production.

Frequently asked questions