Worker reassignment, dependency backups and removal

Scope and prerequisites

Worker migration changes execution references to compatible authorized capacity. It does not automatically transfer files, databases, credentials or an operating system. Confirm the source tenant, eligible destination, worker-management authority and operational window before beginning.

A dependency backup preserves assignment metadata and integrity information. It is not a VM image or a complete data backup. When restoring or reassigning from saved metadata, verify that the destination currently satisfies the required capabilities and that the referenced objects still exist.

Inventory and prepare

1. Open Cloud workers → Workers and inspect the source worker.
2. Use Reassign references, Dependency backups or Restore/reassign to another worker as appropriate.
3. Read the current references and confirm the source tenant and worker.
4. Review active or queued executions, default-worker usage, Sessions, Workflows and any credential or connection dependencies.
5. Use Drain worker when the intent is to stop assigning new work while allowing existing work to finish.
6. Resolve incomplete inventories and provider-state errors before attempting removal.

Scheduling changes and VM power changes are different actions. Stopping a VM is not a replacement for a controlled wait for active executions to finish.

Preview and apply reassignment

1. Select the supported Destination worker and the intended references.
2. Confirm Destination credentials have been configured and verified only after checking the actual destination configuration.
3. Choose Preview changes and inspect the proposed changes, warnings and blockers.
4. If you change destination, selection or relevant configuration, generate a new preview.
5. Apply the allowed plan through Apply reassignment and verify the reported result.
6. Refresh source and destination information and inspect the saved dependency backup where applicable.

The interface manages the preview and retry identifiers. Do not alter them to override a conflict. Download metadata copy provides the displayed backup scope; it should not be treated as a portable copy of all object contents or secrets.

Resolve Sessions and deprovision

The removal flow can offer Replace worker, Distribute Sessions or Disable affected Sessions. A replacement must be compatible with every affected Session. Distribution requires a complete assignment plan. Disabling affected Sessions changes their ability to run, and linked Workflows can show a dependency error.

Open the removal dialog, refresh impact and review provider resources, references and execution activity. If the supported flow offers Stop and deprovision the VM, read its effect before selecting it. Enter the displayed Type to confirm value and acknowledgment only after all permitted prerequisites are satisfied, then submit once.

Acceptance and recovery

In a laboratory, reassign one synthetic Session, verify the published references and backup, then refresh the source impact. Successful removal requires confirmed provider absence and final reference checks. A provider error preserves the Dova record for diagnosis and retry; unknown or unavailable is not equivalent to absent.

After a network error, reopen the operation and inspect current state before retrying. Closing a dialog does not cancel a request already accepted by the provider. Do not claim resource removal or cost savings until the provider result and the corresponding Dova state are verified.

Related guides: Cloud workers, Worker installation and Audit.