Moving Devices and Organizations
Your org tree changes: a device gets onboarded under the wrong client, an organization (for most MSPs, a client) is acquired or split, or you regroup your book of business. Two actions cover that, and both keep history intact.
| You want | Use |
|---|---|
| One device under a different organization | Change ownership on Configure > Agents |
| A whole organization under a different parent | Change parent on Configure > Organizations |
| One machine to stop being collected from | Delete on Configure > Agents |
Move a device to another organization
Select the device on Configure > Agents, then Change ownership and pick the destination organization.
What moves with the device:
- Its identity and its device record, so the row keeps the same history.
- Its collection state, so it resumes where it left off rather than re-uploading.
- Every event it collects from the move onward, which records under the new organization.
What stays where it is:
- Data already collected stays with the organization that owned the device at the time. Events are filed under the organization that owned the endpoint when they arrived, so a move never refiles earlier data.
What the move survives:
- Reinstalls, wipes, reimaging, and nightly disk-restore cycles. The device returns to the organization you moved it to, even when its deployment package still carries the original client's registration token.
- Reinstalling with a different organization's registration token does not move a device. Any token in your workspace returns the endpoint to the device record and organization it already has. The token decides the organization only for a device's first enrollment. See Agent identity and cloning.
What you need:
- The destination must be an organization in the same workspace.
- Permission to manage the device, plus permission to register agents in the destination organization.
- A live device cannot be moved under a deleted organization. Undelete the organization first.
Move an organization under a different parent
Select the organization on Configure > Organizations, then Change parent and pick the new parent.
What comes along:
- Everything below the organization, including its sub-organizations, devices, and ingest keys. You only name the organization that moves; the subtree follows it.
- History, including data collected before the move. Access is resolved against the tree as it stands now, so past events for the moved organization and its devices appear under the new parent right away, with no reprocessing and no backfill.
- Access, for the same reason. Users and tokens scoped to the new parent see the moved subtree, and ones scoped to the old parent stop seeing it.
Limits:
- An organization cannot move under itself or under one of its own descendants.
- A live organization cannot move under a deleted parent.
- The tree has a depth limit, measured on the deepest organization in the subtree you are moving, so a very deep subtree can be refused.
- You need organization write permission on both the organization that moves and the new parent.
The move runs while you wait, so a large subtree can take a moment before the screen confirms it.
Delete a device instead of moving it
Move a device when it should keep collecting somewhere else. Delete it when the machine should stop being collected from at all.
- Delete on Configure > Agents. An agent that is still running stops collecting and idles.
- The deletion holds through wipes. A deleted machine that is wiped, reimaged, or reinstalled is refused when it tries to enroll again, under any registration token in your workspace, rather than arriving as a brand-new device. One delete covers one machine however many times it comes back.
- Deleting a device does not remove data it already collected.
- Deleting a device is not a way to move it. A reinstall after a delete is refused, not relocated.
Undelete is the way back. Undelete the device on Configure > Agents, then:
- A machine that wipes and re-enrolls comes back on its own, with its identity and history intact.
- A machine whose agent is still installed and idling needs its agent service restarted on the endpoint. A coming agent release brings it back without that step.