Records migrate cleanly with the standard tools. Files are where org-to-org moves quietly lose data — and nobody notices until someone opens an empty record months later.
Attachments, ContentVersions, and document links don't travel the way rows do. Volume, API limits, and reference remapping turn "just move the files" into the part of the project that slips. This is the architecture we built Relay around.
Why files are different from records
A standard data migration tool handles objects, fields, and relationships well. Files are different: they have binary content, they link to records via ContentDocumentLink, and they have version history. Migrate them naively and you get broken links, missing thumbnails, or files that arrived with the wrong owner.
At volume — six years of a mid-size org can mean millions of files — you're also fighting Salesforce API limits on both ends simultaneously. Something has to act as a buffer.
Why we stage through S3
Pushing files directly between two orgs means fighting both orgs' limits at once. Staging in your own S3 bucket decouples extract from load: pull once, verify, then load at a pace the target org is happy with — and you keep a durable copy the whole time.
- Extract from source with integrity checks per file
- Stage in your bucket — your data never leaves your control
- Re-map references and load with retries on the target
The S3 bucket is yours. You control access, retention, and cost. We never touch your data directly — Relay just orchestrates the movement.
The audit trail is the product
"Did everything make it?" should be answerable with a report, not a shrug. Every file gets a row: source ID, target ID, checksum, status. If one fails, you see exactly which — and re-run only that one.
A migration you can't audit isn't finished. It's just untested.
Point-and-click mapping on top means an admin runs it, not a script nobody else understands. Six years of files over a weekend, zero lost — because the boring parts were designed in.
This is exactly what Relay delivers: visual field mapping, S3 staging, and a complete per-file audit log — installed from AppExchange in clicks, no custom code required.
Frequently Asked Questions
How do you migrate files between Salesforce orgs?
Migrating files requires three steps: extract from the source org with per-file integrity checks, stage in AWS S3 (your own bucket), then re-map ContentDocumentLink references and load into the target. Direct org-to-org transfer fails at volume because you fight both orgs' API limits simultaneously. Relay automates this with visual field mapping, S3 staging, and a per-file audit log.
What is ContentVersion in Salesforce and how does it affect file migration?
ContentVersion is the Salesforce object that stores the actual file content. When migrating, you must move both the ContentVersion records (binary data) and ContentDocumentLink records (which connect files to their parent records like Accounts or Opportunities). Missing either half breaks the file-record relationship in the target org — leaving records with no attached files.
Why use AWS S3 as a staging layer for Salesforce file migration?
S3 staging decouples the extract phase from the load phase so you never fight both orgs' API limits simultaneously. You pull files from source once, verify checksums, then load into the target at whatever pace it can handle — with retries on failures. The bucket stays in your own AWS account, so your data never leaves your control.
Planning a Salesforce org migration?
We'll show you how Relay handles your specific object and file structure in a 30-minute demo.
Request a Relay demo →