SharePoint Sharing Links After Migration

What happens to sharing links after migration?

Most of them stop working. A sharing link points at one copy of one file in one tenant, so once that file exists as a new object in a new tenant, the old sharing link has nothing left to resolve to and the user gets a not found or access denied page.

There is one exception worth knowing before you plan anything. Microsoft's own cross-tenant SharePoint migration redirects existing sharing links for migrated files to the new location, because it moves the site rather than copying it. Every other route, including Microsoft's SharePoint Migration Tool and every third party product, copies content, and copied content gets new sharing links or none at all.

So the planning question is not whether sharing links survive. It is which route you are taking, and how many of those links anybody will actually miss on the Monday after cutover.

Why do sharing links break when content moves?

Because a sharing link is not stored on the file. It is stored beside it, keyed to an identifier the migration cannot carry.

When somebody shares a document, SharePoint writes an entry into a hidden Sharing Links list on that site. The entry holds the document unique ID, an AuthKey, which is the random string you see in the sharing link, a role definition for read or edit, and a group ID. SharePoint also creates a hidden group named after the document GUID and the share type. Later shares of the same document at the same access level join the existing group instead of making a new one.

Now run a copy based migration. The file lands in the target tenant as a new item with a new unique ID, in a site with a different URL, under a different tenant host name. The AuthKey from the old tenant means nothing there. The hidden group refers to a document GUID that does not exist. The identifiers the sharing links depended on were never yours to move.

That is also why permissions and sharing links are two separate jobs. A tool can map a user from the old tenant to the new one and rebuild a role assignment, which is covered in how to migrate SharePoint permissions to another tenant and sits inside the wider move described in how to migrate a SharePoint site to another tenant. Rebuilding a secret string somebody emailed out eighteen months ago is a different thing, and no product does it. The same split shows up in does SharePoint version history migrate between tenants, where the content moves and the record around it does not.

Which sharing links survive and which die?

It depends on the sharing link type, and most admins have never had a reason to learn the difference. Microsoft has three.

The row that surprises people is the first one. Anyone links keep working against the source tenant for as long as the source content exists, because those sharing links need no sign in at all. If you decommission slowly, a client can sit on a live copy of last quarter's pricing in a tenant you stopped watching. That is a security item, not a migration one, and it belongs on the decommissioning checklist.

The guest row is the expensive one. External users are only added to a document's permission set when they open the sharing link, so your reporting understates external reach until somebody clicks. After the move, the partner tenant still points at a user object that no longer exists, and there is no automatic reconciliation between an old guest entry and a new identity.

Does Microsoft's cross-tenant move keep them?

Yes, with conditions. Microsoft's cross-tenant SharePoint migration states that existing shared links for migrated files redirect to the new target location, and that users and groups keep access if they were included in the identity mapping step.

It also leaves a redirect site behind on the source. Anyone who opens the old site URL is sent to the new site and asked to sign in with target tenant credentials. You can list those redirects with Get-SPOSite -Template RedirectSite#0 and remove them with Remove-SPOSite once the full migration is signed off.

Two warnings come with that. Site URLs have to be unique, so a redirect left in place blocks any later attempt to migrate a user or a site back to the source, and the migration fails rather than warns. And the trust relationship between the tenants has to be removed on both sides before the source licences expire, because the command stops working on an expired source.

Native cross-tenant migration is also the narrow route. It needs both tenants in a trust relationship, it is scoped to mergers and divestitures, and it does not cover an on premises source at all, which is a different job described in SharePoint Server to SharePoint Online migration steps. Most teams end up on a copy based route for at least part of the estate, and that is where this planning matters. The gaps in Microsoft's own copy tool are listed in SharePoint Migration Tool limitations you hit in week one.

How do you handle sharing links before cutover?

Run these before the content moves, while you can still read the source tenant properly. Steps two and three are the ones that decide how loud go live week gets.

