Migrate Sophos Endpoint devices between Central tenants
During acquisitions, tenant consolidation or a change of partner, managed endpoints may need to move to another Sophos Central tenant. This is not merely a device move: the target tenant has its own licences, policies, exclusions, administrators and data retention.
Before migration
Inventory the source and target:
- tenant and organisation structure,
- active Endpoint and XDR licences,
- Agent Mode and operating systems,
- policies, groups, exclusions and Website Lists,
- Update Caches, Message Relays and proxies,
- isolated devices, open Alerts and active investigations,
- VDI, server and legacy platforms.
Do not assume that policies and exclusions move with the computer. Equivalent or stronger protection must be prepared in the target tenant in advance.
Use the supported migration path
Sophos provides an Endpoint API-based migration for supported scenarios. Use API credentials with the minimum required permissions. Store credentials in a Secret Store and rotate or remove them after the project.
Securely automate Sophos Central Endpoint API explains authentication, tenant ID, data region, roles, rate limits and secure error handling.
Exact availability and restrictions depend on the tenant type, licence, platform and agent version. Check the current Sophos workflow before the project. Manually manipulating MCS files or tenant IDs is not a supported alternative.
Enable Device Migration for a limited period in both the sending and receiving tenant. The administrator performing the migration needs administrator permissions in both accounts and Service Principal Super Admin API credentials.
First create a Receiving Job in the target. Its Job ID and Access Token are then used for the Sending Job with the specific Endpoint list. Do not store these tokens in tickets or shell history.
Move a pilot group
Migrate a small number of representative devices first. Then verify:
- The device appears only in the expected target tenant.
- Communication and Last Active are current.
- Licence and Agent Mode are correct.
- Target group and effective policies are correct.
- Updates, protection tests, Alerts and isolation work.
- Old tenant-specific caches or relays are no longer required.
Begin the phased migration only after this validation. Critical servers, VDI and remote devices form separate waves.
Sophos keeps a computer in the migration queue for up to 14 days. A device that remains offline then fails and must be queued again manually. Do not silently count holiday devices and rarely connected systems as successful.
Special cases
An offline or damaged device cannot be moved remotely with confidence. It may require repair or reinstallation with the target tenant’s installer.
With Tamper Protection enabled, do not use unauthorised removal or registry workarounds. The correct recovery and uninstall process is covered in Uninstall Sophos Endpoint with Tamper Protection enabled.
Follow-up work
After the final wave, reconcile source and target. Remove orphaned devices from the source tenant only after confirming registration in the target and retention of relevant incident data. Clean up API credentials, temporary groups and migration exclusions.
Use Event and Audit Logs in both tenants to verify the result. Compare the API status with the registration and effective policy actually visible in the target.
In the source tenant, the Send endpoints to another tenant audit event confirms the send operation. On the computer, Device registered with new account <AccountID> confirms success, while Device failed to register with new account <AccountID> means that the source tenant still manages the device. Expect Allow endpoints to migrate to this tenant in the target tenant. Then verify registration, assigned user and successful agent update status on the migrated device.