A migrated knowledge base stays current when source changes have stable identifiers, explicit update and deletion events, freshness limits, failure receipts, and queries that expose stale content.
Stable identifiers and change signals
Assign every canonical record a stable source identifier that survives title or path changes. Record created, updated, deleted, effective, and expiry timestamps separately when the source provides them. Algolia's incremental-update guidance relies on unique object identifiers to match source and index records; the same requirement applies across destinations. Without a durable key, an edit can become a duplicate and a deletion can leave an orphaned searchable copy.
Choose the synchronization mode per source: event-driven change feed, scheduled incremental pull, periodic full reconciliation, or a combination. Define how additions, edits, moves, merges, permission changes, expirations, and deletions are represented. Preserve the source event and destination receipt, including retries and dead-letter items. A successful job count should reconcile to concrete records rather than only showing that the scheduler ran.
Authority, expiry, and stale-source handling
When several documents address the same topic, record authority, product version, jurisdiction or business unit where relevant, effective date, and superseding relationship. Expired material can be excluded, visibly marked, or retained for authorized historical lookup according to buyer policy. The answer system should not silently combine current instructions with an older conflicting source merely because both rank highly.
Create stale-answer probes from incidents and high-value questions. Each probe names the authoritative record and version expected after a source change. Monitor time from source update to destination visibility, failed partial updates, duplicate growth, deleted-record exposure, and queries that still cite deprecated material. These measurements identify whether the system is current for the workflows that matter rather than offering an abstract index-freshness percentage.
Maintenance ownership and recovery
The runbook should show how to pause ingestion, replay a failed window, rebuild an index, compare counts, restore permission metadata, verify a deletion, rotate connector credentials, and rerun the relevance suite. Name the source owner, pipeline owner, destination owner, and person who resolves content authority. Alerts need a destination and a response expectation; an unread dashboard does not operate the freshness system.
SourceCurrent installs and documents the synchronization controls through Reality Contact, LLC. The buyer sets retention, expiry, authority, and access policy, supplies maintainers, and decides when the source platform can be retired. Continuing provider costs and operational responsibility transfer at handoff unless a separate agreement says otherwise.
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: Algolia incremental-update documentation; Algolia data synchronization strategies.