B BROCENT

How to Use Claude to Plan a Microsoft 365 Tenant-to-Tenant Migration

A practical guide to using Claude on cleaned Microsoft 365 inventory exports to draft a tenant-to-tenant migration plan: a mapping sheet, a conflict list, migration waves and staff cutover notices in each office's language, with migration tools doing the moving and people verifying.

Low angle view of modern glass skyscrapers against a clear blue sky
The short answer: A tenant-to-tenant migration is moved by migration tooling, not by a chat model — but the plan around the tooling is a pile of spreadsheets, and that is where Claude helps. Export the inventories from both Microsoft 365 tenants, strip out anything sensitive, and ask Claude to build a source-to-target mapping sheet, flag the conflicts, propose migration waves and draft the staff cutover notices in each office's language. Every row still has to be checked against the real tenant by a person, and the exports must never contain passwords, keys or mailbox content.

Picture the IT manager of a Hong Kong trading group, call it Group A, that has just acquired a company with offices in Singapore and Kuala Lumpur, which we will call Company B. Group A has about 240 users on its own Microsoft 365 tenant. Company B has about 180 on a separate tenant, 110 in Singapore and 70 in Kuala Lumpur, so roughly 420 people once everyone is consolidated into the Hong Kong group's tenant.

The first draft of that plan is usually a spreadsheet one person builds by hand from the Entra user list and then patches as surprises appear. Nobody yet knows that the same sales alias exists in both tenants, that the Singapore finance shared mailbox is owned by someone who has left, or that Kuala Lumpur laptops are enrolled in the other company's Intune.

The migration platform will move whatever it is told to move. Deciding what to tell it, which user maps to which account, which accounts are not worth moving and who goes first, is a reading-and-cross-checking job across several exports. The model drafts and cross-checks that plan, the migration tools do the moving, and humans verify.

What Has to Be Mapped Before Anyone Moves a Mailbox

Beyond the mailbox move sit six kinds of object, and each needs a row in the plan before the first wave is scheduled.

Identities, Licences, Shared Mailboxes, Groups, Sites and Devices

Identities. Every Entra ID user in the source tenant needs a decision: migrate, merge into an existing target account, leave behind or retire. Record the source UPN, the target UPN, the primary SMTP address and every alias.

Licences. Licences in the source tenant do not travel. Migrating users need a licence in the target, and the licence report shows whether the target has enough seats on the right plans. Native cross-tenant mailbox migration in Exchange Online also needs a per-user add-on licence and a trust configuration between the tenants, so check current Microsoft Learn for licensing and prerequisites.

Shared mailboxes and groups. Shared mailboxes, Microsoft 365 Groups, distribution lists and Teams all have owners and members who may or may not be migrating. They are the objects most likely to end up orphaned.

SharePoint sites and OneDrive. The site list from the SharePoint admin center gives owners, sizes and last activity. Sharing links to this content typically break when it moves.

Teams. Team structure and channel files can be moved by migration tooling. Native mailbox moves have historically not carried Teams chat history. Microsoft announced a migration orchestrator in public preview from early December 2025 (Message Center MC1198079), covering mailboxes, OneDrive and Teams chats through new Graph PowerShell commands, but its status may have changed, so check its current status before you plan around it.

Devices. Intune-enrolled devices and Autopilot records belong to the source tenant. Plan re-enrolment into the target, often a reset or re-provision, with Autopilot device records deregistered from the source and imported to the target, and check current Microsoft guidance for the path that fits your device types.

Turning Inventory Exports Into a Mapping Sheet and Conflict List

Claude does not connect to either tenant in this workflow. You export the inventories, clean them and paste them in, and it reads them side by side.

The Exports to Pull, and How to Strip Them First

1. Entra users from both tenants. Download the user list from the Entra admin center, or export it with Microsoft Graph PowerShell. Keep object ID, display name, UPN, mail, enabled flag, user type, last sign-in and office.

2. Mailbox statistics. In Exchange Online PowerShell, Get-EXOMailbox gives mailbox type (user, shared, room, equipment) and aliases, and Get-EXOMailboxStatistics gives size, item count and last logon. Keep the sizes and counts, never the content.

3. Groups and Teams. Export Microsoft 365 Groups, distribution lists and Teams with owner and member counts.

4. SharePoint sites. Export the active sites list from the SharePoint admin center: URL, template, owner, storage used and last activity.

5. Intune devices. Export managed devices from the Intune admin center: name, operating system, ownership, primary user, enrolment type and compliance state.

6. Licence report. Per-user assigned licences plus the subscription summary, so the model can compare seat counts with what the target tenant has.

