Archiving old Salesforce records to cut storage without losing history

What is actually filling your Salesforce storage?#

Salesforce storage fills from two separate pools: data storage, used by records such as accounts, cases, tasks and email messages, and file storage, used by attachments, Salesforce Files and documents. The storage usage page in Setup shows which objects take the most space, and it is the first screen to open before anyone proposes deleting anything.

In software companies the usual culprits are predictable. Email-to-Case creates an email message record for every inbound and outbound email, activity capture tools log tasks and events in bulk, integrations write log records nobody reads, and closed cases pile up with their attachments. Each is a different archiving decision.

Write down the top objects, how old their records are and who still opens them. A storage problem driven by integration logs is solved very differently from one driven by years of customer email.

Delete, archive inside Salesforce or archive off-platform?#

The choice between deleting, archiving inside Salesforce and archiving off-platform comes down to what you need later: the history itself, everyday access from the record page, or neither. Every option frees storage, but only two of them keep history.

What deleting really costs#

Deleting Salesforce records costs more than the records themselves, because related data goes with them. Deleting a parent can remove child records, email messages lose the case they explained, and reports built on multi-year trends silently change.

Deleted history is also history you cannot use later. Support cases linked to product releases, opportunity stage changes and the notes behind lost deals explain how the business actually worked. They support audits, renewals and disputes, and they are the kind of operating record AI developers now license from established companies.

If deletion is right for a record family, such as integration logs with no business meaning, document the decision, the date range covered and who approved it.

How big objects and archiving tools work#

Salesforce big objects store very large volumes of records on the platform for data that must be kept but is rarely touched. They are built for volume rather than daily use, so search, reporting, sharing and automation work differently than on standard objects. Check what your users actually need before moving records there.

Archiving products, from Salesforce and from AppExchange vendors, package the same idea: they move old records out of standard storage on a schedule and let users view or restore them. When comparing tools, ask each one the same questions.

• 1Are parent-child relationships kept, such as case to email message to account?
• 2Are files and attachments archived, or only records?
• 3Can users see archived records from the original record page?
• 4Can records be restored with their original IDs?
• 5Where is the archive stored, and can you export it in full if you leave the tool?
• 6How are privacy deletion requests applied to archived records?

Get a complete copy before anything moves#

A complete copy is the safety net under every archiving option, and the Salesforce Data Export Service is the simplest place to start. According to Salesforce Trailhead, a manual export can run every 7 days in Enterprise, Performance and Unlimited Editions, while Professional and Developer Editions can generate backup files only every 29 days.

The export can include images, documents and attachments, plus Salesforce Files and CRM Content document versions, at the cost of longer processing, and it arrives as zip files of CSVs. One Salesforce partner's guide says the zip files are deleted 48 hours after the notification email and that the feature is not available in sandboxes, so download promptly into controlled storage.

Large orgs usually need API-based tools for volume. Whatever the route, keep every record ID and lookup field, because IDs are what let you rebuild the link from an email message to its case and from the case to the account.

Illustrative: a vertical SaaS company over its storage limit#

Illustrative: a fictional company selling scheduling software to commercial cleaning contractors runs support in Service Cloud with Email-to-Case. Storage alerts start arriving, and the CFO is asked to approve extra storage.

The IT lead's first proposal is to delete closed cases from the product's early years. The head of support objects: those cases link to engineering issues and explain how the scheduling logic was fixed release by release. Instead, the team exports cases, email messages and attachments with their IDs, loads them into the company's data warehouse, checks counts against Salesforce reports and only then removes old email messages from the org.

Storage falls back under the limit, agents still see case summaries on each account, and the full threads stay queryable in the warehouse. When leadership later asks whether its support history could be licensed, the archive is already complete and linked.

What should stay inside Salesforce?#

Salesforce should keep the records people use to serve customers today, and the archive should hold the rest. Draw the line by how each record family is used, not by one cutoff date for every object.

How SourceX looks at archived CRM history#

SourceX looks at an archived Salesforce history as one of the stronger forms of operating records, because a well-built archive keeps cases, emails, opportunities and accounts linked by ID. In the fit check, a company describes the archive with metadata only: objects, years covered and whether threads and outcomes are complete.

Under the SourceX Enterprise Data Value Framework, linked history rates well on human-generated signal and domain expertise, while privacy burden and preparation cost reduce net value, since customer names, email addresses and signatures in threads all need removing. Rights review checks customer contracts and platform terms, and every approved package carries a SourceX Evidence Packet.