2026 capacity is 100% sold out. Consumer cloud is closed; federal and contractor intake remains open. Capacity update
Deployment guides

Moving workloads between regions

Regional moves are a provision-and-cut operation rather than a migration, and the sequencing matters.

  • Updated Apr 2026
  • Platform administrators

There is no live move

Hosts do not move between facilities. A regional move means provisioning in the target region, replicating, cutting over, and decommissioning the original. This is a consequence of dedicated hardware: there is no shared substrate to migrate across.

Plan it as a cutover with a rollback path, not as a migration that runs in the background.

Sequence

  1. Provision in the target regionUse the same hardware profile unless you have a reason to change it. Changing profile and region at once makes any performance difference impossible to attribute.
  2. Verify the new hostRetrieve and verify the attestation report before replicating anything to it.
  3. ReplicateMove data over your private interconnect rather than the public path. Egress rules apply in both directions and both segments need the path declared.
  4. Cut overSwitch traffic during an agreed window. Keep the source host running and intact until you have confirmed the target under real load.
  5. DecommissionRelease the source host through the portal. Media sanitization runs automatically and produces the disposal evidence.

Do not decommission on the same day you cut over. Keeping the source host for a few days costs allocation but preserves a rollback that does not depend on backups being correct.

Compliance implications

Both regions sit under the same accredited baseline, so a regional move does not change what you inherit and does not require a new assessment of the hosting layer.

If your own authorization names specific regions, update that documentation. The platform will not flag the discrepancy for you.

Deployment guides

Related articles

All deployment guides