FIELD NOTE / MICROSOFT 365 / SHAREPOINT / SEARCH
The migrated project record opens by URL but disappears from SharePoint search
The migration dashboard says the archive moved. A direct link opens the required drawing, yet a project engineer searching its exact legacy number gets no result. Copy completion and retrieval acceptance are different controls: one accounts for destination objects, while the other proves that authorised people can find the right evidence without already knowing its URL.
The situation: copied successfully, operationally invisible
COMPOSITE SCENARIO: documented product behaviour combined with recurring operational failure patterns. No client-specific delivery claim is attached. Consider a Perth civil-engineering consultancy moving fifteen years of completed-project records from a file share and legacy SharePoint estate into SharePoint Online. The migration reports show the expected document count with no material failures. A retained link opens a drainage drawing named DRG-0427-C03.pdf, and its library row displays project number WA-0427, discipline and record class.
A project engineer searches WA-0427 from the new hub and receives current correspondence but not the drawing. Searching the full file name sometimes works for an administrator. Filtering a custom search page by record class returns nothing. Another user sees a superseded copy above the approved record. The archive exists, but its indexed representation and security-trimmed retrieval do not match the business expectation.
The migration team initially requests a site reindex. A schema change may justify delay. Record the specific crawl and index state before assigning the cause. The target library can be excluded from search; metadata may not map to the intended managed property; a query template can exclude the content type or path; migrated permissions can change who receives results; duplicate trimming or ranking can hide an expected copy; or the index may not yet contain the changed item. Each explanation requires different evidence.
Freeze acceptance and preserve four evidence planes
Do not delete, remigrate or repeatedly reindex the archive while the cause is unknown. Preserve the source inventory, migration task and item reports, destination URLs and IDs, library/search settings, search-schema mappings, permission records, query text, persona, timestamp and raw result evidence for a bounded sample. Keep the legacy source read-only until retrieval acceptance and records obligations are signed off.
Separate four evidence planes. Reconciliation compares expected source items with destination items. Crawl eligibility proves the site, library and item may enter the index. Indexed representation proves content and metadata reached the intended managed properties. Retrieval proves a particular query, scope and authorised persona returns the right item without prohibited disclosure.
A green migration report addresses only part of reconciliation. Microsoft Migration Manager reports distinguish scanned, filtered, expected, migrated and not-migrated items, and detailed reports can identify individual outcomes. Those reports are essential but time-limited; retain them with the release pack. They do not certify ranking, managed-property values, query templates or security trimming.
Prove that the content is eligible to be indexed
Check the target site setting that allows content to appear in search and the library setting that allows its items to appear. Confirm the expected URL returns the supported, readable object. Exclude migration placeholders and report rows from the known-item set. Record approval, draft, checkout and publication states where they affect the required persona’s access. Capture temporary search-result removals and tenant-level discovery restrictions as part of the tested query state.
Permissions determine both direct access and search-security trimming. SharePoint search is security trimmed: an account normally receives results only for content it may access. Check group membership separately from ownership. Microsoft documents cases where an owner without membership receives different search results. Test the engineer’s effective access through the same identity and group path used in production, then test a prohibited persona. An administrator finding the file proves neither ordinary-user recall nor safe security trimming.
Use direct access carefully. Opening a shared link confirms current access to one object. Inspect the indexed security descriptor and run the chosen search scope to establish discoverability. Record the account, browser session, URL, permission source and exact query time so apparently conflicting observations can be reconciled.
Trace legacy metadata into managed properties
SharePoint extracts content and metadata as crawled properties, then maps selected values into managed properties used by search. A visible library column confirms the stored display value only. Inspect the crawled and managed property values required for query, search, retrieval and refinement. Site columns with populated content can generate crawled and managed properties, while local or recreated columns may have different internal names and mappings from the legacy estate.
For project number, record class, discipline, approval state and source identifier, record the target column ID/internal name, column type, sample value, discovered crawled property, mapped managed property, mapping order and relevant attributes. Query the exact managed property and request it in the selected properties. If WA-0427 is visible in a list view but absent from the property returned by search, the indexed representation lacks the expected value; user vocabulary is outside that result.
Use an available refinable managed property where refinement or sorting is required; do not assume a newly created text property has every capability. Treat PnP community documentation and tools as practitioner implementation aids. They are useful for inspecting raw search responses and mapping conventions, but the supported behavior and permissions must resolve to Microsoft documentation and local evidence.
Reduce the search to a falsifiable query
Start with a known destination URL and its stable identifiers. Run a path-bounded known-item query, then exact file name, title, full-text phrase and managed-property queries. Capture query text, scope, result source, query template, selected properties, refiners, duplicate-trimming setting, returned row count, rank and result URL. Compare site search, hub or organisation search, and any custom PnP search page as separate products.
A custom result page can add hidden constraints for path, content type, record class or date. A valid index result can disappear because the query template excludes it, the wrong result source is selected, a filter references an unmapped property, or a presentation slot requests a property that was never selected. Test the raw SharePoint Search API before changing the page. The open-source SharePoint Search Query Tool and PnP query commands expose primary, refinement and raw result sets and can help isolate service results from UI configuration.
Add title, author, record class, date, phrase, permission and prohibited-item queries to the exact-code test. Tokenisation and punctuation can change identifier matching; filenames, titles and body text behave differently; rank can place a technically returned item beyond a user’s practical scan depth. Define expected retrieval position where known-item finding matters, and record alternate terms real staff use.
Repair the smallest failed boundary
If the site or library is excluded, enable search only after confirming the intended information boundary. If permissions are wrong, repair ownership and group membership through the approved access model; do not broaden access merely to improve recall. If the metadata path is wrong, standardise the target site columns, populate values, map the correct crawled properties to controlled managed properties and update the query contract.
After a schema or mapping change, request a reindex of the affected library or list first. Escalate to site or tenant scope only when the results identify a wider indexing problem. Microsoft warns that site reindexing can place significant load on search and recommends it only when changes require all items to be reindexed. Record the request time and allow the scheduled crawl/index process to complete; repeated requests do not convert an asynchronous service into a synchronous one.
If reconciliation is wrong, isolate missing, filtered, failed or duplicate migration items using the retained task reports and destination manifest. Remigrate only the attributed subset through an idempotent plan. Preserve source identifiers and approved metadata, and make superseded/duplicate disposition explicit. Rebuilding a custom search page is justified only when the raw index is correct and the page’s query or presentation contract is the failed boundary.
Accept retrieval with a controlled query set
Construct a gold set from business-owned examples: exact known documents; records found by project number, title phrase, author, discipline, record class and date; deliberately similar superseded copies; recent changes; inaccessible records; and items that must not be returned. Include common vocabulary, punctuation variants and misspellings where the business depends on them. Record an expected result set and an accountable relevance judgement for each query.
Measure known-item success, relevant results within the first ten positions, false positives, prohibited disclosures and freshness separately. Precision and recall measure a bounded judged set. Extending the result to the entire tenant requires a documented sampling design. NIST’s TREC work demonstrates why repeatable test collections and topic-level evaluation matter; an average can hide a critical project query that fails completely.
Run the matrix as records user, engineer, project manager, external collaborator if applicable, site owner and prohibited persona. Repeat in fresh sessions on the supported search surfaces. Acceptance requires destination reconciliation, expected managed-property values, positive retrieval, negative security results, tolerable freshness and a documented explanation for every exception.
Make search acceptance part of migration and change control
Define retrieval acceptance before migration waves begin. Preserve reports before their platform retention expires, and join source identifier, destination URL, content hash or size, metadata values, permission disposition and search-test ID. Build the sample from the risk register: records required for safety, contractual evidence, active disputes, long identifiers, unusual formats, unique permissions and superseded versions deserve deliberate coverage.
Version the managed-property register and query templates. Rerun affected tests after column, content-type, permission, hub, result-source, search-page, retention or migration changes. Monitor failed known-item queries and user feedback without treating popularity as relevance truth. A record can be rarely searched and still be essential.
Do not infer that SharePoint is the right archival or discovery architecture solely because indexing can be repaired. Retention, legal discovery, metadata quality, immutable evidence, scale, export and operating ownership remain separate fit decisions. The controlled outcome is narrower: authorised people can reliably retrieve the agreed migrated evidence, unauthorised people cannot, and the proof can be repeated after the next change.