Home › Blog › Tenant migration
Guide · Tenant migration
Microsoft says there is no built-in way, and there is not. A group is an identity, a mailbox, a site, a membership and whatever sits on top, each with its own route or none. The sequence that produces the right group on the far side, and the five mistakes that produce the wrong one.
By Alex Makey · 6 September 2026 · 7 min read · Verified against Microsoft documentation, September 2026
Ask Microsoft how to move a Microsoft 365 group between tenants and the answer, from Microsoft’s own staff in its own forums, is that there is no built-in method. That is accurate. It is also unhelpful, because groups are where the work lives — every Team, every modern SharePoint site, every Planner board has one underneath. Here is what a group is made of, which parts migrate by which route, and the sequence that produces the right membership on the far side.
A Microsoft 365 group is an identity object in Entra ID with four things hanging off it. A group mailbox in Exchange Online, with conversations and a calendar. A SharePoint site — the document library, pages and lists. A membership of owners and members. And, optionally, the services layered on top: Teams, Planner, Yammer, Stream.
None of these move as one thing. Each is a separate migration, or a separate recreation, and a group that arrives in the target with three of the four is the normal outcome of a project that did not plan for the fourth.
1. Inventory every group, with its type (Teams-connected or not), owners, member count, site size, mailbox size, last activity, and whether Planner or other services are attached. Get-UnifiedGroup with Get-UnifiedGroupLinks for membership; the SharePoint admin centre for site sizes. Groups with no activity in six months are archived in the source, not migrated.
2. Decide the naming and privacy in the target. Names collide across tenants more often than people expect — two companies both have a group called Finance. Decide the rule before anything is created.
3. Make sure every member exists in the target as a licensed user, with the mapping between source and target UPNs written down. A group recreated before its members exist arrives empty or, worse, with the wrong people.
4. Create the groups in the target, empty, with the right owners. By script from the inventory, or by the migration tool’s group provisioning step. Set privacy and naming before content lands.
5. Migrate the SharePoint site content into each new group’s site, with the SharePoint tool you are using for the rest of the estate. This is where the value is and it is the most reliable step.
6. Recreate what does not migrate: unique permissions and sharing decisions from the report, Planner boards from export, the group calendar’s recurring meetings by hand. Re-invite guests.
7. Populate membership last, so people do not find a half-built group. Notify them when it is complete.
8. Set the source group read-only, then archive it after validation. Retain for the retention period before deleting.
Migrating the site without recreating the group. The content lands in a plain SharePoint site with no group, no Teams connection, no membership model. Everything then has to be moved again into a group-connected site. Create the group first; migrate into its site.
Membership before content. Users get a notification about a new group, open it, find it empty, and conclude the migration has failed. Populate membership as the last step.
Guests. External members do not move. Each has to be invited to the target tenant and added to the group. Some will not accept. Know which groups have guests before you start.
Forgetting the private channel sites. A Teams-connected group can have private channels, each with its own SharePoint site separate from the group’s. Tools that enumerate the group’s site miss them. Inventory sites by URL, not by group.
Retention labels and policies. They are tenant configuration and do not move. If the source group was under a retention policy, the target group needs the equivalent applied before content arrives, or the retention starts from zero.
Create groups by script from the inventory, migrate site content with ShareGate or AvePoint, treat group mailbox conversations and Planner as export-and-rebuild unless the client specifically needs them live, and populate membership on the last day. It is slower to describe than to run, and it produces groups that look, on the far side, like they always lived there.
One email a month, at most
Postmortems, timelines, licensing changes that cost people money. If a month has nothing worth your time, you hear nothing.
Please enter a work email address.
Done. Unsubscribe by replying to any email; we will not argue.
Related questions
Not as a single object; Microsoft provides no built-in method. The group is recreated in the target, its SharePoint site content is migrated with a SharePoint tool, membership is mapped user by user, and the mailbox, calendar, Planner and Teams layers are migrated with limits or recreated.
Inventory, decide naming and privacy, ensure every member exists in the target, create the group empty with owners, migrate the site content into it, recreate what does not migrate, populate membership last, then set the source read-only.
Because the site was migrated before a group was created for it in the target. Content landed in a plain site. Create the group first and migrate content into the group’s site.
Rarely with full fidelity. Some tools migrate group mailbox conversations; the calendar is usually recreated or exported. Plan for export-and-rebuild unless a tool has been tested on your estate.
They do not move. Each guest must be invited to the target tenant and added to the group again, and some will not accept. Inventory guests before starting.
Rather not do this yourself?
Describe the situation and you get back a sequence, an honest view of what will be slow, and a fixed price — usually within one business day. Or ask one question and get one answer.