Migrate a container's or virtual machine's instances between servers on Cycle, or revert a recent migration. Pass exactly one of container or virtual_machine. Cycle backs every VM with a container, so a VM migrates through that container's single instance (select it with all_instances:true or name it in targets); the response reports both the VM and its backing container.
Cycle migrates instances across any infrastructure it manages — between servers, data centers, cloud providers, and on-prem hardware. Not every server is a valid target: containers carry tag restrictions and other constraints, so this tool only accepts destinations Cycle reports as compatible for the container. A migration is reversible: the original instance is retained until Cycle's purge window elapses (roughly 3 hours for stateful instances), during which action:"revert" restores it on its source server. Only retained source instances are revertable; running destination copies are skipped. Load balancer instances cannot be migrated.
Workflow:
1. Call with preview:true and your selection. It makes NO changes and returns the selected instances — each with its current server (id and name) and whether it is stateful — plus, for migrate, the compatible destination servers. The plan comes from read-only lookups; Cycle does not validate it.
2. If the destination is unclear, present the compatible servers and let the user choose. With NO compatible servers migration is impossible — tell the user why (tag or infrastructure constraints).
3. Confirm the specific move with the user, then call again without preview. Never migrate or revert without explicit confirmation.
Select instances with exactly one of: targets (specific instances, each optionally with its own destination so they can spread across servers), source_server ("move this container off nuc-bear"), or all_instances. A top-level destination_server is the default for selected instances without their own and is required with source_server or all_instances.
copy_volumes applies to stateful instances and defaults to true so data is never silently dropped. A VM's local volumes — including its boot disk — are what it moves, so copy_volumes:false lands the VM on empty local storage and is almost never wanted. External (SAN) volumes are attached, not copied, and are unaffected either way.
Asynchronous: submits one job per instance and returns without waiting (wait_seconds gives a short bounded wait for quick moves). Track the job_ids with get_jobs, then call again with preview:true to confirm each instance reports its destination server.