What you can export from Salesforce Commerce Cloud today
Most of the store data in Salesforce B2C Commerce leaves Business Manager as XML files defined by Salesforce's schema files, and coupon codes export as CSV. Orders can be exported from Business Manager under Merchant Tools, Ordering, Import and Export, where the platform builds the XML file automatically. Site import and export moves site-specific configuration and settings from one instance to another. Those documented paths are the starting point for a renewal, a pricing change or a data residency requirement, but they do not cover everything. The rest of this section sets out the gaps you should plan for before you assume a full extraction is available. The first gap is file size. Salesforce's documentation states that B2C Commerce limits export file uploads to 500 MB, and that multiple site exports or exports with very large images can lead to data overage charges. Confirm the current limit and overage terms with your Salesforce account team, then check your largest sites and image libraries against it. Plan for several export runs rather than one, and record which site, catalog and date range each file covers so the files can be reconciled later.
The second gap is scope. The XML formats are defined by schema files that you should obtain from your own instance, and they describe what the platform stores in that version, not how your custom cartridge code, custom objects or third-party integrations store their data. Ask your Salesforce partner or developer to inventory custom attributes, custom objects and any data held in external systems, because those rarely appear in a standard export. Because the B2C Commerce tooling is documented by Salesforce, check the Salesforce Trailhead module on configuring B2C Commerce import and export before you design the extraction, and treat any gap you find as work to scope, not a fact to assume away.
Which data types export, in which format, and with which limits
This table lists the export paths Salesforce documents for B2C Commerce, the format each one produces and the limits that apply. Read each row as a question: what data, which file type, and what constraint will affect your export plan. The main takeaway is that the 500 MB upload limit and the cost of multiple site exports should shape how you schedule and split your extracts.
| Data type | Export path and format | Limit or constraint | What to confirm |
|---|---|---|---|
| Catalog and other site data | XML files built on the B2C Commerce schema files | Subject to the 500 MB export upload limit | Confirm the full object list against the schema files in your instance version |
| Coupon codes | CSV file | Subject to the 500 MB export upload limit | Confirm which promotions and coupon fields your export includes |
| Orders | XML generated automatically by Business Manager under Merchant Tools, Ordering, Import and Export | Subject to the 500 MB export upload limit | Confirm the order date range and status filters you need before exporting |
| Site-specific configuration | Site import and export package moving settings between instances | Multiple site exports can add to upload volume and overage charges | Confirm which settings the package covers and which must be rebuilt manually |
| Images and media | Carried within exports when included in the site package | Very large images can push an export past the 500 MB limit and lead to overage charges | Ask Salesforce how image size counts toward the limit and plan a separate media copy |
| Multi-site estates | One export per site or a combined package, depending on your process | Several site exports can trigger data overage charges | Compare the cost of combined and separate exports before scheduling runs |
| Scripted extraction | Automated runs with sfcc-ci against Business Manager endpoints | Same 500 MB upload limit applies to scripted output | Confirm your sfcc-ci version and the commands your instance supports |
What does not export and how teams work around the gaps
The documented export paths cover schema-defined XML, coupon codes and site configuration, but they do not promise a complete copy of everything on a storefront. The cards below cover the gaps teams most often hit, the 500 MB limit that forces split exports, and the documented tools for working around each one. Confirm every gap against your own instance and contract before you plan around it.
Content outside the schema files
Content assets, page layouts, slots and storefront content are often managed outside the XML schemas that define catalog, customer and order exports. Some of this content may only be reachable through the storefront itself or through site import and export. Ask Salesforce for the complete list of object types your instance uses and compare it with the schema files your team exports. Treat anything missing from that comparison as a gap until you have confirmed otherwise.
Splitting exports under the upload limit
B2C Commerce limits export file uploads to 500 MB, and multiple site exports or exports with very large images can exceed it. Split large exports by site, by catalog or by date range, and run each part as its own job so each file stays under the limit. Check the file size of every part before upload, since a failed upload can leave a partial dataset that looks complete. Ask Salesforce how overage is billed before you run large exports.
Scripting pulls with sfcc-ci
The sfcc-ci command line tool can automate job runs, data transfers and site operations from a script rather than the Business Manager screens. A scripted pull gives you a repeatable, logged copy you can rerun for delta extracts before cutover. Keep credentials in a secrets manager, not in the script file, and record which job IDs and export options each run used. Confirm which operations your account role permits before you build the pipeline.
Coupon codes and promotion rules
Coupon codes export to CSV, while the promotion logic that applies them is part of the XML schema and may not carry over in full. Export coupon codes separately, then check redemption counts, expiry dates and any customer-specific restrictions against a sample order. Expect to rebuild the discount rules in the target platform's promotion engine, since a code list alone does not carry the rule behavior. Confirm the export covers every coupon type your merchandising team uses.
Historical data beyond exported windows
Order and customer exports cover what your chosen query window and export options include, so older history may need a separate pull. Decide how far back order history must go for returns, tax and finance, then confirm that the export options reach that date. Customer records tied to orders may export separately from order history, so reconcile the two counts before you retire the source instance. Ask your Salesforce contact which retention settings apply to your instance.
Contract and instance confirmation
Each gap depends on your edition, your enabled features and your Salesforce contract, and the supplied facts do not list every object type. Build an inventory of every object your storefront reads, writes or displays, then mark each one as exported, scripted, split, or needing a Salesforce answer. Record who confirmed each mark and when. Review the inventory with the business owners of content, promotions and customer service before you sign off the export plan.
The sequence for a complete export and how to verify it
This sequence moves catalog, site, order and coupon data out of Salesforce B2C Commerce in an order that keeps each file traceable to the instance it came from. Each step closes with a check, so the final dry-run load shows whether the export is complete before the contract ends.
Inventory sites, data objects and volumes
Before exporting anything, list every site, catalog, price book, customer group, promotion and order range in Business Manager, and record the record count for each object as the baseline. Assign an owner for each object, usually a merchandiser for catalog data and an operations lead for orders. The step is done when the inventory sheet shows a count per object per site and every owner has signed off on scope, so no data set is discovered missing during cutover.
Run Business Manager data exports
Run the XML exports for catalogs, price books, customers and other objects from Business Manager, using the schema files as the reference for each file's structure. Store each file under a naming convention that includes the instance name, object type and export date, and keep the original files unmodified. Confirm the run completed by checking the export log for each job, then compare each file's record count with the baseline from the inventory step.
Export site configuration with site import and export
Run site import and export to capture site-specific configuration and settings, which the XML object exports do not cover. Record which settings were included and keep the archive alongside the object files so the configuration can be reviewed with the storefront team. The check is a manual review of the settings list against a checklist of domains, locales, currencies and payment and shipping configuration, with each gap logged as an open item.
Split files that approach the 500 MB limit
Salesforce's Trailhead material states that B2C Commerce limits export file uploads to 500 MB, and that multiple site exports or very large images can lead to data overage charges. Check the size of each archive before upload, and split large exports by object type or site so each part stays under the limit. Confirm the split by summing the record counts of all parts and comparing the total with the baseline, since a split that drops or duplicates records is harder to detect later.
Export orders and their history
Export orders from Business Manager under Merchant Tools, Ordering, Import and Export, which builds the XML file automatically. Agree the date range and order statuses with finance and customer service first, because open orders, refunds and returns need different handling in the target. Verify by comparing the order count and total order value for the range against the figures in the commerce reports, and by spot-checking a sample of orders for line items, payments and shipping addresses.
Export coupon codes as CSV
Coupon codes export to CSV rather than XML, so they need a separate check. Export them from the same instance and record the code count and the status of each code, including redemption counts and expiry dates. Verify by reconciling the redemption totals with the order export, because a code that shows redemptions in orders but is missing from the coupon file will break promotion rebuilds in the target platform.
Script repeatable pulls with sfcc-ci
Wrap the exports in scripts using sfcc-ci so the same pulls can run again for delta exports and for the final cutover. Store the scripts in version control, pin the sfcc-ci version used, and record the instance and parameters in each run's log. Confirm the script works by running it twice against the same instance and checking that the file hashes and record counts match, which shows the process is deterministic before it is needed for cutover.
Record checksums and run a dry-run load
Generate a checksum for every exported file and keep the manifest with the record counts and instance details. Load the full set into a test environment on the target platform, then compare loaded record counts, totals and sample records with the manifest. The sequence is complete when the dry run reconciles on every object and the gaps are either fixed or accepted in writing. Schedule the final dry run before the Salesforce contract end date, and ask Salesforce and the target vendor to confirm any data retention or export limits in writing.
Scripting repeatable exports with sfcc-ci
Scripting the export is what turns a one-off data pull into a process you can repeat. A scripted run lets the team refresh catalogs, customers and orders for a delta sync close to go-live, and rehearse the full extract against a parallel test environment before cutover, so each dry run is compared with the last rather than rebuilt by hand. The same run also gives auditors and the project team a record of what was taken, when, and from which instance. The Salesforce export files still follow the XML schemas and the 500 MB upload limit described earlier, so the script must handle both the format and the size of each output.
A scripted run needs three things before it starts: credentials, instance access and a storage location. Credentials should belong to a dedicated integration user with only the Business Manager permissions needed for import and export, so that the job can be revoked without touching people's accounts. Confirm with your Salesforce administrator which instances the user can reach, including sandboxes, and whether the account is covered by your identity and multi-factor policy. The storage location should be a bucket or file share inside your own cloud account or data center, with encryption at rest, access logging and a retention period agreed with your data protection owner, because the export contains customer personal data and order history.
The exact sfcc-ci commands, their option names and the authentication method it expects should be checked against the current tool documentation before you write any automation around them. Do not rely on examples copied from older blog posts or from this page. Ask your engineers to run the tool against a sandbox, record the exact version used, and keep the working commands in version control with the rest of the migration code. Also confirm how the tool handles failed downloads, partial files and job status, since a silent failure in a nightly delta run is harder to detect than a failed manual export.
What to plan before the Salesforce renewal or termination
The export itself is the easy part to start and the hard part to finish. These cards cover the decisions that have to be settled before the contract ends, because the 500 MB upload limit, the timing of the last order and the custody of the exported files all shape how much work the cutover takes.
Confirm data-return terms in writing
Ask Salesforce, in writing, what data you can take at termination, in which formats and within what window. Business Manager exports are XML built on Salesforce's schemas, with coupon codes as CSV, so your contract should name those formats rather than leave them to a support ticket. Check whether any export is charged, because Salesforce notes that multiple site exports or very large images can lead to data overage charges.
Set a freeze and cutover date
Pick a catalog and order freeze date, and a later cutover date when the new store goes live. Between those dates, merchandising changes, price book edits and promotion updates should be held or logged so the final export matches what customers see. Agree the date with finance and fulfillment, since a freeze that is too early leaves stale prices and a cutover that is too late extends the overlap.
Book storage and transfer space
Estimate the size of each export set before you run it, including site, catalog, price book, customer and order files, and split large sets so each stays under the 500 MB upload limit. Plan where the files will sit during transformation, and confirm your staging storage and transfer bandwidth can hold several full exports at once. Ask your hosting or implementation partner to quote this work against the written scope.
Plan parallel running for orders
Keep Commerce Cloud taking orders until the new platform has its own checkout, payment and fulfillment connections tested. Orders placed during the overlap must be exported and imported without duplicates or gaps, so define one source of truth for each order and a reconciliation step on the cutover day. Confirm that payment gateways and order management integrations can point at both systems during the transition.
Agree who holds the exported copies
Decide who owns the exported XML, CSV and site configuration files, where they are stored and who can access them after the contract ends. Customer and order exports contain personal data, so the holder, retention period and deletion method should be written into your data processing terms and internal records. Name one accountable owner inside your organization and keep a checksummed master copy outside any vendor system.
Questions teams ask before exporting their Commerce Cloud data
How much effort does a full Commerce Cloud data export take?
The effort depends on how much data sits in each export and how many exports you need. Salesforce Trailhead states that B2C Commerce limits export file uploads to 500 MB, so a large estate can require several exports, and multiple site exports or very large images can push you toward data overage charges. The main drivers are object volume (products, variants, customers, orders), image size, the number of sites and price books, and how many separate export files you must split the work into. Ask for an estimate based on a sample export from your own instance, not a generic figure.
Can an internal team export Commerce Cloud data without outside help?
Often yes for a small catalog, and the export tooling itself is built into Business Manager. Business Manager produces XML files built on Salesforce's schema files, and coupon codes export as CSV. Teams with a stable, well-documented estate and an engineer comfortable with XML and scripting can usually run the core exports. Outside help becomes more useful when the estate has many sites, custom attributes, large media libraries, or when the export must be repeated, validated and scheduled reliably. The decision turns on who owns the schema knowledge and how much time the export work takes away from current operations.
What does the export work need from our team?
Plan for four inputs before the work starts:
- Business Manager access with permission to run import and export jobs under Merchant Tools, Ordering, Import and Export
- Someone who knows the site structure, price books, custom attributes and which data is live versus legacy
- A test or sandbox instance where exports can be run and checked before any production use
- Storage and a secure transfer path for the export files, since they contain customer and order data
Confirm with Salesforce how your contract and instance configuration affect export limits and job permissions.
How long will the export take to complete?
It depends on your data volume, and it should be estimated from your own instance rather than taken from a general rule. Estimate the number of products, variants, customers, orders and media files, then run a representative export to measure how long a job takes and how large its output is. Include time for splitting files to stay under the 500 MB upload limit, validating the XML against the schema, and repeating runs when data changes. Ask any vendor or partner for a timeline built on that measured sample and a written scope.
Are exports enough to rebuild our store on another platform?
No. Exports move data such as catalog, customers, orders and site-specific configuration, but they do not carry over cartridge logic, storefront code, custom checkout behavior or integrations with order management, CRM and payment systems. Those need separate design and build work on the target platform. Treat the export as the data migration step only, and scope the rewrite of business logic, the storefront and each integration as its own line items in your plan.
How does a quote for export work follow from a written scope?
DeployOpen does not publish a price list. Most engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that written scope. A useful scope lists the sites and data types to export, the number of exports expected, the image handling approach, the validation steps, the test instance to use, and the handover documentation. Ask any provider to state which items are one-time work and which recur, such as repeat exports for a cutover or ongoing support retainers.
What should we check in the exported files before using them?
Check that every file validates against the schema Salesforce provides, that record counts match what Business Manager reports, and that a sample of products, customers and orders reconciles with the live instance. Confirm that coupon codes from the CSV map to the promotions in the target platform, and that customer and order files are handled under your data protection rules. Keep an audit record of each export run, its date and its checksum, so you can show what was moved and when.
How to verify the export is complete and usable
Treat the export as unproven until you have compared it against the live Salesforce B2C Commerce instance. A file that uploads without error only shows that the transfer worked, not that every catalog, customer, order and coupon record made it across. Start by recording record counts for each object type you exported, including products, categories, customers, orders, price books and coupon codes, and compare those counts with what Business Manager reports for the same instance on the same date. Export at a fixed point in time, or freeze order placement during the run, so that the counts are comparable. Any difference should be explained before you move on, because a gap found now is far cheaper to fix than one found after cutover.
Next, check the files themselves. Confirm that every XML file parses against the schema files Salesforce publishes for B2C Commerce, and that coupon codes sit in their CSV file with the expected header row and column count. Keep checksums for each file and store them with the export archive so that later copies can be verified. Watch the 500 MB upload limit closely: a file that was truncated or split during transfer can look valid at a glance. Sample records by hand as well. Pick a set of orders across different statuses, a few customers with addresses and saved payment references, and products with variations, then open the same records in Business Manager and check totals, line items, statuses and dates. Ask your team to document which fields they checked, because auditors and migration partners will ask.
Finally, run a test load into a non-production instance of your target platform. Load failures, skipped rows and mismatched references show whether the export carries enough structure for the target to use, and that is a different question from whether the export is complete. The target format is not yet chosen for this page. Mapping decisions, such as how sites and price books become websites, channels or store views, belong in the sibling migration guides for Magento Open Source and Saleor, which are also linked from the hub. Confirm with your platform team which environment, data volume and reconciliation report the test load must produce before you sign off.
How DeployOpen scopes and delivers a Commerce Cloud data exit
DeployOpen plans and delivers the data exit from Salesforce B2C Commerce as a fixed-scope engagement inside your own infrastructure. We start from the XML exports, CSV coupon files and site export packages your team already produces, and agree in writing what is extracted, transformed, tested and handed over before work begins.
How we scope
- Inventory every site, catalog, price book, customer and order export your Business Manager instances produce today.
- Confirm which exports run within the 500 MB upload limit and which need to be split or staged.
- Agree in writing which schemas, coupon CSV files and order records are in scope, and which are excluded.
How we build
- Script repeatable export runs with sfcc-ci so extraction does not depend on manual Business Manager clicks.
- Map XML export elements to the target platform's data model and document each field transformation.
- Test imported samples against source record counts, and check order statuses, customer records and coupon redemptions.
How we hand over
- Deliver the export scripts, transformation rules, reconciliation reports and a runbook in your repositories.
- Document where each export archive is stored, retained and encrypted within your own environment.
- Walk your engineering and operations teams through a dry run before the source instance is retired.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Ask any provider to confirm, in writing, who owns the export scripts, archives and access credentials.
