What is Salesforce data archiving?

Salesforce data archiving is the practice of moving older records or files off Salesforce's own (expensive, per-GB) storage to lower-cost external storage, on a retention schedule, while keeping them retrievable for as long as they're still needed — usually for compliance, audit response, or straightforward storage-cost reasons.

It's a different problem from backup. A backup is a point-in-time snapshot of your whole org, meant for disaster recovery — restoring everything back to a known-good state after data loss or corruption. Archiving is selective and ongoing: specific records or files, moved deliberately based on age or a retention policy, retrieved individually rather than restored wholesale. A tool built for one doesn't automatically solve the other.

In a compliance context, archiving is usually paired with two more requirements that backup tools don't need to think about at all: retention policy (how long a record has to be kept, and what happens once that period ends) and legal hold (a flag that overrides retention and prevents deletion, regardless of how long a record has been sitting, for as long as it's needed for litigation or an open investigation).

Common challenges with Salesforce data archiving

Most of these don't show up during evaluation — they show up the first time someone actually needs an archived file back, often mid-audit.

How to archive data in Salesforce

  1. Audit what's actually driving storage costs and compliance exposure. Which objects hold the bulk of your file storage? Which of those are also the ones a regulator or auditor is realistically going to ask about?
  2. Decide retention per object or use case — not one blanket org-wide policy. A CAPA/complaint record's retention requirement is rarely the same as a routine sales attachment's.
  3. Pick where archived files will actually live. Salesforce Big Objects can't hold binary file content and offer no real WORM (write-once-read-many) guarantee, so the common real-world pattern is external immutable storage — an S3-compatible bucket with Object Lock enabled, for example — rather than trying to keep everything inside Salesforce's own storage layer.
  4. Decide your retrieval path before you commit to a tool, not after. Ask directly: once a file is archived, can it be pulled back into whatever merge/export workflow you already rely on without a manual restore step first? This is the single question most evaluations skip, and the one that causes the most pain later.
  5. Build (or confirm) a legal-hold state machine. A hold needs to override every disposal setting, and every deletion — scheduled or manual — needs to re-check hold status at the moment it runs, not just rely on a flag set once.
  6. Test retrieval under audit-like conditions before go-live. Simulate an actual "produce this record's complete documentation, now" request before the first real one arrives, not after.

Comparing the real vendors

Pricing and positioning below reflect what's publicly documented for each vendor. Where a number isn't publicly listed, this guide says so rather than guessing.

Vendor Pricing Retrieval after archiving Best fit
FilePreserve $499/mo flat, per org — unlimited users Automatic — pulled back in the moment it's selected Audit-ready cross-record export, not just storage
DataArchiva ~$499/mo (~$6K/yr), flat & config-driven Manual, via DataArchiva's own console Flat-rate, admin-configurable archiving
Odaseva $5,000/user/yr+ (Professional), per-seat Manual, through Odaseva's enterprise flow Enterprise backup/restore/compliance breadth
GRAX Not publicly listed, sales-led Own access platform; not evaluated against automatic restore Enterprises with an existing GRAX relationship
XfilesPro Not publicly listed, storage-offload focused Storage offload only, no merge/export workflow Storage cost is the problem, not export
Own (formerly OwnBackup) Archive ~$1,000/mo+, per-product, enterprise Manual, through Own's own product line Orgs buying backup + archive through Salesforce

Own was acquired by Salesforce in 2024.

FilePreserve isn't trying to out-compete DataArchiva or Odaseva on archiving depth, storage scale, or compliance-attestation breadth — that's a fight against funded, established platforms with a years-long head start. The real gap it targets is narrower: no archive vendor on this list ships a built-in cross-related-record merge tool with automatic file restore, and no document-merge tool can see a file once any of these archive vendors has moved it. FilePreserve is both halves of that workflow at once.

Best practices checklist

Frequently asked questions

Is Salesforce archiving the same as backup?

No. Backup is a point-in-time snapshot of your whole org for disaster recovery. Archiving is selective and ongoing — moving specific records or files based on age or retention policy, retrieved individually rather than restored wholesale.

Can Salesforce's built-in Archive feature handle this?

It covers a limited set of supported objects, and doesn't include custom retention policies, a legal-hold state machine, or cross-record merge/export controls — so it tends to be outgrown quickly by any org managing FDA/CMS-scale audit documentation requirements.

Does archiving files break existing document-merge tools?

Often, yes. Most archive vendors move files to their own storage in a way standard Salesforce APIs — and the merge tools built on top of them — can't reach until the file is manually restored through the archive vendor's own separate console.

How is FilePreserve different from the vendors above?

It's the only tool in this comparison that combines archiving, cross-related-record merge, and automatic file restore on select into one system — so a file being archived doesn't change how you retrieve it for an audit-ready export. See the "Why it's different" section on the homepage for the full comparison, and the pricing page for what's included.

Want to see how FilePreserve handles your own archive-and-retrieve scenario?