1. Report every external share. Pull the external sharing report from the SharePoint admin centre for all sites. This is the list of sharing links that reach people outside your company, and it is always shorter than anyone expects.
2. Find the heavy sharers. Twenty people usually own most of the outbound sharing. Email those twenty individually. A broadcast to everybody gets ignored, and these are the users who generate the tickets.
3. Agree what gets re-shared and what does not. Anything older than a quarter is a candidate for letting go. Rebuilding every historic link is a waste, and nobody will notice the difference.
4. Pre-stage the guests. Invite the external identities into the target tenant before cutover so there is something for a new share to point at. The target identity has to exist first.
5. Warn the partner tenants. Tell the organisations you work with that links to your files will be reissued. The ones who hear it in advance do not raise it as an incident.
6. Tighten the target sharing policy first. Set the default link type and the expiration policy in the new tenant before users start sharing, because the defaults travel with every link created after that.
7. Migrate, then verify the permissions landed. Direct permissions rebuild from identity mapping, so confirm that on a pilot site before trusting it across the estate.
8. Re-share the agreed list in one pass. Owners create fresh links from the target tenant on the day, not over the following fortnight. One message, one window, one set of new links.

That sequence folds into the wider plan in the Microsoft 365 migration planning checklist, and the time it adds is covered in how long does a SharePoint migration take.

What about links inside documents and chats?

These are the ones that break quietly. A sharing link pasted into a Teams chat, an email signature, a Word document, an Excel formula or a OneNote page is just text, and no migration reads it.

• Teams chat and channel messages. Messages stay in the old tenant unless they are migrated separately, and a sharing link inside one points at the old site either way.
• Documents that reference other documents. A proposal that links to a price list carries the old tenant URL inside the file. It opens, it looks fine, and the sharing link fails only when somebody clicks it.
• Excel external references. Formulas pointing at another workbook break on the first refresh after the move and show a reference error rather than a missing file message.
• OneDrive shortcuts. A shortcut to a shared library is a pointer to a tenant location, so it needs recreating rather than repairing. User drives follow the same rule when they move with RecoveryTools OneDrive Migrator.
• Intranet pages and wikis. Hard coded links in page content survive the copy intact and point at the tenant you just left.

You cannot fix those with a migration setting. What you can do is decide early that the intranet pages get a URL pass, because they are central and visible, and that everything inside personal documents gets left alone until a user reports it. Trying to rewrite sharing links inside thousands of files costs more than the broken ones do.

How do you clear the broken ones after go live?

Treat it as a short, staffed window rather than a background task. The volume arrives in the first ten working days and then falls away.

• Run a named link desk for two weeks. One inbox, one owner, a fixed reply that tells the user to ask the file owner for a fresh sharing link. Consistency beats speed here.
• Keep the source read only, not deleted. A read only source answers every question about where a file went. Deleting it early turns a two minute lookup into an escalation.
• Watch the external report in the new tenant. Compare it with the source report after three weeks. The gap is the sharing nobody bothered to recreate, which tells you how much of it mattered.
• Kill the Anyone links on the source. Before decommissioning, revoke anonymous access in the old tenant. Those sharing links outlive the project otherwise.
• Remove the redirect sites last. On the native route, leave them until the move is signed off, then clear them so a later move back is possible.

Teams without spare hands for that window hand it to our cloud migration service, which runs the link desk alongside the cutover rather than after it.

Frequently asked questions

Where to start this week

Pull the external sharing report. Not the migration plan, the report, and read the names rather than the totals.

It will show you two things in ten minutes. How much of your content leaves the company through sharing links, and which twenty people create most of it. Those twenty are your entire communication plan, and the budget around them is broken down in SharePoint migration cost.

The rest of it is a decision you can make today. Every sharing link gets rebuilt, which costs weeks, or the ones that matter get rebuilt in one planned pass and the rest are allowed to expire. Pick the second one, and say so before go live rather than after the first ticket.

Published 9 October 2026. Link behaviour, redirect cmdlets and link types come from cross-tenant SharePoint migration step 7 and how shareable links work in OneDrive and SharePoint.