ServiceNow System Archive vs Live Archive: What Happens When You Retire the Instance
ServiceNow now has two ways to archive data: System Archive and Live Archive. They store data in different places, and people often assume that means one of them gets your data out of ServiceNow.
It doesn’t. Both are built for an instance that’s still running. If you’re planning to retire the instance, the question that matters is simple: once it’s gone, how will anyone read those records?
The two features store data differently
This is where most of the confusion comes from.
System Archive moves inactive records into archive tables, usually prefixed ar_, in the same database. It’s included with every instance. It makes your active tables smaller and faster, but ServiceNow states it does not reduce primary storage usage, because the archived records stay in the same database.
Live Archive is newer. Administrators set retention rules, such as archiving closed incidents older than 12 months, and Live Archive moves those records into cheaper storage tiers while keeping them queryable. It does reduce primary storage. It also requires RaptorDB Professional, a separately licensed database.
Different storage, same dependency. Here’s how they compare with an independent archive:
| ServiceNow System / Live Archive | Independent off-platform archive | |
|---|---|---|
| Where the data lives | System: archive tables in the instance. Live: object storage | A copy you hold outside ServiceNow |
| How users read it | Through ServiceNow | Through the archive’s own interface |
| After the instance is retired | Not readable. Export it before shutdown or it goes with the instance | Readable, if you’ve acquired and tested it |
| What it’s for | System: faster active tables. Live: lower primary storage | Keeping records usable after the platform is gone |
| Who controls access | ServiceNow ACLs | Whatever access model you configure and test |
Moving data isn’t the same as owning it
Live Archive moves data to a different storage tier. That’s a capacity decision. It doesn’t give you a standalone archive you can run without ServiceNow, and ServiceNow doesn’t position it that way. Its own launch material describes Live Archive as a way to avoid going off-platform.
That’s fine if you’re staying on ServiceNow. If you’re leaving, it’s the wrong tool for the job.
Before shutdown, confirm three things in writing: what data you’ll receive, in what format, and who will run the retrieval service after the contract ends.
The test: can you read it without ServiceNow?
Before shutdown, have a real user find a record, follow its related records, open its attachments and export what they’d need for an audit, using only the proposed archive. Then do the same with a restricted user and make sure they can’t see what they shouldn’t, in search results, record views or attachments.
Compare everything against the live instance while you still have it.
Where an independent archive fits
Cortex Archive for ServiceNow is a self-hosted, read-only interface to the ServiceNow records you retain. Getting the data in is a separate step: the ServiceNow Sync Utility, described in the current Cortex release notes, pulls exports through the API into PostgreSQL. Cortex then reads that database with read-only credentials.
Test both stages with your own data before you accept the archive: what came across, whether the attachments open and whether access works the way you configured it.
You don’t have to choose one or the other. Use native archiving to keep a running instance fast. Add an independent archive for records that have to survive the instance. Plenty of teams will need both.
Frequently Asked Questions
Does native ServiceNow archiving move data out of ServiceNow?
Live Archive moves it to object storage. System Archive keeps it in archive tables in the instance. Either way, you read it through ServiceNow, so neither gives you access after retirement.
Can ServiceNow archiving meet retention and audit requirements?
While the instance is running and the archive and destroy rules are set up correctly, it can. If the records have to stay retrievable after the instance is retired, you need an independent archive.
What’s the difference between System Archive and Live Archive?
System Archive moves inactive records into ar_ tables in the same database and doesn’t reduce primary storage. Live Archive moves them to object storage, does reduce primary storage and requires RaptorDB Professional.
Do destroy rules give me a compliant retention policy?
No. A destroy rule deletes data. Your records and legal owners still need to approve the retention schedule, legal holds and who can authorize disposal.
How does Cortex get ServiceNow data?
In two stages. The ServiceNow Sync Utility, covered in the current Cortex release notes, pulls exports through the API into PostgreSQL. The Cortex archive then reads that database with read-only credentials.
When should I choose an off-platform archive?
When the records need to be readable after ServiceNow is gone. If you’re staying on the platform, native archiving is the right tool. If you’re doing both, use both.
Related reading
- Why DIY ITSM Archives Fail Audits
- Retire the Platform, Keep the History: Build vs Buy
- ServiceNow System Archive documentation
- ServiceNow Live Archive / RaptorDB Pro Australia release notes
Retiring ServiceNow and need the history? Look at Cortex Archive for ServiceNow and test an independent retrieval path with your own records.