Strip before you paste. Delete every column you do not need. Never include passwords, MFA secrets or authentication-method detail, BitLocker or other recovery keys, admin tokens or mailbox content. If your policy requires it, pseudonymise as well: a small script replaces names and the local part of each address with IDs, using one key file that stays on your side, so the same person or alias gets the same ID in both tenants and collisions remain detectable. Leave the domain part visible, because domain conflicts depend on it.

The Prompt That Produces the Mapping Sheet and Conflict List

Paste the cleaned files with one instruction: "Attached are cleaned inventory exports from Tenant A (the target) and Tenant B (the source), with personal identifiers replaced by IDs. Build a mapping sheet with one row per Tenant B user: source ID, proposed target UPN, licence needed, mailbox type and size, and a decision of migrate, merge, leave behind or retire, with the reason. Then list the conflicts in separate groups: UPN or alias collisions with Tenant A, domain-related blockers, duplicate display names across the tenants, shared mailboxes with no active owner, accounts that are disabled, unlicensed or have not signed in for 90 days, and groups or Teams whose owners are all leaving or inactive. Cite the row IDs behind every item, and say 'not in the data' instead of guessing."

A conflict the model cannot point to is one you do not trust yet, and spot-checking ten rows against the real tenant tells you how far to trust the rest.

The Conflicts Worth Asking For

Most surprises come from a short list: UPN and alias collisions (the same address in both tenants), duplicate display names (two people, or one person with two accounts), shared mailboxes nobody owns, unlicensed or inactive accounts that are candidates to leave behind rather than pay to migrate, and orphaned groups and Teams whose owners have left. The model is good at finding them; deciding what to do with each one is a business call.

Sequencing Waves — Who Moves First and Why

A wave plan is a list of who moves when and what each move depends on. Three things drive the sequence whatever the tooling.

The first is dependencies. A manager and the assistant with delegate access, or a team that shares a mailbox and a Team, should move together, or the delegation breaks across tenants. The second is size and throttling: very large mailboxes and many parallel moves slow one another down, so spread the heavy ones across waves. The third is the domain.

A custom domain can only be verified in one tenant at a time. To use Company B's domain in the target, it must first be removed from the source tenant, which means no user, group or alias in the source can still use it. That single rule shapes the cutover weekend: users are moved onto temporary addresses, the domain is removed from the source and then added and verified in the target, mail routing is switched, and only then do people get their primary address back.

A Worked Example — Two Tenants, Three Regions, One Cutover Weekend

1. Export and clean. An IT administrator exports the six inventories from both tenants, drops unneeded columns, replaces names and address local parts with IDs using a small script and a local key file, and confirms no passwords, keys or mailbox content are present.

2. Run the mapping prompt. Claude returns the mapping sheet and a conflict list. In this scenario it flags a handful of alias collisions where both tenants have a sales alias, two display names shared by different people, a Singapore finance shared mailbox whose only owner is disabled, and several Kuala Lumpur accounts with no recent sign-in and no licence.

3. Resolve the conflicts with people. The IT manager, the Singapore and Kuala Lumpur office managers and HR go through the list. The missing owner is replaced, the stale accounts are retired, and the alias collisions are renamed in the plan.

4. Ask for the wave plan. Prompt: "Using the mapping sheet, propose migration waves for the Tenant B users. Wave 0 is the IT team and a few volunteers. Keep people who share mailboxes, Teams or recurring meetings in the same wave, put the heaviest mailboxes in their own wave, avoid month-end for finance, and list each wave's dependencies." Then ask a second question: "Does anyone appear in a wave before something they depend on, and does every shared mailbox sit with its main users?"

5. Cross-check against the real tenant. Before approval, a person verifies a sample of rows in the admin centers and confirms the target tenant's licence count covers the migrating users. The migration tool's own discovery or pre-check run is the second source.

6. Draft the cutover-weekend checklist. Ask for a sequenced checklist: change freeze, final sync, domain removal from the source, domain verification in the target, mail routing switch, device re-enrolment and first-login support.

Drafting Staff Cutover Communications in the Right Language for Each Office

People experience a migration through what breaks for them, so the notice must list it: recurring Teams meetings to recreate, external sharing links that stop working, Outlook and OneDrive to set up again, and devices to re-enrol.

Give the model the facts and dates yourself, then ask: "Draft a cutover notice for staff in [office]. Say what changes on which date, what they must do before and after (sign out, sign in again, set up Outlook and OneDrive again), what will not carry over, and who to contact." Produce the same notice in English for everyone, in Traditional Chinese for Hong Kong staff, in Simplified Chinese for Singapore staff who prefer it and in Bahasa Malaysia for Kuala Lumpur. Have a native reader in each office check the translation before it goes out; the model's version is a draft.

