How do you export your data from commercetools before the contract ends?
The Merchant Center lets you export some commercetools resource types as CSV or JSON, Custom Objects export as JSON only, and anything the Merchant Center does not cover needs the HTTP API. If your contract is up for renewal, facing a pricing change, bound by a data residency requirement, or simply locking you in, that split decides how much of your data you can take out with a download and how much needs engineering time. Before you commit to a migration date, confirm the current export list in commercetools' documentation, because the supported resource types and formats can change between releases. Ask your account contact to confirm them in writing for your project.
Treat the export as a project with a plan, not a single download. Start with an inventory of every resource type your storefront, integrations and finance processes depend on, including products, categories, customers, prices, orders, inventory and Custom Objects. For each one, note whether the Merchant Center covers it, whether the file size limits apply if you plan to re-import the file, and how large your data set is. Order and inventory volumes often drive the approach, so ask commercetools to confirm any export limits that apply to your project's volume before you plan batches. Where a limit is lower than your data, you will need the HTTP API with paging.
Verification decides whether the export is finished. For each resource type, compare record counts between the export and the source through the HTTP API, then sample records and check that references such as product variants, tax categories and customer addresses still resolve. Reconcile order totals and open payments against your finance system for a fixed date range. Keep the commercetools project live until the target system has passed these checks, and confirm in writing what data remains available after the contract ends, how long it is retained, and whether the exit terms include export support.
Which commercetools data can you export, and in what format?
This table lists each commercetools resource type with its export route, file format and the limits you need to confirm before planning a migration. Where a limit is not in our researched sources, the cell tells you where to check the current value. Custom Objects and any field outside the Merchant Center exports will need HTTP API queries, so plan that work early.
| Resource type | Export method | File format | Limits to confirm |
|---|---|---|---|
| Products and product types | Merchant Center export or HTTP API query | CSV or JSON, per export type | Record caps and file size limits in commercetools docs |
| Categories | Merchant Center export or HTTP API query | Confirm supported format in the Merchant Center | Confirm hierarchy depth and export row limits with vendor |
| Customers | Merchant Center export or HTTP API query | CSV or JSON, per export type | Confirm whether password hashes are included and file size caps |
| Prices | Merchant Center export or HTTP API query | CSV or JSON, per export type | Confirm how standalone and channel prices appear in each export |
| Inventory | Merchant Center export or HTTP API query | Confirm supported format in the Merchant Center | Confirm export row limits and the size of files you can re-import |
| Orders | Merchant Center export or HTTP API query | CSV or JSON, per export type | Confirm order export limits and date range restrictions with vendor |
| Custom Objects | HTTP API query only | JSON only | Confirm pagination limits for large query results in API docs |
| Other custom fields and extensions | HTTP API query only | JSON from API responses | Confirm API rate limits and page sizes for bulk extraction |
What does not leave commercetools in a Merchant Center export, and how to work around it
A Merchant Center export covers the common resource types, but some data comes out in a limited form or not at all. Each card names one gap, the workaround that usually closes it, and the limit you must confirm in your own project before you plan the cutover.
Custom Objects export as JSON only
Custom Objects are available only as JSON, so a CSV-based workflow will miss them entirely. Plan to pull them through the HTTP API, page through the full result set, and write the records to files your target importer can read. Keep the container, key and version fields so references from products and orders still resolve. Confirm the page size and query parameters in the commercetools API reference before you script the pull.
Inventory export can truncate
The inventory export has a row limit that can cut off large stock sets, and a truncated file still opens normally, so the gap is easy to miss. Export in segments, such as by SKU range or channel, or read inventory entries through the HTTP API with paging. Then compare row counts against an API count for the same filter. Confirm the current row limit in the Merchant Center export documentation for your project.
Order export has a row cap
Order exports also have limits, and a store with several years of history will exceed them in one pass. Split the export into date windows with exact boundaries, such as one month at a time, so adjacent windows share no orders. Keep the order number and version fields in every file so you can detect duplicates when you merge. Confirm the order export limit and how the date filter behaves with commercetools support.
Files above the import limit
A file larger than the re-import size limit cannot go into the target platform as one file. Split products and customers into chunks by stable ID, repeat the header row in each chunk, and keep a manifest that lists row counts and checksums per chunk. Import in a fixed order so categories and product types exist before the products that reference them. Confirm the import size ceiling for your target platform before you choose a chunk size.
Fields outside export templates
Each export template includes a fixed set of fields for its resource type, and anything outside that set is not in the file. Typical candidates are custom field values, price tiers you did not map, and references to resources exported in another file. Compare a sample record field by field with the same record from the HTTP API before you assume the file is complete. Confirm each template's field list in the export documentation.
Reconcile counts before cutover
Completeness is something you verify, and the export does not guarantee it. For each resource type, record the API count, the row count in each file, and the count after import into the target system, then investigate any difference. Run the check on a full export taken close to cutover, because orders placed after the snapshot will change the totals. Keep the reports with your migration evidence so the team can explain any gap later.
What is the sequence for a complete export from commercetools?
The sequence turns commercetools data into a set of raw, timestamped files that you have checked against the source before any migration work starts. Each step ends with a verification so that gaps are found while the source project is still available.
Inventory the resource types in use
Before exporting anything, list every resource type your commercetools project uses: products and product types, categories, customers, prices, inventory, orders, carts, discounts, tax settings, stores and channels, and Custom Objects. Owners in commerce operations and the engineer who built the storefront should both sign off on this list, since integrations often store data the business team never sees. The output is a checklist with one row per resource type and a column for the export method you plan to use. You know the inventory is complete when the storefront and integration code have been searched for every API resource the application reads or writes.
Confirm current limits in vendor documentation
Read commercetools' current documentation for Merchant Center export formats, file size limits, and any stated restrictions on inventory or order exports, and record the date you checked. Limits change between releases, so do not rely on figures from older migration guides or forum posts. Confirm specifically which resource types can be exported as CSV, which as JSON, and which only through the HTTP API, including Custom Objects, which are JSON only. The output is a dated note of limits next to your inventory checklist. You know this step is done when every row in the checklist has a confirmed export method.
Run the Merchant Center exports
Using the Merchant Center, run exports for each resource type that supports it, and download the files without opening and resaving them in a spreadsheet, because spreadsheet applications can alter identifiers, dates and multi-line text. Where a single export exceeds the size you plan to re-import, split the work by time range or resource subset and note how each file was produced. Store the files exactly as delivered. You know this step is done when each file has been downloaded, its name recorded, and its row count noted for the next verification.
Query the HTTP API for remaining data
For resources the Merchant Center does not export in full, such as Custom Objects and any fields outside the standard export, query the commercetools HTTP API with paginated requests. Use the project's own API client credentials with the narrowest scope that reads the data, and log each request URL, query and response timestamp. Write each response to disk as received. You know this step is done when the total count returned by the API for each query matches the number of records you saved, including every page.
Store raw files unchanged with timestamps
Place every file and API response in a single archive folder with a naming convention that includes the resource type, the export method, and the UTC time it was taken. Compute and record a checksum for each file, and keep a manifest listing the file name, checksum, record count and source. Do not transform, rename fields or deduplicate in this archive; any transformation belongs in a separate working copy. You know this step is done when the manifest lists every file and a second person can recompute the checksums and get the same values.
Verify each set before the next step
Compare each resource's record count in the saved files with the total shown in the commercetools Merchant Center or returned by an API count query taken at the same time. Spot-check a sample of records by identifier, confirming that prices, currencies, custom fields and status values match the live project. Record any difference and resolve it before exporting the next resource type, since a missing page or a truncated file is far easier to find now. You know this step is done when every resource type has matching counts and a signed-off spot-check log.
Repeat the export before cutover
Because orders and inventory keep changing while the store trades, run the full sequence again close to the cutover date and compare the new manifest with the earlier one. Record the difference in order counts and inventory quantities, and decide which delta export will close the gap. Keep both archives until the new platform has been verified in a parallel run. You know this step is done when the delta between the two exports is fully explained and documented in the migration log.
How do you verify that an export is complete?
A successful file download does not prove that an export is complete. Before you treat any commercetools export as a migration source, reconcile record counts for each resource type against counts you can pull independently from the Merchant Center and from the HTTP API. Products, categories, customers, prices and orders should each have a matching total in the file and in the live system, with the same filters applied on both sides. Where the counts differ, record the gap and the filter that explains it, such as a status or store scope, before moving on. Do not assume the export tool applied every filter you expected, and confirm the scope with commercetools support or your own project settings if a count is unexpected.
Keep a manifest for every file you produce. For each file, record the resource type, the export date and time, the row or object count, the file size and a checksum such as SHA-256, then store the manifest with the files so the import team works from the same reference. Checksums show that a file has not changed since it was written, but they cannot show that the source was complete, so they complement the count reconciliation rather than replace it. Note the size of each file against any import limit your target platform enforces, and confirm those limits with the vendor of that platform.
Sample records to compare field values across the export and the source. Pick a fixed set of products and orders, including edge cases such as variants, multiple currencies, channel-specific prices and custom fields, then check that key, sku, price amounts, currency codes and custom field values match. Repeat the verification after any change in the live store during the export window, because new orders, price edits or catalog updates will shift the counts. Re-running the reconciliation and manifest at the final cutover is the step most teams skip, and it is the one that catches changes made after the first export.
Should you use the Merchant Center or the HTTP API for each data type?
A merchandiser or store administrator can run most one-off exports from the Merchant Center without writing code. This path suits small catalogs, a single category, or a snapshot taken for review. Exports follow the resource type, so products, categories and customers are separate jobs, and each produces its own file.
- Who runs it: a merchandiser or administrator with Merchant Center access to the relevant project.
- Skills needed: spreadsheet editing and basic JSON reading. No API knowledge is required.
- Format choice: use CSV for spreadsheet review. Use JSON when nested structures such as variants and attributes must stay intact.
- Limits to confirm: the file size and record limits that apply to each resource type, and whether your inventory and order volume fits within the export limits.
- Access to confirm: which roles can export customer and order data, since personal data should be limited to people who need it.
Before you treat any file as complete, compare its record count with the count shown in the Merchant Center for the same resource.
When a catalog is large, variants and references are deeply nested, or the extraction must be repeated, scripted calls to the HTTP API give you control over paging and a record of exactly what was pulled. This path needs an engineer who can handle authentication, pagination, retries and rate limits, and who can keep raw responses for later checks.
- Who runs it: a backend or integration engineer, ideally working with the person who owns your product data model.
- Skills needed: REST calls, API client authentication, cursor-based paging, JSON handling and retry logic.
- Scope of credentials: create an API client with only the read permissions the job needs, and record who holds its secret.
- Limits to confirm: the maximum page size, request rate limits and access token lifetime for your project and region, checked against the current commercetools documentation.
- Repeatability: store raw responses with timestamps so you can rerun the extraction and compare results later.
Run a small test pull first and confirm that paging returns every record once, because a partial pull can look complete until counts are compared.
Custom Objects can only be exported as JSON, so they need a file-based workflow and an engineer who understands their structure. The usual method is to query each container, page through its keys and save every object with its container and key intact. Decide early which containers hold data your target platform needs, because the mapping work depends on that choice.
- Who runs it: a developer who knows the custom data model used by your storefront and integrations.
- Skills needed: JSON handling, schema analysis and query paging by container.
- Inventory first: list every container and key before extraction so that no data set is missed.
- Access to confirm: whether the API client can read every container, including containers owned by other teams.
- Mapping decisions: decide whether each container becomes a data model, metadata or a separate service table on the target platform.
Compare the object count from the API with an independent count from your own inventory, so you know the extraction covered every container.
Most migrations combine both paths. The Merchant Center handles files that people need to review by eye, such as categories and a sample of products. The HTTP API handles full, repeatable sets such as products, prices, customers and orders, followed by a reconciliation pass. Track both paths in one shared log so that every file has a known origin and a known date.
- Who runs it: a migration lead who assigns Merchant Center checks to merchandising staff and API jobs to engineers.
- Skills needed: spreadsheet review and scripting, plus a shared tracking sheet for run results.
- Division of work: use the Merchant Center for resources people must inspect, and the API for anything that must be complete and repeatable.
- Limits to confirm: which export limits affect each path, so that file splits and paginated pulls are planned before the run starts.
- Verification: compare record counts and checksums between the two paths for any resource type exported by both, before cutover.
Agree on one source of truth for each resource type before extraction begins, so a later correction does not leave two versions of the same data in circulation.
What to plan before the commercetools renewal or termination
Your contract terms set the window you have for extraction, so they come first. The cards below cover the terms to confirm, the access and credentials the export depends on, and the freeze plan for the live store. Confirm every term with commercetools in writing and do not assume standard terms apply to your agreement.
Notice period and end date
Find the notice period, the exact end date of the subscription and whether renewal happens automatically. Work backward from the end date to set your extraction, validation and cutover milestones. Ask commercetools whether the end date is the date access stops or the date data deletion begins, because those two dates often differ. Record the answer in writing before you plan the export sprint.
Retention and deletion after termination
Ask how long commercetools keeps your project data after the subscription ends, what triggers deletion and whether you can request a deletion certificate or written confirmation. Confirm whether backups are included in that deletion and on what timeline. Keep your own verified copies of the export under your retention policy, since the vendor's deletion terms will not cover your legal obligations for orders and customer records.
Access during the export window
Confirm which users, roles and API clients keep working after notice is given and after the end date. Ask whether read-only access to the Merchant Center remains available for a defined period so your team can check exports against the source. A short, written access window protects you if an export must be repeated or a gap is found late in the project.
API credentials and scopes for extraction
Create API clients with read scopes for each resource you need, such as products, categories, customers, orders, prices and custom objects. Scope them to the project, store the secrets in your vault and rotate them after the export. Confirm with commercetools that the scopes and rate limits in your plan support full extraction, and that API clients stay valid through the window you have agreed.
Freeze and change plan for the live store
Decide how catalog, price and order changes are handled while exports run. Agree a freeze window for product and price edits, or record every change made during the window so you can reapply it. Name the owner who approves exceptions. Without this plan, a delta export may miss updates made after the first snapshot, and reconciliation becomes guesswork.
Verification and sign-off ownership
Assign who signs off that each resource type is complete, such as record counts, reference integrity and sample checks against the live project. Set the acceptance criteria before extraction starts. Confirm in writing what commercetools will support if an export fails or returns partial data, and whether any vendor assistance is charged separately.
What does it cost and take to export data from commercetools?
What drives the effort of exporting data from commercetools?
The effort scales with how much data you hold, how many resource types you move, and how deep you verify the result. Volume matters because Merchant Center exports and HTTP API pulls take longer as record counts grow. Each resource type adds its own mapping and check, so products, categories, customers, prices and orders each count separately. Custom fields, Custom Objects and integration-owned data add work because they need their own schema review, and Custom Objects only export as JSON. Verification depth is the final driver: a count comparison is quick, while field-level reconciliation against the target system takes considerably more time. Ask the vendor to break the estimate down along these lines.
How long does a commercetools data export take to scope?
Scoping is the part you can control, and it usually takes less time than the export itself. Start by inventorying every resource type, custom field and Custom Object your store uses, then check each against the export limits in the commercetools documentation and the file size limits you plan to re-import. Those two inputs determine how many batches, API passes or manual steps the work needs. No fixed duration can be given here because it depends on your catalog, integrations and order history. Ask any provider to commit to a duration in the written scope, with the assumptions behind it listed.
What access does the team need for a commercetools export?
Your team needs three things before work starts. First, Merchant Center access with a role that can run exports for the resource types in scope. Second, API clients with read scopes for the HTTP API, created in the commercetools project settings, so that anything the Merchant Center does not export can still be queried. Third, a named owner for each data set, such as products, prices, customers and orders, who can answer questions about meaning, status and history. Keep credentials in a secrets manager and rotate them when the engagement ends. Confirm exact scope names and role permissions with commercetools, since they can change.
Can a merchandiser or developer export commercetools data alone?
A merchandiser can usually run Merchant Center exports for simple product and category data, and a developer can script HTTP API queries for anything the interface does not cover. Doing both alone is harder. Merchandisers rarely know how custom fields, product types and Custom Objects map to the target system, and developers often lack the business rules behind prices, tax settings and order statuses. Completeness checks also need a second person who did not run the export. A practical split is one owner for the export scripts and one business owner for each data set, with a documented sign-off before cutover.
What is included in a written quote for exporting commercetools data?
A useful quote lists the resource types in scope, the export method for each (Merchant Center or HTTP API), and how Custom Objects and custom fields are handled. It should name the deliverables, such as exported files, a field mapping document, a row count reconciliation report and a list of known gaps. Ask how file size limits are handled for any file you plan to re-import, how the work splits between fixed-scope phases and ongoing support, and who is responsible for each dependency on your side. Confirm the commercetools contract and subscription terms before signing, because data access, retention and exit provisions sit there.
Which commercetools data needs extra checks before it moves?
Several data types need more checks than standard catalog data:
- Orders and payments, where status history, refunds and tax lines must reconcile.
- Customers and addresses, where consent records and personal data handling need a documented basis.
- Prices and currencies, where channel and customer-group rules affect the result.
- Custom Objects, which export as JSON only and often hold business logic or integration state.
For each, confirm with your legal and finance owners what must be retained, and test a sample record end to end before running the full export.
How do you verify that a commercetools export is complete?
Verification compares what left commercetools with what arrived in the new system, and it works best when designed before the export runs. Record counts per resource type and store are the first check. Next, sample records should be compared field by field, including prices, variants, images references and customer addresses. Images are a common gap: the export carries references, not the files, so you need a plan to fetch and host them. Keep the source data available until the owner for each data set signs off. Ask any provider to describe the reconciliation report they will produce.
How DeployOpen scopes and delivers an exit from commercetools
DeployOpen plans and implements the export side of a move away from commercetools inside your own infrastructure, so you can see what each resource type can and cannot carry before any data moves. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory every resource type you need, then record which ones the Merchant Center exports and which need HTTP API queries.
- Confirm Custom Objects, inventory and order volumes against the export limits in your own tenant before choosing a method.
- Agree in writing which file size limits apply to each re-import file and how large exports will be split.
How we build
- Build repeatable export scripts against the commercetools HTTP API for data the Merchant Center cannot deliver as JSON.
- Test each export on a copy of your data and check record counts against the live tenant before the final run.
- Keep exported files in your own storage with access controls and an encrypted transfer path agreed with your security team.
How we hand over
- Deliver a completeness report that compares source counts, exported counts and sampled records for each resource type.
- Document every export command, query, file format and known gap so your team can rerun the process without us.
- Walk your engineers through the verification steps and record which items still need a decision from your business owners.
How we support
- Offer ongoing support as a retainer if your team wants help rerunning exports or handling later data corrections.
- Review exports again when commercetools changes its API or limits, and confirm the changes with the vendor's current documentation.
- Agree the support boundary in the written scope so responsibilities for the old and new platforms are clear.
