There are plenty of reasons to move files out of Salesforce: storage costs, compliance requirements, or simply consolidating where your organization keeps its content.
Strangely enough, there are also good reasons to go the other way, moving files from a legacy CRM or another business system into Salesforce during a CRM migration, system consolidation, or integration project.
Either direction is doable without scripting, including the hard part of keeping files linked to the right records, avoiding duplicates, and preserving the metadata.
Want to migrate Salesforce files to SharePoint without coding?
Discover how Document Extractor built for the Salesforce platform can make migrations smooth
#1 Know What You Are Moving
Before the actual move, you need to run a quick discovery phase on your current org footprint.
- Run a Storage Report: Go to Setup > Data > Storage Usage to capture the exact raw volume of your File Storage vs. Data Storage.
- Query the Schema: Run a quick SOQL query or use an API tool to get a count of rows in Attachment, Document, and ContentVersion.
- Identify Large Files: Isolate your outliers. Will you be moving a lot of large files? Define a threshold (e.g. 25MB) and filter for files greater than that threshold, as these will dictate your batch sizes and network throughput limits later.
Keep in mind that if you have an older Salesforce org, documents may be spread across Classic-era storage and modern Lightning storage.
Classic (legacy):
- Attachments: files attached directly to records in the old model
- Notes: plain-text notes on records
- Document Folders: the old Documents tab
Lightning (modern):
- Files (ContentDocument / ContentVersion): the current standard
- Enhanced Notes: the richer note format introduced with Lightning
- Libraries (Salesforce CRM Content): shared file repositories
The real challenge of a Salesforce file migration isn’t moving the raw binary blobs (the PDFs, images, or logs); it's preserving the relational context.
In the Classic model, an Attachment is a simple child of a parent record. In Lightning, ContentVersion holds the actual file data, which rolls up to a ContentDocument, which is then mapped to records using a junction object called ContentDocumentLink.
If you are moving files out of Salesforce, you have to extract these relationships so your target system (like SharePoint, Azure Blob, or an AWS S3 bucket) knows which file belongs to which account or case. If you are moving files in, you have to map your legacy files to this modern, multi-tiered Lightning architecture. Doing this without writing custom Apex batches or Python scripts requires a tool that natively understands these underlying API relationships.
#2 Determine your Source and Target
If SharePoint Is Your Target: Document Extractor
Document Extractor is purpose-built for moving Salesforce files to and from SharePoint Online or on-premises.
It handles all the hard work. Document Extractor monitors documents related to Salesforce Accounts, Contacts, Leads, Opportunities, Quotes, Contracts, Orders, Assets, Email Messages, and Custom Objects, and creates the appropriate folder structure in SharePoint. It handles all the necessary relationships, edge cases, and linking.
Your users do not notice a thing. After a file moves to SharePoint, a link is left in its place inside Salesforce. Behind the scenes, some files may already live in SharePoint while others are still stored in Salesforce, but the users’ Salesforce experience remains consistent. That means you can migrate in phases, validate as you go, and avoid a risky big-bang file cutover.
Define a start date. If you do not want to migrate everything at once, you can specify a date and only transfer files created after that point, which is useful for large orgs that want to phase the migration.
Metadata. Standard metadata file attributes, such as Created By, Owner, Description, Version, and Modified By, are mapped directly to SharePoint, alongside any custom fields defined on the ContentVersion object. This ensures you maintain complete file history, compliance, and user context even when files leave the Salesforce ecosystem. Beyond file attributes, Document Extractor maps parent record fields (e.g., Account Name) to the corresponding SharePoint folder hierarchy.
Full Classic and Lightning coverage. Attachments, Notes, Document Folders, Files, Enhanced Notes, and Libraries are all supported. Nothing gets left behind.
Supported Salesforce editions: Professional, Enterprise, Unlimited, and Developer, in both Classic and Lightning Experience. SharePoint versions supported include 2013, 2016, 2019, and SharePoint Online / Office 365.
There is a free 15-day SaaS trial, no credit card required, which is enough time to run a proper proof of concept. If you want to run your trial self-hosted, or if you need more info, there is a simple form you can use to reach out.
If Your Target Is Something Other Than SharePoint: Connect Bridge
Not every file migration starts or ends with SharePoint. Your files may have a legacy CRM, an on-premises file store, a proprietary document management system, or something else entirely as the source or destination. That is where Connect Bridge comes in.
Connect Bridge is an integration platform that connects Salesforce to essentially any database or business application. You use standard SQL syntax to communicate with Connect Bridge and, under the hood, it translates SQL queries (SELECT, INSERT, UPDATE, DELETE) into the appropriate Salesforce API calls.
This is particularly useful for:
- Syncing Salesforce with on-premises databases or legacy systems
- Building custom integrations where the target is not SharePoint
- Organizations with specific compliance or data residency requirements
For the reverse direction, Connect Bridge handles any external source you need to pull files from into Salesforce, making it the right tool for inbound migrations too.
How Pricing Works
Pricing for Document Extractor is based on the number of Salesforce users, not on the volume or size of files being migrated. For Connect Bridge, pricing is based on the number of Salesforce users and the number of files being migrated.
This matters a lot if you are dealing with large file sets: tools that charge per GB or per file can produce surprisingly large bills once you get into the hundreds of gigabytes.
User-based pricing is predictable regardless of how much data you move and gives you the flexibility to migrate in phases and rerun jobs as needed without watching the meter.
Should You Still Consider the DIY Route?
If you are comfortable with Python, the REST API route (for example, pulling from ContentVersion and pushing to Microsoft Graph) is viable for a one-time migration of moderate size. But it carries real hidden costs: developer time, handling rate limits, deduplication logic on ContentDocumentLink, metadata preservation, and edge cases that only surface halfway through a large migration run.
For most organizations, using an out-of-the-box tool with a free trial, a proven track record, and user-based pricing is the lower-risk path. The scripting route makes sense when you have requirements that no standard tool can meet, or when you have a developer with genuine spare capacity to own it end-to-end.
- Migrating to SharePoint, or importing from SharePoint into Salesforce? Document Extractor offers a 15-day free trial, no credit card required.
- Any other source or target? Connect Bridge offers a free demo.
and is available to answer your questions through the contact form at any time.
About the Author

By Ana Neto, technical advisor at Connecting Software.
“I have been a software engineer since 1997, with a more recent love for writing and public speaking. Do you have any questions or comments about this article? I would love to have your feedback, leave a comment below!"
