ServiceNow Replication vs Archive: What Each Provides
A replication pipeline can supply an archive. It can also produce a database that nobody outside the data team can use. To choose the right design, start with the task: do you need a refreshed dataset, historical records people can retrieve, or both?
Replication and archiving have different jobs
Replication keeps selected source data synchronized with a target for reporting, integration or other downstream use. An archive retains a defined historical scope and provides a way to retrieve it. A single implementation can do both, but a synchronized copy needs explicit retention and deletion rules if it is also the historical record.
ServiceNow’s native features have another role. System Archive moves inactive records into archive tables in the instance. Live Archive, available with RaptorDB Professional V2, moves records and attachments to object storage while keeping access in ServiceNow. Neither feature’s documented retrieval path establishes independent access after the instance is retired.
Data shape is the first validation point
Check what the replication tool changes. It may select only some tables, add tracking columns, transform references or flatten relationships. Those choices may suit analytics. Historical retrieval also needs the values and links that let a person understand the original record.
Before choosing an approach, compare a representative source record with the retained copy. Trace the record’s parent and child relationships, journal entries, approvals, attachments, display values, custom tables, and deletion behaviour. Document every transformation that matters to the retrieval use case.
Ask these questions before approving either option
- What records and periods must be retained, and what happens when the source deletes them?
- Are journal entries, attachments, references, approvals, and custom tables included?
- Does the target preserve readable values as well as internal identifiers?
- Can authorized users search, view, print, or export a record without ServiceNow?
- How are authentication, authorization, audit logging, encryption, backup, and disposal handled?
- Can the design handle the expected record volume and unusually large histories?
- When is the final sync, how are failures reconciled, and who accepts the retained scope?
Run an independent retrieval test
Select difficult records while the live instance is still available: a long journal history, multiple attachments, custom fields, related tasks, and a sensitive access case. Using only the proposed retained-data solution, ask an intended user to find each record, understand its context, and produce the required output. Compare the result with ServiceNow and record discrepancies.
For each scoped table, compare expected records with delivered records and explain the difference. Do the same for attachments; use checksums where practical. Then inspect fields and relationships and test allowed and denied user access. Counts show coverage; the retrieval exercise shows whether users can do the job.
Where Cortex Archive fits
Cortex Archive for ServiceNow provides the search and record-viewing interface for supported historical data, including relationships and attachments. Its source connection can use read-only database credentials, while configuration sits in a separate read-write store. Cortex 3.2.0 release notes describe the ServiceNow Sync Utility, full-text search and CSV export of search results. Validate the acquired schema, custom data, attachments, access controls and performance against the version you will deploy. Keep the extraction report alongside the archive’s acceptance results.
Define the final sync before shutdown. Name the source, selected records, transformations, cutoff and owner of any failures. Agree whether later deletions should remove retained records, be recorded as changes, or wait for an approved disposal decision. A pipeline designed to mirror the source can otherwise remove history you intended to retain.
Frequently Asked Questions
Is ServiceNow replication the same as an archive?
No. Replication usually maintains a copy for downstream use; an archive is designed around retained-record retrieval. Some products can support both outcomes, but the implemented data scope, transformations, interface, controls, and independence determine the result.
Does ServiceNow’s native archive provide independent access?
System Archive stores data in archive tables; Live Archive uses object storage but retrieves it through ServiceNow. A different storage location does not establish a standalone retrieval service. If you must retire the instance, verify a separate access path and the applicable contractual terms.
Is a replicated database automatically readable?
No. It may contain the necessary rows without preserving readable display values, relationships, attachments, or a usable interface. Test representative records rather than relying on row counts alone.
Must an archive preserve every ServiceNow table?
Not necessarily. Preserve the approved record scope and the context needed for the stated retrieval purpose. Record owners, legal counsel, security, and compliance teams should decide scope and retention; the technical team should prove what the implementation captured.
Can Cortex replace ServiceNow’s authorization model automatically?
Do not assume that. Cortex supports its own authentication and security configuration, but source-specific authorization parity must be designed and tested for the deployment.
What happens when the source deletes a record?
That depends on the replication configuration. Some pipelines propagate deletions; others keep them or record a deletion marker. Compare that behaviour with your retention policy and legal holds, and test it before treating a replicated dataset as the archive.
Evaluating a retained-data design? Review Cortex Archive for ServiceNow and test it with the output of your chosen export or replication process.