Claude-Drafted Plan vs. a Migration Vendor's Discovery Tool vs. a Managed Migration

  • Claude-drafted plan. Fast at reading several exports together and drafting the mapping sheet, conflict list, waves and multilingual notices. It cannot check your tenant and can be confidently wrong, so every claim needs a check. Correct use: the planning layer and first draft, reviewed by someone who knows the tenant.
  • A migration vendor's discovery tool. Third-party platforms such as ShareGate, AvePoint, BitTitan and Quest are commonly used for Teams and SharePoint moves and connect to the tenants directly, so their inventories reflect the real objects. Fidelity limits differ by product, so check current documentation. Correct use: the system of record for what moves and how, with the Claude plan as a cross-check.
  • A managed migration. A team that has run these cutovers owns the tenant configuration, licensing, device re-enrolment and the weekend itself, and carries the accountability. Correct use: when the project is larger than your IT team can run alongside the day job.

Getting This Right — What You Must Not Paste Into a Model, and Data-Residency Constraints

Keep secrets out entirely. Passwords, MFA secrets and recovery details, BitLocker or other recovery keys, admin tokens and mailbox content never go into a prompt.

Treat exports as personal data. Names, email addresses, departments and sign-in dates are personal data. Under Hong Kong's PDPO and the PDPA in Singapore and Malaysia, think about purpose, minimisation and where the data goes, and pseudonymise before pasting if your policy requires it. Check your plan's data terms and your own policy before pasting staff data. This is not legal advice.

Know which cloud each tenant is in. Hong Kong tenants are on global Microsoft 365. Microsoft 365 operated by 21Vianet in mainland China is a separate sovereign cloud, and a move between it and global Microsoft 365 is not a standard same-cloud tenant-to-tenant migration. Check current Microsoft documentation, expect third-party tooling and more planning, and take advice on data residency before exporting anything from a China-region tenant.

Deciding which exports can safely go into a model, and building the prompts and cross-checks around them, is AI+ Support work. Running the migration itself, with tenant configuration, licensing, device re-enrolment and the cutover weekend, sits under Managed IT & Cloud Services, and our IT support team handles staff on cutover day. If you want the ongoing service afterwards, see managed IT support for live per-market pricing. For the non-AI side of the same project, read the Microsoft 365 migration checklist for Hong Kong and the guide to a post-acquisition tenant migration in Singapore.

Frequently Asked Questions

How long does a tenant-to-tenant migration take?

There is no honest single number. The drivers are the user count, total data volume and the largest mailboxes, throttling on both tenants, the number of waves, how much of the estate is Teams and SharePoint content, device re-enrolment and how much testing and pilot time you allow.

Can we migrate Teams chat history?

It depends on the tooling and changes often. Native mailbox moves have historically not carried Teams chats, Microsoft's announced orchestrator preview is meant to cover them, and third-party platforms have their own fidelity limits, so check each one's current status before promising staff anything.

What breaks on cutover day?

Recurring Teams meetings usually need recreating, external sharing links stop working, Outlook profiles and OneDrive sync clients need reconfiguring, and Intune-enrolled devices need re-enrolling.

Do Intune-enrolled devices need re-enrolling?

Generally yes: often through a reset or re-provision, with Autopilot records deregistered from the source and imported to the target.

Does moving a China-region tenant change anything?

Yes. Microsoft 365 operated by 21Vianet is a separate sovereign cloud, so a move between it and global Microsoft 365 is not a standard same-cloud tenant-to-tenant migration. Check current Microsoft documentation and expect third-party tooling and more planning.

Is it safe to paste tenant exports into Claude?

Only after you strip them. Remove passwords, MFA secrets, recovery keys, admin tokens and mailbox content, pseudonymise if your policy requires it, and check your plan's data terms and your obligations under PDPO or PDPA before anything leaves your environment.

Share:

Ready to take action?

Turn these insights into a roadmap for your business.

Book a 15-minute no-obligation consultation with our APAC IT experts. We'll review your current setup and provide a tailored IT roadmap within 24 hours.

Explore all services
📋

Free Checklist

10 Critical Checks Before Expanding IT to Greater China

PIPL compliance, network segmentation, bilingual helpdesk setup, and more — everything your IT team needs before Day 1 in China.

Request the checklist →

📬 Monthly Asia IT Insights

China compliance updates, cybersecurity alerts, and IT tips for APAC teams — once a month.

No spam. Unsubscribe anytime.