Two different problems, two different tools. Here's when to use each — and when you need both.
The fastest way to know which tool you need. Most org-to-org projects use both — start here, then read the sections below for the details.
| File Migration | Data Migration | |
|---|---|---|
| Moves | Binary files and their parent-record links | Structured records and their field values |
| Salesforce objects involved | ContentVersion, ContentDocument, ContentDocumentLink, legacy Attachment | Standard and custom SObjects (Account, Contact, Opportunity, Case, custom objects) |
| Volume sweet spot | Thousands to millions of files; throughput limited by file size and storage API | Thousands to tens of millions of records; throughput limited by Bulk API 2.0 job slots |
| Primary API | ContentVersion multipart upload; Bulk API 2.0 for ContentDocumentLink rows; REST fallback | Bulk API 2.0 for volume; per-record REST API for small datasets and precision error reporting |
| Common use case | Attaching files in the target org after records already exist there | Aligning schemas and moving the parent records themselves |
| Order in an org consolidation | Second — after Data Migration has created the parent records | First — establishes the parent records that files will attach to |
Binary content and the relationships that make it visible on Salesforce record pages.
ContentDocument — the file container (069 ID prefix)ContentVersion — the actual binary file payload plus version metadata, owner, and custom fieldsContentDocumentLink — the sharing rows that link a file to its parent record (Account, Case, custom object, etc.)Attachment records (00P ID prefix), with optional upgrade to ContentVersion in the target orgIf your project is "the records are already in the target org, we just need the files," File Migration is what you want. Read the Salesforce File Migration product page →
Structured records, the schema they live in, and the relationships between them.
__c SObject)If your project is "we need to align schemas and move the records themselves," Data Migration is what you want. Read the Salesforce Data Migration product page →
Org consolidations almost always require both tools — run in the right order.
For the file side end-to-end, see the Salesforce File Migration guide. For scoping a project before you start, see how to count Salesforce attachments and ContentDocuments.
Four common scenarios, four answers.
Two orgs becoming one, with records and files on both sides. You need both tools, run in order — Data Migration first, File Migration second.
Pick: BothAcquired company's Salesforce data needs to land in the acquirer's org. Schemas differ, records have attachments. Same answer as consolidation — Data first to align schemas and land parents, then Files.
Pick: BothPartial Copy or Full Copy sandbox refreshed the records but didn't bring files. Records already exist in the sandbox with matching IDs — you only need to copy files. File Migration alone handles this.
Pick: File MigrationNothing is moving between orgs. You just have too many old files in one org and want to offload them to S3 while keeping them discoverable from record pages. Neither migration tool — use Salesforce File Archiving instead.
Pick: File ArchivingData first. Files in Salesforce are attached to parent records via ContentDocumentLink (or, for legacy Attachments, the ParentId field). If the parent Account, Contact, Case, or custom object record doesn't exist in the target org yet, the file has nothing to attach to. Run Data Migration to land the parent records, verify they exist via External ID mapping, then run File Migration.
No — and that's by design. File Migration and Data Migration target different SObjects (ContentVersion / ContentDocumentLink / Attachment vs. Account / Contact / custom objects), use different API paths (binary upload via multipart vs. structured record insert), and have different concerns (file metadata and sharing vs. schema diff and dependency ordering). EKE Services offers them as two separate tools so each can specialize in its own domain.
Use File Migration alone when the parent records already exist in the target org and you only need to move attachments — for example, a sandbox refresh where records were copied but files weren't, or modernizing legacy Attachments to ContentVersions inside the same org. Use Data Migration alone when there are no files attached to the records you're moving, or when files will be handled separately by an archival or external storage strategy.
Data Migration creates the parent records that File Migration's ContentDocumentLinks need. The integration point is the External ID: Data Migration stamps an External ID on each migrated parent record, and File Migration uses that External ID to resolve the new parent's target-org ID when it creates ContentDocumentLink rows. As long as the External ID strategy is consistent across both runs, file-to-parent associations are preserved end-to-end.
Tell us what's in source and target — orgs, record volumes, file volumes, schema gaps, and timeline. We'll walk through which tool (or both) fits your project.