Permission preservation requires a source-to-destination identity map, record-level access metadata, tests for allowed and denied users, and an approved disposition for every unmapped principal.
Source principals, groups, inheritance, and ownership
Export the identities and groups that can access each content class, including inherited permissions, link-based access, external guests, service accounts, and owner roles. Normalize identifiers without discarding the original value. A display-name match is not enough when two people share a name or an email domain changed. Record the destination principal, match type, evidence, affected record count, and the owner authorized to approve or reject the mapping.
Microsoft's identity-mapping guidance separates exact, partial, and no-match records and warns that content owned by users who were not migrated may lose access. Treat partial matches as review items and no-match identities as blocked until a responsible owner supplies a destination treatment. Never solve an unmapped restricted user by broadening the destination record to everyone.
Authorization carried through indexing and query
The destination index needs the permission metadata required at query time, and the application must pass the authenticated caller's identity or group claims into the authorization check. Azure AI Search documents document-level access patterns that store identity or ACL metadata during indexing and filter results against the caller at query time. The exact implementation varies, but the acceptance property is stable: unauthorized records must not appear in results, citations, suggestions, counts, or answer context.
Test one allowed and one denied identity for each permission class, including inherited access, changed group membership, archived content, and deleted users. Repeat tests after incremental synchronization because a working initial load can still leave stale access when source permissions change. Keep permission logs free of sensitive content while retaining the principal, record identifier, decision, policy version, and timestamp needed to investigate an unexpected result.
Exception approval and cutover controls
The permission ledger should classify every exception: unmapped principal, unsupported inheritance, external guest, public link, orphaned owner, destination limitation, or pending approval. Each row needs the affected content, temporary treatment, risk owner, due date if applicable, and final disposition. Cutover criteria can require zero unexplained mappings while permitting named exceptions that the buyer explicitly approves.
SourceCurrent prepares and tests the mapping through Reality Contact, LLC. The buyer's identity and content owners confirm principals, approve exceptions, and grant production access. The service does not decide who should be authorized, and no technical test substitutes for the buyer's security, privacy, legal, or records-management review.
Where the service stops
Reality Contact, LLC implements and verifies the migration but does not decide records-management or legal-retention policy, grant user access, certify security or compliance, delete the source system, or switch production users without the buyer's approval. The buyer reviews content, permission, retrieval, freshness, exception, and rollback evidence, approves parity, and switches authorized users and answer systems to the migrated platform. This is technical migration and documentation; it does not replace the buyer's security, privacy, legal, records-management, procurement, or platform-owner review. We do not promise perfect parity, preservation of unsupported source features, universal retrieval quality, uninterrupted connectors, or the absence of untested permission and content defects.
Sources: Microsoft SharePoint migration identity-mapping guidance; Azure AI Search document-level access control.