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.
- Storage costs escalate as an org grows. Salesforce's own file storage is priced well above commodity cloud storage, and attachments/files tend to accumulate indefinitely without an active archiving discipline.
- Archived files become hard to reach again. Most archive vendors move a file to their own storage in a way that standard Salesforce APIs — and whatever document-merge or export tool you already use — simply can't see anymore. Getting it back means logging into the archive vendor's own separate console and manually restoring it first.
- Merge and export tools weren't built with archiving in mind. Tools built to assemble documents from a record (and its related records) generally assume every file is still live in Salesforce. The moment a file has been archived by a separate vendor, most merge tools simply can't include it — not a bug, just two tools that were never designed to talk to each other.
- Compliance requests span several related lists, not one object. An FDA CAPA/complaint response or a CMS RADV request rarely maps to a single record's own attachments — it usually needs everything tied to a case, member, or claim across several related objects, assembled into one packet.
- Legal hold has to be provably enforced, not just configured. A checkbox that says "on hold" is only as good as whether every deletion path actually re-checks it at the moment of deletion — not just when the record was first flagged.
How to archive data in Salesforce
- 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?
- 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.
- 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.
- 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.
- 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.
- 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
-
Inventory what's actually driving storage costs before picking a tool — don't archive by default without knowing what's using the space.
-
Set retention per object or use case, not one blanket org-wide policy.
-
Before committing, confirm: can this tool retrieve an archived file without a manual restore step, inside whatever merge/export tool you already use?
-
Test retrieval under audit-like conditions before go-live — not after the first real audit request arrives.
-
Make sure legal hold provably overrides retention/disposal settings — re-checked at the moment of every deletion, not just set once in the UI.
-
Know where the bits actually live — your own cloud account versus a vendor's multi-tenant storage — and what that means for your own compliance posture.
-
Budget for the real evaluation cycle a compliance buying committee runs — this category typically isn't a same-day self-serve decision, regardless of sticker price.
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?