You finish a SharePoint migration. Files are in the right place, permissions look correct, and users can browse to the documents they need. Then the first helpdesk call comes in: search is not finding anything. The second call arrives before you can close the first ticket. By end of day, a migration that went smoothly on every objective criterion is being described as a failure by everyone who depends on it.
Search degradation after a SharePoint migration is predictable, partially avoidable, and recoverable - but only if you know what is actually happening. There are three distinct causes, and they compound each other in ways that make the problem feel more mysterious than it is. Each has a different fix and a different timeline.
The recrawl lag: why newly migrated files disappear from search
SharePoint Online's search index is crawl-based, not real-time. When content is created or moved, the search crawler must visit each item and index it before it becomes discoverable. For small, incremental changes to existing libraries, crawling happens quickly. For a large migration that deposits thousands of files into previously empty locations, the crawler treats those locations as new and queues them behind all the other indexing work across the tenant.
In practice, expect 24 to 72 hours before migrated content becomes consistently discoverable through search. High-volume migrations can extend this window. There is no admin setting that forces a priority crawl or bypasses the queue. The only lever is time.
This is why post-migration hypercare communication matters as much as the migration itself. When users are told in advance that search results will be incomplete for 48 to 72 hours, helpdesk volume drops sharply. When they are not told, every missing result becomes a ticket, and the migration project absorbs blame for a platform behaviour that would have resolved on its own.
A workable approach: tell users they can browse directly to their documents in the new location while search catches up, and give a specific window after which search should be working normally. Overdeliver on that window if you can. Do not promise a time you have not verified.
The recrawl lag is the most common cause of post-migration search complaints. It is also the only one with no technical fix. Everything else on this list has a remediation step.
Permission gaps that make indexed files invisible
SharePoint search does not just find content; it finds content the requesting user is permitted to access. If a user's permissions were not carried over correctly during migration, files that are fully indexed simply do not appear in that user's search results. This is not a search failure. It is a permissions failure presenting as a search failure, and the distinction matters because the fix is completely different.
Permission gaps after migration are more common than most project plans account for. Three sources dominate:
- Unique permissions on individual files. When a source library had unique permissions applied at the file level rather than inherited from the library, migration tools vary in how faithfully they replicate that structure. Some carry unique permissions as expected; others flatten them to library defaults or skip them. The result is a file that is technically in the right place but invisible to the users who were supposed to see it.
- Security group membership drift. Permissions managed via Microsoft 365 groups or Entra ID security groups can drift between the time the permission audit was run and the time the migration completed. A user added to a project team after the permissions snapshot was taken will not have the access the plan intended.
- Orphaned owner accounts in cross-tenant migrations. In a cross-tenant scenario, files owned by a source-tenant account that does not exist on the destination can end up with orphaned ownership records. This rarely blocks access outright, but can produce inconsistent search behaviour for admin accounts where the crawl evaluates scope differently.
Diagnosing permission gaps requires a single test: can the affected user browse directly to the file via URL? If yes but the file does not appear in search, it is a recrawl lag issue - it resolves with time. A user who cannot browse to the file directly has a permissions problem, and that requires immediate remediation.
For guidance on carrying permissions over correctly from the start, see how to preserve SharePoint permissions during migration.
Broken internal links and what they do to the crawler
The third cause of post-migration search degradation is the least obvious: broken internal links. SharePoint search uses the links embedded in site pages, document metadata, and list fields to understand relationships between content. When those links point to locations that no longer exist - because a site was renamed, a library was restructured, or the source tenant domain is gone - the crawler encounters dead ends.
The impact on search quality is indirect. The crawler does not fail outright on a broken link; it simply cannot follow it. Content that was well-connected in the source environment, discoverable because it was linked from hub site navigation and site pages, becomes isolated in the destination because those connections are severed. Users who expected to find content by navigating through related pages find instead a dead link, and the content that the broken link was supposed to surface never appears.
Site Pages are the most common source of broken links after a cross-tenant migration. A news post that linked to a document in the source library now points to a URL that either returns an error or, worse, still resolves in the source tenant where the document is no longer actively maintained. Users following those links from search results arrive in the wrong place.
Replacing broken URLs at scale is mechanical but time-consuming when done manually. ShareMaster's Replace Master scans site pages and list fields for instances of the old URL pattern and updates them to the new destination URL in bulk, across multiple libraries and pages. For the complete process, see how to find and fix broken SharePoint URLs.
A structured first-72-hours response
The three causes above have different remediations and different timelines. Addressing them in order makes the hypercare period shorter and the outcomes more predictable.
Day one: validate permissions before assuming search is broken. Select a representative sample of migrated files, including some that had unique permissions on the source, and confirm that affected users can browse to them directly. If they cannot browse to them, fix permissions first. Search cannot show users content they do not have access to, so unresolved permission gaps prolong every other symptom.
Day one: audit and fix internal links in site pages. Before the crawl finishes indexing migrated content, identify site pages that contain absolute links to the old domain. Replacing those URLs before the crawler indexes those pages means users who follow search results land in the right place from the start.
Before go-live: set expectations on search timing. A brief migration completion notice that names a specific search availability window - and explains why the window exists - eliminates most of the helpdesk volume that would otherwise arrive in the first two days.
Clone Master is designed to carry metadata and permissions across tenants within the capabilities of the SharePoint Migration API, which reduces the volume of post-migration cleanup. See what Clone Master preserves during cross-tenant migrations.
Why search health belongs in your migration acceptance criteria
Migrations are evaluated on whether files landed in the right place. Search is rarely measured as a separate acceptance criterion, which is why it becomes the most visible problem after go-live.
Adding search quality to your acceptance criteria is a small policy change. It means running a search validation test 48 hours after migration completes: a defined set of test queries that should return known results, run by representative users from different access groups. If those queries return the expected results, search is healthy. If not, you have a structured basis for identifying whether the cause is recrawl lag, a permission gap, or broken links - rather than a general sense that "search isn't working".
The investment in that test plan is small relative to the cost of an unstructured hypercare period where every helpdesk ticket is investigated from scratch. Migrations that include search validation as a formal checkpoint finish hypercare faster and carry more credibility with the users who depend on the content.
Frequently Asked Questions
How long does SharePoint search take to index content after migration?
SharePoint Online's search index typically crawls newly migrated content within 24 to 72 hours for most tenants. High-volume migrations can push this out further depending on queue depth. There is no mechanism to force a priority recrawl for migrated content, so setting user expectations in advance is the main lever available to admins.
Why can some users find migrated files in search but others cannot?
SharePoint search enforces permissions at query time. If a user does not have permission to access a file, it will not appear in their search results even if the file is indexed. Inconsistent permission migration - particularly for files that had unique permissions on the source - is the most common cause of search results that differ between users after a migration.
Why do SharePoint internal links break after migration?
When content moves between sites, site collections, or tenants, any absolute URLs embedded in pages, document metadata, or list fields continue to point to the original location. If that location is decommissioned or renamed, those links break. Site Pages that contained links to document library items are particularly vulnerable. A find-and-replace tool can scan for old domain patterns and update them in bulk.