A controlled knowledge migration identifies the source state, defines how every record and permission maps, proves retrieval parity on representative questions, and keeps a rollback path until the buyer approves cutover.
Source inventory and migration contract
Inventory content types, records, attachments, comments, versions, authors, owners, timestamps, tags, links, redirects, permissions, deleted states, and export limits before transforming anything. Count records by class and identify which source features have no direct destination equivalent. A migration contract should define canonical identifiers, content and metadata fields, attachment treatment, encoding, timestamp semantics, permission principals, deletion signals, and the rule for records that fail parsing.
Microsoft's SharePoint Migration Tool guidance begins with scanning and an assessment report that exposes inventory and risks before migration. Apply the same principle regardless of platform: preserve the raw export, tool version, extraction time, checksums, and source-side counts so later discrepancies can be traced to extraction, transformation, or destination ingestion. Do not normalize away source errors before they are recorded.
Staged load, reconciliation, and permission checks
Load a representative stage before the full corpus. Reconcile source and destination counts by content class, then inspect missing records, duplicate canonical keys, truncated fields, broken attachments, altered links, and unsupported metadata. Sampling should cover old and new records, large files, nested pages, non-English content, duplicate titles, deleted or archived material, and every permission pattern. A successful API response is not proof that the destination record is readable or correctly authorized.
Run permission tests as named users or groups and include denied queries. Identity mapping deserves its own ledger because a source principal can be missing, renamed, or mapped to the wrong destination identity. Microsoft warns that content owned by users who are not migrated can lose working access. Keep unmapped principals as explicit exceptions with an owner and approved treatment before any production switch.
Parity approval, cutover, and rollback
Use known-item and answerability queries to compare retrieval, citations, and permission behavior between source and destination. Record accepted differences caused by a new ranking model or unsupported feature rather than forcing identical ordering. Establish a change freeze or incremental sync window, rerun source-to-destination counts, confirm redirects, test monitoring and deletion, and keep the source available until the buyer accepts the evidence and rollback condition.
SourceCurrent prepares the migration and parity record through Reality Contact, LLC. The buyer decides which exceptions are acceptable, approves the cutover time, grants destination access, and authorizes any source retirement. The report covers the confirmed corpus and test set; it does not guarantee that every untested record or query behaves identically.
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 Tool scan and assessment; Microsoft SharePoint migration settings and permission preservation.