Search parity is demonstrated by a versioned query set that compares known-item retrieval, answer support, citations, permissions, and failure states across source and destination.
Query set derived from real retrieval obligations
Build the suite from query logs, known-item questions, support cases, source-owner examples, stale-answer incidents, and permission-sensitive lookups. Include exact titles, identifiers, acronyms, natural-language questions, old terminology, and queries expected to return nothing. Each case should name the relevant source record or supported answer, authorized identity, unacceptable records, source behavior, and the destination criterion. Hold a subset out from ranking configuration to reduce tuning directly to every acceptance case.
A migration does not require identical rank order when the destination uses a different retrieval system. Define parity around user obligations: the known document appears within an agreed depth, the answer cites an authoritative current span, restricted content remains absent, deprecated material is marked or excluded, and unsupported questions do not invent a source. Preserve accepted differences and the buyer's reason for accepting them.
Content, permission, and freshness dimensions
Run each query against named source and destination snapshots. Record result identifiers, ranks, snippets, citations, access decisions, content versions, and evaluator disposition. Separate missing ingestion from poor retrieval: a document absent from the index needs a pipeline repair, while an indexed document below the criterion needs ranking or query work. A permission failure is a release hold even when the answer text appears correct.
Freshness cases should include an updated record, a deleted record, an expired policy, and two conflicting versions with different authority. The destination should surface the approved current source and retain enough provenance to explain why. Incremental synchronization tests also need a time boundary: record the source change, detection time, destination update, failed attempts, and final query result rather than saying only that synchronization is automatic.
Cutover report and continuing regression suite
Summarize passes and holds by query class, but keep every raw case behind the report. Define the cutover gate, accepted exceptions, rollback trigger, and owner of each unresolved item. Rerun the suite after the final incremental sync and after redirects or answer systems switch to the destination. The suite should remain with the maintainer because relevance, content, permissions, and connectors continue changing after migration day.
SourceCurrent implements the parity suite through Reality Contact, LLC. The buyer chooses acceptance thresholds, interprets business importance, and authorizes the switch. The report demonstrates the supplied cases and identities at a named corpus state; it does not claim universal equivalence between platforms.
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 scan and risk reporting; Azure AI Search document-level authorization patterns.