A Microsoft 365 tenant is not designed to be moved. Users, mailboxes, OneDrive files and SharePoint sites are tied to one tenant ID, and when a company changes hands, that boundary turns into a project. The data has to go somewhere else, and Microsoft gives you surprisingly little help getting it there.

Three situations produce this problem again and again:

• Mergers and acquisitions. The acquired company has its own tenant, its own domain and years of mail. The parent wants everyone in one tenant by the end of the integration plan.

• MSP client handovers. A client leaves one managed service provider for another, or brings IT in-house. The old provider owns the tenant setup; the new one needs the data without inheriting the configuration.

• Splits and divestitures. One business unit is carved out and needs its own tenant with only its own data, nothing from the rest of the organization.

Microsoft's native cross-tenant migration tools do exist, but they come with conditions: add-on licensing per migrated user, cooperation from administrators on both sides at the same time, and a window in which both tenants stay live and connected. In an acquisition that is often fine. In a hostile split, a contested MSP exit, or a case where the source tenant is about to be decommissioned, it falls apart.

There is a quieter option that most organizations already have in place. If the source tenant has been backed up, the backup is a complete, tenant-independent copy of the data. Restore it into the target tenant and the migration is done. This article walks through the three scenarios and shows where a backup-based cross-tenant restore fits.

Scenario 1: The acquisition

A 400-person manufacturer buys a 60-person software company. The buyer runs its own Microsoft 365 tenant and wants the new team on company email addresses within 90 days. The acquired company's tenant is to be shut down afterwards to stop paying for it.

The traditional route is a tenant-to-tenant migration with a third-party migration tool or Microsoft's cross-tenant feature. Both work, but both assume the source tenant is healthy, fully licensed and stays online through the cutover. Migration licensing is paid per user, and the project usually needs a specialist for the setup on both sides.

With a backup in place, the sequence looks different. The acquired tenant is backed up in full before any changes are made. That snapshot becomes the legal and operational record of what the company had on the day of closing, which is worth keeping regardless of how the migration is done. New accounts are created in the buyer's tenant. Then each user's mailbox and OneDrive is restored from the backup into their new account, mapped by name rather than by tenant identity.

Two things come out of this that a migration tool does not give you. First, the source tenant can be shut down the moment the backup is verified, because nothing downstream depends on it staying alive. Second, the backup remains as a retention copy of the acquired company's data, which matters for contracts, disputes and compliance obligations that outlive the tenant.

Scenario 2: The MSP client handover

A managed service provider loses a client to a competitor, or the client decides to run IT themselves. Every MSP has been on both ends of this. The outgoing provider is contractually obliged to hand over the client's data, but has no incentive to spend engineering hours making the transition smooth. The incoming provider wants a clean tenant built to their own standards, not an inherited one full of someone else's policies, conditional access rules and leftover service accounts.

The awkward part is timing. A tenant-to-tenant migration needs both providers to coordinate on the same days, with admin access on both sides. When the relationship has gone sour, that coordination is exactly what nobody wants to do.

Backup breaks the dependency. If the client's Microsoft 365 data is backed up to storage the client controls, or to a backup account the client owns, the handover is reduced to one step: give the new provider access to the backup. The old provider's involvement ends there. The incoming provider builds a fresh tenant, creates users, and restores mailboxes and files from the backup on their own schedule.

For MSPs this also changes the pitch at onboarding. A client whose data is backed up outside their provider's tenant is a client who can leave cleanly. That sounds like a risk for the provider, but in practice it is a selling point: clients sign more readily when they can see the exit. And when the provider is the one receiving a client, the first thing to set up is a backup of the old tenant, before anyone touches it. That backup is both the migration source and the insurance policy if the old provider cuts access early.

Scenario 3: The split

A group divests one of its divisions. The division's 120 employees move to a new legal entity with a new tenant, and the deal says they take their own mail, files and team sites with them and nothing else. The remaining group keeps everything that belongs to the other divisions.

This is the scenario where migration tools are weakest, because the task is selective. The question is not "move everything from A to B" but "move these users, these sites, and these shared mailboxes, and leave the rest". Getting the scope wrong in either direction is a problem: data that stays behind is a loss for the new company, data that leaks across is a confidentiality breach for the old one.

