How to export your data from Salesforce before you leave
Salesforce documents two exit paths for customer data: the Data Export Service, run from Setup, and Data Loader, a separately installed client. Start here whatever brings you to this page, whether it is a renewal quote, an edition price change, a data residency requirement or a plan to leave a platform your teams have built around. The Data Export Service produces CSV files in a compressed archive and can run manually or on a schedule. Data Loader suits repeatable, scripted extraction through its graphical interface or command line. Neither path is a full copy of the org. Both are about records and, where you choose, files, and the documentation does not present them as a complete record of the configuration that defines how your business runs. Treat that configuration as a separate inventory task.
The Data Export Service has the tighter constraints, so plan around them first. Manual runs can happen once every 7 days or every 29 days depending on your edition, and automatic weekly exports are limited to Enterprise, Performance and Unlimited editions. Confirm your edition in your contract and in Setup before you set a date. Each run can include images, documents and attachments, which you should decide on in advance because files add the most volume. The Trailhead guidance recommends the Include all data option for complete backups. Salesforce deletes the zip archives 48 hours after the notification email is sent, so download each file, verify it, and move it to controlled storage within that window. Build the export into your exit calendar with that deadline in mind.
Data Loader is the better fit for exports you need to repeat, such as monthly extracts during a parallel run or a final cutover pull. Because it is a client you install and configure, check with your Salesforce administrator that the user has the required API and object permissions before you rely on it. Use the export results to build a dated inventory of custom objects, fields, reports, flows, integrations and attachments, and note which of these your target platform must replace. Then run a test export and load it into a staging instance, so you learn about field mismatches and missing files before the renewal date. Keep the final archive in access-controlled storage with a retention period set by your legal and compliance teams.
Which Salesforce data each documented export method covers
This table compares the two documented Salesforce exit routes by data coverage, format, cadence and optional attachments. Read it to see which method fits a one-time archive and which fits a repeatable extract for a migration. The main takeaway is that the Data Export Service suits a periodic full backup, while Data Loader suits scripted, object-by-object extracts you can rerun.
| Question | Data Export Service | Data Loader |
|---|---|---|
| How it runs | Started from Setup in the browser | Separately installed client with a graphical interface or command line |
| Output format | CSV files in a zip archive | CSV files written to a location you choose on your device |
| Cadence by edition | Weekly in Enterprise, Performance and Unlimited; every 29 days in Professional and Developer | Runs whenever you start it, limited only by your own schedule and API access |
| Manual run frequency | Manual runs available every 7 or 29 days depending on edition | Unlimited manual runs, subject to your org's API usage |
| Scheduled automation | Weekly or monthly schedule, weekly limited to Enterprise, Performance and Unlimited | Command-line batch jobs can be scheduled with your own tooling |
| Images, documents and attachments | Optional inclusion in the run | Must be exported as separate objects or files; confirm the method for your object set |
| Repeatable scripted exports | Not designed for scripting | Suited to automation and integrations, per Salesforce's description |
| Download window | Zip files deleted 48 hours after the notification email | Files remain wherever you save them; retention is your responsibility |
What the documented export paths leave out and how to cover the gap
Neither documented exit gives you a complete copy of how your Salesforce org works. The Data Export Service and Data Loader move record data, but automation, page layouts and reporting logic stay behind. Each card below names one gap, the risk it creates at cutover, and a workaround to confirm in your own org before you move.
Files expire 48 hours after notice
Data Export Service output is delivered as CSV files in zip archives that are deleted 48 hours after the notification email is sent. A export that finishes overnight can be gone before the migration team opens it. Treat the download as a time-boxed step: schedule the run, record the notification time, download immediately, and copy the archive to storage you control with checksums. Confirm the current window in Salesforce Trailhead before each export.
Apex classes and triggers
Apex code is not exported as data. Triggers, classes and their test coverage live in the org metadata, so the export gives you no copy of the logic that sets fields, creates related records or blocks bad entries. Before cutover, export the code from a sandbox or use the metadata tooling your team already uses, then list each trigger's business purpose in a document. Expect the functional equivalent to be rebuilt in your new platform, not translated line by line.
Flows and process automation
Flows, approval processes and older automation are configuration, so the data exports do not capture the decision paths, field updates or notifications they trigger. A record can look correct in the CSV while the rule that produced it is undocumented. Inventory every active flow, record its entry criteria, actions and owners, and test each one against the target system in a parallel run. Confirm the active flow list in the org, since retired automation can still appear in older records.
Page layouts and record access
Page layouts, Lightning record pages, field-level security and sharing rules are not included in the record export. Sales users rely on these to see the right fields, and the sharing model decides who can see which accounts. Capture a screenshot or metadata copy of each layout used by a profile, and write down which roles can see which records. Rebuild these in the target system and check them with a sample of real user accounts before go-live.
Reports and dashboards
Reports, dashboards and their folder sharing are not exported as data, so the historical reporting that managers depend on disappears at cutover unless someone rebuilds it. Export the report definitions and filters, then record the figures each dashboard shows for a fixed date. Those totals become the acceptance test for the new reporting. Ask your team which reports feed forecasts, board packs or commission calculations, since those carry the most risk.
Confirm exclusions in your org
The documented exclusions can change, and your org may hold objects, files or integrations that a standard export handles differently. Before you rely on either export path, run a test export in a sandbox, compare object counts and attachment totals with the source, and check the output for every custom object. Keep the list of confirmed exclusions with the cutover plan so that auditors and owners can see what was moved and what was rebuilt.
The export sequence for a complete Salesforce copy
This sequence produces a full copy of your Salesforce org data, with files and attachments, plus repeatable object extracts you can rerun and check against the live org before you cut over or leave.
Confirm edition and export cadence
The org administrator checks the Salesforce edition in Setup before anything else, because the edition decides how often the Data Export Service can run. Trailhead notes that manual runs are possible every 7 days or every 29 days depending on edition, and that automatic weekly or monthly schedules are limited to Enterprise, Performance and Unlimited editions. Write down the edition, the date of the last successful export and the next allowed run so the team plans around a fixed window. The step is done when the administrator has a dated record of the edition and cadence.
Schedule a full export with all data
In Setup, the administrator opens the Data Export Service and selects the option to include all data, which Trailhead recommends for complete backups. Choose whether to include images, documents and attachments, since these are optional and are the items most often missed in a partial copy. Check the export page for the notification email address and confirm that a named person will receive it. The step is done when the export request appears as queued or running in the Setup list.
Enable the replace carriage returns option
Before the export runs, tick the option to replace carriage returns with spaces if the data will be reimported into another system. Multi-line text fields often contain line breaks that break CSV parsing during import, and this option removes them from the output. Note in the migration log that the option was used, because the exported text will differ from the original field values in those positions. The step is done when the export settings record shows the option enabled before the run starts.
Run Data Loader for repeatable object extracts
Install Data Loader as a separate client, then use its graphical interface or command line to extract the objects that matter most, such as accounts, contacts, opportunities and custom objects. Scripted runs produce the same file layout each time, which makes repeated test extracts and final cutover extracts comparable. Store the mapping files and command scripts under version control, with the Salesforce user and API access documented. The step is done when each object has a CSV file and the script can be rerun without edits.
Download the archive within 48 hours
When the notification email arrives, the administrator downloads the zip archive promptly, because Salesforce deletes Data Export Service files 48 hours after that email is sent. Store the archive in a restricted location on your own infrastructure, with checksum or hash values recorded at download. Unpack it in a separate working folder and do not edit the original files. The step is done when the archive is verified, stored, and a copy is confirmed readable.
Check record counts and attachments
Compare the row count of each CSV against the record counts reported in Salesforce reports or SOQL queries for the same objects and date range. Confirm that the number of attachment and document files matches the expected count from the org, and sample several files to check that they open. Record any gaps, such as objects Data Loader did not extract or files that did not export, and resolve them before relying on the copy. The step is done when a signed-off reconciliation sheet shows each object and file category as matched or explained.
Repeat the sequence before the next export
Before the next Data Export Service window opens, rerun the Data Loader scripts and compare their output with the previous extract to identify records that changed. Log the cadence, edition limits and any export failures so the next cutover does not depend on memory. Confirm the reconciliation sheet is current and stored with the archive. The step is done when the team can state which export is the latest verified copy and when the next one is due under the org's edition.
How to verify the export is complete and usable
Verify each export before anyone relies on it, starting with record counts per object. Compare the number of rows in every CSV file against counts from Salesforce itself, such as a report or a SOQL COUNT() query run through Data Loader's command line or a developer tool, taken at the same point in time as the export. Do the same for every standard and custom object you plan to move, including Accounts, Contacts, Opportunities, Tasks, Events, Cases and custom objects. Where counts differ, check whether records were created, deleted or changed between the export and the count, and record the explanation rather than assuming the export is at fault. Pay particular attention to the Data Export Service's "Include all data" option, since the Trailhead guidance recommends it for complete backups, and confirm that the files you received match the option you selected.
Next, sample relationships and the files that depend on them. Pick a set of Accounts and confirm that their Contacts and Opportunities appear in the expected CSV files with matching IDs, and check lookup fields such as AccountId and OwnerId for orphaned values. Count attachments and files separately from the data files, because the Data Export Service only includes images, documents and attachments when you choose that option, and Data Loader exports them only through its own steps. Compare the number of files against what your admins see in the org, and record any gaps. Also check for carriage returns in long text fields if you plan to reimport, since the Data Export Service can replace them with spaces, which changes the content.
Store the archive with checksums and a run log. Generate a SHA-256 hash for each zip archive or CSV file with a command such as sha256sum, store the hashes separately from the archive, and keep a log that records the run date, the export method, the edition, the user who ran it, the selected object list and the row counts. Keep the Data Export Service notification email, since the archive is deleted 48 hours after that email is sent, so copy the files to controlled storage within that window. Verification proves the copy exists and is intact. It does not prove that a target system can rebuild the business logic, such as Apex, flows, validation rules, sharing rules or approval processes, which requires a separate mapping exercise before cutover.
Data Export Service or Data Loader: choosing by team and situation
An administrator who needs a single, point-in-time copy of the org usually starts in Setup with the Data Export Service. It runs in the browser, needs no installed software and produces CSV files in zip archives. Your edition sets the cadence: the service can be run manually once every 7 days or every 29 days depending on edition, and weekly automation is limited to Enterprise, Performance and Unlimited editions. This path suits a snapshot taken before a renewal, a retirement or a cutover freeze, and its output is a set of files for reading and archiving.
- Run from Setup: Open the data export page in Setup, choose the export type and start the job.
- Include all data: Trailhead recommends the Include all data option for complete backups.
- Attachments are optional: Images, documents and attachments are included only when you select that option.
- Download window: The zip files are deleted 48 hours after the notification email is sent, so download and store them promptly.
- Edition limits: Confirm your edition's manual cadence and scheduling options before you plan the run date.
Check the edition, the run date and the download window before you schedule the snapshot, and store the archive where the team controls access.
A team that will run a new system alongside Salesforce for several weeks needs extracts it can repeat with the same field list each time. Data Loader is a separately installed client that runs through a graphical interface or from the command line, and Salesforce describes it as suited to automation and integrations. Scripted runs let the migration team refresh the same objects on a schedule, compare outputs between runs and keep a record of what was extracted and when. Setup involves installing the client on a controlled workstation or host and configuring the connection for the integration user who runs it.
- Fixed field lists: Define the objects and fields once so every run returns the same structure.
- Command line for scheduling: Command-line operation suits jobs run on a controlled host at set times.
- Refreshable copies: Repeat extracts to keep the target CRM current through the overlap period.
- Run logs as evidence: Keep logs and file checksums with each run so the team can show what was extracted and when.
- Scoped integration user: Give the account only the object and field access the extract requires.
Ask the Salesforce admin to confirm the user's permissions and the current Data Loader version before the first scripted run.
Files and attachments are the part of an org most often left behind. The Data Export Service can include images, documents and attachments in a run, but the team has to select that option, and the archive still follows the 48-hour deletion window. Records and files are separate concerns, so a contact list can move without its attached contracts and the reverse can happen too. Plan for file volume, folder structure and the link from each file to its parent record, because the target CRM needs both to restore context for the people who use those documents.
- Select the file option: Confirm that the export run includes images, documents and attachments before it starts.
- Track the parent link: Keep the record ID or external key that ties each file to its contact, account or opportunity.
- Size the archive: Estimate total file storage from the org's usage figures before scheduling the run.
- Verify the counts: Compare file counts in the archive with the source for each parent object.
- Plan target storage: Confirm where the target CRM keeps uploaded files, how large each file can be and who can open them.
Review the file count, the parent mapping and the download window with the business owners who depend on those documents.
Most migrations use both paths. The Data Export Service produces a complete, dated baseline that the team can archive and audit, while Data Loader handles the repeated extracts that feed a parallel run. The baseline records what existed at a point in time, and the scripted extracts show what changed afterward. A common sequence is a full Data Export Service snapshot first, then Data Loader for the objects that change most often, followed by reconciliation of the two sets before any cutover decision.
- Baseline first: Take a full export as the reference copy before any import into the new system.
- Scripted deltas: Use Data Loader for high-change objects, such as opportunities and tasks, on a set schedule.
- Reconciliation step: Compare record counts and key fields between the baseline and each scripted run.
- Separate retention: Store zip archives and script outputs in controlled locations with a defined retention period.
- Document the mapping: Record which export produced which target object so the cutover can be audited later.
Agree the baseline date, the delta schedule and the reconciliation checks in writing before the parallel run begins.
What to plan before the Salesforce contract renewal or termination
The export mechanics only matter once the exit timeline is fixed. These cards cover the decisions to settle before the end date, from the export schedule to the contract terms that govern how your data comes back.
Set the export cadence to the cutover date
The Data Export Service runs on a fixed rhythm, so the last full export must land after the final working day in Salesforce, not before it. Work backward from the planned cutover and schedule at least one run that captures the latest state, including records changed during parallel running. Check which cadence your edition allows, since manual and automatic options differ by edition. Confirm the final export date with the cutover plan before the renewal notice window closes.
Plan where archives are kept
Salesforce deletes Data Export Service zip archives 48 hours after the notification email, so every file must be downloaded and copied to storage you control within that window. Decide in advance where the CSV sets go, who may access them, how long they are retained and how they are encrypted. Retention should follow your own records policy and any legal hold obligations, not the timing of the Salesforce contract. Record checksums so you can prove later that an archive was not altered.
Document automations and integrations
Inventory every Flow, Apex trigger, scheduled job, approval process, connected app and middleware connection that reads or writes Salesforce data. Exports contain records, not logic, so anything that runs inside the org disappears at termination and must be rebuilt or retired. Note the owner, trigger, data touched and downstream system for each item. This list drives the rebuild scope for your target CRM and shows which external systems need a new data feed.
Keep users and API access until cutover
Data Loader and any integration user depend on active logins, API permissions and a valid profile, so removing access early can stop the final export. Keep a small set of named administrators and one scripted exporter account active until the last extract is verified. Rotate or document credentials once cutover is complete. Review which users hold the export permission, since that role decides who can pull full org data.
Confirm data return terms in the contract
Before termination, ask Salesforce in writing what it will return, in what format and within what period, and whether any fee applies. Check the master subscription agreement and order form for clauses on data deletion after termination, backup retention and certification of deletion. Clarify whether attachments, files and metadata are covered alongside standard records. Treat the answers as contract facts for your legal and procurement teams to confirm, not as assumptions.
Verify exports against a test restore
Running an export is not proof of a usable copy. Load a sample extract into a staging instance of your target CRM, compare record counts and key relationships against Salesforce, and check that multi-line text fields and attachments survived. Use the replace-carriage-returns option when files will be reimported, and document any field types that did not map cleanly. Repeat the check on the final extract before the Salesforce org is shut down.
Questions buyers ask before exporting Salesforce data
How much effort does a Salesforce data export take?
A one-off export is mostly administrator time, plus the time needed to check the files. The Data Export Service runs from Setup in the browser, so the export itself takes a few steps. Data Loader is a separately installed client, so someone must install it, configure access and run it. Effort rises with the number of objects, the volume of attachments and the number of checks the business wants afterward. The facts available to us do not price these export methods, so confirm what your Salesforce edition includes with Salesforce. For an outside partner, ask for a quote built on a written scope that lists objects, attachments and verification steps.
How long does a full Salesforce export take to plan?
Planning depends on the number of objects, the attachment volume and how often you can export. The Data Export Service can be run manually once every 7 days or every 29 days, depending on edition, so you cannot repeat a full run on demand. Archives are also deleted 48 hours after the notification email, so plan the download window in advance. A sensible plan includes a test export in a sandbox, a dry run of the reconciliation checks and a date for the production export. Review the Salesforce Trailhead module on data export methods before setting dates, and ask any partner for a written schedule tied to the agreed scope.
Can one Salesforce admin run the export alone?
A single administrator can run a standard Data Export Service export if they hold the required permissions and can download the archive within the 48-hour window. Other methods need more people:
- Data Loader exports need an integration user, API access and someone who can build and maintain the scripts.
- Checking record counts, relationships and attachments usually needs someone who understands the data model.
- Sign-off on whether the sales data is complete belongs to a business owner.
Confirm your admin's permissions in your own org before the export day. If the admin lacks Data Loader or API skills, budget for an engineer or an outside partner to cover that part.
What does the business and IT need to provide for an export?
The business needs named owners for accounts, opportunities and other sales records, plus someone to approve what counts as a complete export. IT needs a secure, access-controlled location for the archives, a retention rule and a way to delete copies when they are no longer needed. Export files contain customer and sales data, so decide who can download them and how they are transferred. IT also needs a staging environment to test imports and reconciliation before anything touches production. Put these responsibilities in the written scope so each party knows what it provides and when.
What drives the cost of an outside partner for a Salesforce export?
The main cost drivers are the scope and the complexity of the data:
- The number of standard and custom objects, and the number of fields on each.
- The volume of attachments, images and documents, and whether they must be linked back to records.
- Whether the export must be repeatable, for example as scripted Data Loader runs for a parallel period.
- The verification required, such as record counts per object, relationship checks and sampled field comparisons.
- Any mapping or cleanup needed before the data goes into a target system.
DeployOpen works on fixed scopes agreed in writing before work starts, so ask for a quote that lists each of these items. A narrower export of standard objects costs less to plan and verify than a full export with custom objects and attachments.
Does a Salesforce Data Export Service run include attachments and files?
It can, but only when you select the option. The Data Export Service can optionally include images, documents and attachments in the run. It can also replace carriage returns with spaces, which makes the CSV files easier to reimport. Salesforce's Trailhead guidance recommends the Include all data setting for complete backups. Output arrives as CSV files inside zip archives, so attachments need a separate mapping step to link them back to their parent records. Confirm the options for your edition and org before you start, and check the archive contents against an expected file list.
What does a Salesforce export leave out, and how do you check it?
The export contains only what the selected run includes, so the first check is to compare the archive against your object list. Do not assume a run is complete because it finished. Useful checks include record counts for each object against Salesforce reports, a sample of parent and child records to confirm relationships, field-level comparisons on key fields such as amount, stage and owner, and a count of attachments against the source. Record the results and ask the business owner to sign them off. Ask Salesforce or your partner to document any object or file type that a run does not cover.
How DeployOpen scopes and delivers a Salesforce data exit
DeployOpen treats a Salesforce data export as a planned engagement, not a one-off download. We agree the scope in writing, build repeatable extraction and checks inside your own infrastructure, and hand over documented evidence your team can rerun. Engagements are fixed-scope, and the work starts only after scope, deliverables and timelines are agreed.
How we scope
- Inventory which objects, custom objects, attachments and files must leave Salesforce, and which can be retired.
- Confirm your Salesforce edition, since it sets the Data Export Service cadence and whether weekly automation is available.
- Record the target platform, storage location and retention period in the written scope before any export runs.
How we build
- Configure Data Loader runs for scheduled, scripted extracts, with command line jobs kept under version control in your environment.
- Set up Data Export Service runs with the attachment and file options your scope requires, and choose Include all data for full backups.
- Store each export in encrypted storage you control, and test that the files open and reimport cleanly on a staging copy.
How we hand over
- Deliver a runbook covering the 48-hour download window, the 7-day and 29-day cadence limits, and the steps to repeat each export.
- Provide reconciliation reports comparing record counts and key fields between Salesforce and the exported files.
- Document what the exports leave out, such as data outside the standard export scope, and the manual steps needed to capture it.
How we support
- Offer ongoing support, upgrades and periodic re-exports as a retainer, scoped separately from the initial exit.
- Re-run reconciliation before cutover and after any Salesforce configuration change that affects exported objects.
- Confirm with your Salesforce administrator and legal team which retention, deletion and contract obligations apply before deleting the source org.