A backup-based restore is selective by nature. The operator picks the users and sites to restore into the new tenant, item by item if needed, and the rest of the backup is simply not touched. The parent keeps its full backup of the pre-split tenant, including the divested division's data as it stood on the day of separation. If the deal later turns into a dispute over who owned what, that snapshot is the evidence.

The same selectivity works for consolidation in the other direction. A group that has accumulated five tenants from five acquisitions can back each one up, retire them one at a time, and restore into the surviving tenant in whatever order the integration plan dictates.

How a cross-tenant restore works in Duplicati

Duplicati's Microsoft 365 backup reads data from a tenant through an app registration you create in that tenant, and writes it, encrypted, to a storage destination you choose. The backup does not depend on the tenant once it is taken. A restore is just the reverse: point Duplicati at a tenant, any tenant, and write the data back. Whether the target is the same tenant or a different one is a choice made at restore time, not at backup time.

In practice the process looks like this:

1. Back up the source tenant. Register the Duplicati app in the source tenant and run a full backup. Keep the encryption key somewhere outside both tenants; the backup is unreadable without it.

2. Verify the backup. Browse the backup, confirm the users and sites you expect are there, and do a test restore of one mailbox before relying on it for the move.

3. Prepare the target tenant. Create the user accounts and SharePoint sites that will receive data. The target needs its own app registration for Duplicati, done by the target tenant's administrator.

4. Map identities. A user who was anna@acquired.com is now anna@parent.com. The restore maps each source user to a target user; the target does not need to share domain, tenant or user ID with the source.

5. Restore in scope. Select the users and sites to restore and run it against the target tenant. For a consolidation this can be done in waves, one department at a time, with the source tenant still running.

6. Decommission the source. Once the restore is checked, the source tenant can be shut down. The backup stays as the retention copy.

This works the same whether the backup runs on your own Duplicati installation or as a managed backup in the Duplicati Console. The Console version removes the server: Duplicati runs the backup, and storage is included per user, with the option to use your own destination instead. In both models the tenant app registration and its permissions are set up by your own administrator, and the encryption key stays with you.

For MSPs, the Console model fits the handover scenario well. The backup is tied to the client's organization in the Console, not to the provider's infrastructure, so transferring access means transferring an organization, not re-hosting a backup server.

What backup-as-migration does not solve

A restore moves data. It does not move the tenant around the data, and it is better to know that up front than to discover it on cutover day.

• Identity and licensing. Users, groups, licences and MFA enrolment in the target tenant are created by you, before the restore. The restore fills accounts; it does not make them.

• Configuration. Conditional access policies, retention policies, mail flow rules, Teams settings and app integrations are tenant configuration, not user data. They have to be rebuilt in the target, and in most handovers that is deliberate.

• Domains. A custom domain can only be verified in one tenant at a time. Moving acquired.com to the parent tenant is a DNS and admin-centre task that sits outside the data restore, and it dictates the cutover order.

• Permissions and sharing links. Restored SharePoint content lands with the target's permission model. External sharing links from the old tenant will not survive, and internal permissions depend on how user mapping is done.

• Delta during the move. Mail keeps arriving in the source tenant until the domain is moved. Plan for a final incremental backup after the cutover and a last restore of the delta, or accept a short freeze.

A short checklist for the project:

• Full backup of the source tenant taken and the encryption key stored outside both tenants

• Test restore of one mailbox and one site into the target, checked by the user

• Target users, groups and licences created; identity mapping agreed and written down

• Domain move scheduled and the cutover order decided

• Final incremental backup and delta restore planned for after the domain move

• Source tenant decommission date set, with the backup kept as the retention copy

Backup as the exit plan

The common thread in all three scenarios is that the organization with a tenant-independent backup holds the better position. The buyer can decommission faster. The departing client does not need the old provider's cooperation. The divested division takes exactly its own data and leaves a clean record behind.

None of that requires a migration project to be planned in advance. It requires the backup to exist before the change happens. That is the argument for backing up Microsoft 365 to storage you control, with keys you hold, as a standing practice rather than a reaction to the next deal.

Duplicati Console offers managed Microsoft 365 backup with per-user pricing, storage included, and restore into any tenant you have administrative access to. The same capability is available in self-hosted Duplicati for organizations that prefer to run it on their own infrastructure. Either way, when the next merger, handover or split comes around, the migration tool is already in place.