Can you export your data from Shopify Plus?
Yes, but only part of the store comes out through the admin. Products, customers and orders can be exported as CSV files, while product images, automatic discounts and some metafields do not come out that way and need a separate plan. A merchant weighing a renewal or a move to a self-hosted platform should treat the admin export as the starting point of the data transfer, not the whole of it.
Products export from the admin as a CSV file, but the file carries no product images. Shopify advises keeping the original store live until the new store has imported images from their public URLs, so the old storefront is still needed during the transfer. Customers export as a CSV limited to 15 MB, and the export includes tags and supported metafields. Order exports cover the order records the admin allows you to pull, so confirm with Shopify and your own admin reports how far back the history goes before you plan the cutover. Ask whether any custom data sits outside the supported export fields.
Automatic discounts are the gap most merchants miss. They are rules that apply at checkout, not records a CSV can hold, so you must document each rule's conditions, dates and value and rebuild it on the new platform. Metafields that the CSV does not include need the Admin API, which is also the route for fuller order history. Your developers should inventory every metafield namespace and every automatic discount before a renewal decision, and keep the live store running until those items are verified in the new environment.
Which Shopify Plus data exports as CSV and what the limits are
This table compares how products, customers and orders leave Shopify Plus, the file format each export uses and the limits Shopify documents. Read it as a checklist: the CSV exports cover the basic records, while metafields, images and full order history need a separate path before you cut over.
| Data | Export method and format | Documented limits and gaps |
|---|---|---|
| Products | Product CSV exported from the Shopify admin | Product images are not included in the CSV, so keep the original store live until images are re-imported from their public URLs |
| Customers | Customer CSV exported from the Shopify admin, including tags and supported metafields | File size is limited to 15 MB, so large customer bases may need to be split into several exports (confirm the split approach with Shopify support) |
| Orders | Order export from the admin as CSV (confirm the current columns and row limits in your admin) | No order export limit is set in the facts reviewed here; confirm how much order history and line-item detail the CSV carries |
| Metafields | Not reliably covered by the CSV; use the Shopify Admin API for product, customer and order metafields | Metafield definitions and values need programmatic extraction, and the output must be mapped to your new platform's fields |
| Automatic discounts and apps | Not included in standard CSV exports | Rebuild discount logic and app data in the new platform; export the rules you can see and document the rest |
| Full order history | Admin API for complete historical records (confirm rate limits and access scopes for your store) | Plan for scripted extraction and time for validation against order totals, refunds and fulfillment status |
What does not come out of the admin export and how to handle it
The admin CSV files cover products, customers and orders, but several things that run your store never leave Shopify in that form. Each gap below needs a named owner, a workaround and a check before you cut over, so the new store is not missing a piece you only discover after launch.
Product images
Product CSV files do not include images. Shopify advises keeping the original store live until the new store has imported images from their public URLs. Before you cancel anything, confirm with your vendor that the image URLs stay reachable, and check that every product's image set, alt text and variant image links appear in your export before you rely on it. Test a sample of products end to end.
Automatic discounts
Automatic discounts apply at checkout without a code, so they are not part of the customer or order exports. Export the discount settings from the admin and write them into a list with conditions, dates, minimum amounts and eligible products. Recreate each rule in your new platform's promotion engine, then place test orders that should and should not trigger it.
Shopify Functions
Functions run custom discount, shipping and payment logic inside Shopify's checkout, and their code lives in your app or theme rather than in a data file. Nothing in the CSV exports reproduces that logic. Document what each function does, the inputs it reads and the outputs it sets, then rebuild the behavior as application code or platform rules and test it against the same carts.
App-stored data
Installed apps often keep data in their own databases, such as subscriptions, reviews, loyalty points or wishlists. Standard exports omit most of it. Use the Admin API to read the metafields and app records you rely on, and ask each app vendor for a data export or a documented API. Where a vendor cannot provide one, plan to re-enter or accept the loss of that data.
Metafields and full order history
Customer and product CSV files include only some metafields, and order exports may not hold the full history you need for support or tax records. Where the CSV falls short, query the Admin API for metafield definitions and complete order data. Confirm the scope of data your team needs to keep, and check the access permissions your API credentials hold before you start the export.
When the Admin API is needed for metafields and full order history
CSV exports cover only part of a Shopify Plus store, so metafields beyond the fields a CSV carries, complete order history and data written by apps usually need the Shopify Admin API. Before you commit to a CSV-only extraction, list every metafield namespace your theme, apps and checkout rely on, and check each one against what the product, customer and order exports actually contain. Anything missing from the files becomes an extraction task for engineers.
That task is a small extraction service, not a file download. Your team will need an app or script with an access token scoped to the read permissions it needs, cursor-based pagination to walk each resource from the first page to the last, and a checkpoint so a failed run resumes instead of restarting. Plan for rate limits by throttling requests and backing off when the API signals it is near its limit. Store raw responses alongside the transformed records so you can rerun mappings without calling Shopify again, and reconcile record counts per resource against the admin before cutover.
Confirm current API scopes, rate limit behavior, pagination rules and how far back order history can be read in the Shopify developer documentation for your API version, since these details change and should not be taken from this page. Also ask whether any order or customer data needs a separate approval or is restricted for your app type, and record that answer in your migration plan. Those checks determine how long the extraction runs and whether your order history is complete at cutover.
The export sequence and how to verify each step
The sequence captures a frozen baseline of the store, then moves catalog, customer, order, image and metafield data in an order that makes each piece checkable against the live admin. Each step closes with a count or sample comparison, and the original store stays live until the target confirms everything.
Freeze a baseline snapshot of the store
Before exporting anything, the merchant or store operator records the current state of the store: product, customer and order counts from the Shopify admin, plus a list of installed apps, themes, metafield definitions and active automatic discounts. Keep the snapshot in a dated spreadsheet or document. This baseline is the reference every later check is measured against, so it should be captured on the same day the exports run. Done means the snapshot is saved, dated and shared with whoever will sign off the migration.
Export products to CSV
From the Shopify admin, the store operator exports products as a CSV file. The file carries product fields, variants, prices, inventory and tags, but not product images, so image handling is a separate step. Open the file in a spreadsheet and compare the number of distinct product handles with the product count in the baseline, and confirm a sample of variants matches the live admin for price, SKU and option values. Done means the row and handle counts reconcile and the sampled products match.
Export customers and orders
Export customers to CSV from the admin, checking that the file stays within the 15 MB limit Shopify documents for customer exports. If the file is split or the export is emailed, confirm that every part arrived before combining them. Export orders the same way, noting the date range or export scope you used, because order history in a CSV may not match the full history the admin shows. Compare customer and order counts against the baseline and spot-check several customers and orders, including one with tags, multiple fulfillments and a refund.
Download image files from public URLs
Product images are not in the product CSV, so the operator collects the image URLs from the export or the admin, downloads each file, and stores it in object storage or on the target server under a predictable path. Shopify advises keeping the original store live until the new store has imported images from their public URLs. Count the downloaded files against the number of image URLs, check for failed downloads and retry them, and open a sample of images to confirm they are not truncated or mismatched to the right product.
Pull metafields through the Admin API
Metafields are not fully covered by CSV exports, so a developer uses the Shopify Admin API to read metafield values and definitions for products, customers and orders, and saves the output as JSON or CSV keyed by the Shopify ID. Confirm that each metafield definition in the baseline appears in the output, that counts match for each resource type, and that a few values, such as structured data or references, are stored in a form the target can read. Done means every definition has an exported set of values that matches a live spot check.
Reconcile counts and sample records
Compare every export against the baseline and the live admin. For products, customers and orders, record totals, sampled records and any difference, and investigate each mismatch before moving on. Confirm that the stored image set, metafield set and automatic discount list, which Shopify exports do not carry, are documented in a separate handoff list for manual rebuilding. The reconciliation log, signed off by the merchant, is the output of this step.
Keep the original store live until confirmed
Do not close, downgrade or disconnect the Shopify Plus store when exports finish. Keep it running until the target platform has imported the data, the images resolve from their new location, and the reconciliation log shows no unexplained differences. Only then should the team plan the cutover, using the same baseline to check the target store on launch. Ask your Shopify contract owner which terms apply to closing the store, and confirm them in writing before changing anything.
How the exported data maps to each target platform
Magento Open Source is a self-hosted PHP platform licensed under OSL-3.0, with AFL 3.0 also included in the distribution, so the store's data lives in your own database. Shopify's product, customer and order CSVs are the usual starting point for a catalog-heavy move, but the CSV layouts do not match Magento's import templates column for column. Plan a mapping step that converts Shopify fields into the target's import format before any test load.
- Product CSV mapping: Shopify product handles, variants and option names need translating into Magento's product types and attribute sets before import.
- Images: The Shopify product CSV does not include images, so you will import them from their public URLs or from a separate download step.
- Customers and orders: Customer CSVs can carry tags and supported metafields, but order history usually needs to be loaded through a scripted path.
- Version targeting: Magento 2.4.9 lists PHP 8.5 and MySQL 8.4 or MariaDB 12.3 (recommended) among its requirements, so confirm the import tooling runs on the version you deploy.
Confirm the accepted columns, file formats and import limits in the Magento documentation and test each file type on a staging copy before cutover.
Saleor is a BSD-3-Clause, Python-based headless platform that exposes everything through a GraphQL API, so the import path usually goes through mutations rather than a single file upload. Its data model separates products, variants, stock and prices by channel, which means a flat Shopify export needs restructuring before it fits. Expect the mapping to be a schema exercise as much as a data-copy exercise.
- Channels and pricing: Per-channel pricing, currencies and products must be defined per channel, so a single Shopify price column may need to fan out into several channels.
- Warehouses and stock: Stock is tracked across multiple warehouses, so inventory from Shopify locations needs an explicit warehouse mapping.
- Metadata: Saleor extends data through metadata and apps, so Shopify metafields are typically mapped into metadata fields you define.
- Promotions: Sales, vouchers, cart rules and gift cards are configured in Saleor's promotion engine, so Shopify discount data needs to be rebuilt rather than copied.
Confirm the mutation inputs, required fields and accepted file formats in the Saleor documentation before writing import scripts.
Medusa is built with Node.js and TypeScript on PostgreSQL, with separate modules for carts, orders, product catalogs, pricing and inventory. An export from Shopify therefore lands in module tables rather than a single storefront table, and the import is usually a script that calls Medusa's module services or workflows. Because the core is MIT licensed, the import tooling can live in your own repository.
- Module-based loading: Products, pricing and inventory are separate modules, so each Shopify CSV usually feeds several module calls.
- Migrations first: Medusa runs database migrations through a predeploy script before each startup, so schema changes are applied before any data load.
- Server and worker instances: A self-hosted deployment runs one instance in server mode and one in worker mode, so confirm which process runs scripted imports and background jobs.
- Operational settings: Production uses Redis-based caching, event bus and locking, plus S3 for file storage, and product images will need an S3 destination.
Confirm the module APIs, import workflows and any Medusa Enterprise features you plan to use in the Medusa deployment and repository documentation.
WooCommerce is a GPL-2.0-or-later plugin built on WordPress, so products, orders and customers are stored in WordPress's database alongside content. Shopify exports therefore go into WooCommerce's product, customer and order structures through the WordPress environment, usually with the WooCommerce importers or a plugin you choose. Variants, images and order history are the parts that most often need extra handling.
- Product and variant structure: Shopify variants must be expressed as WooCommerce variable products, so option names and SKUs need to be checked carefully.
- Images: Images are not in the Shopify product CSV, so plan a step that fetches them from public URLs and attaches them to the matching products.
- Customers and orders: Customer records and order history may need a separate script or plugin, since the CSV path alone does not guarantee full order history.
- Extensions: Subscriptions, B2B and other Shopify app features are handled by WooCommerce extensions, which carry their own data formats.
Confirm the importer's accepted fields and file formats in the WooCommerce documentation, and test the import against a copy of the WordPress database.
What to plan before the Shopify Plus contract renews or ends
The export itself is the easy part. The decisions that decide whether a move goes smoothly are timing, what stays live, which apps hold data you need, and how traffic is redirected. Each card below is a decision or check to settle with your team before the renewal date or the cancellation deadline in your contract.
Schedule the full export early
Run the product, customer and order exports well before the renewal or end date, not in the final week. Exports are limited in size and may arrive by email, so large catalogs and customer files can take several attempts. Check the file limits in the Shopify Help Center, confirm which order history you can actually export from the admin, and note where the Admin API will be needed for metafields and full history.
Keep the store live
Do not cancel the Shopify Plus store until the new platform shows verified images. Shopify states that product images are not in the product CSV, so the new store must import them from their public URLs while the original store still serves them. Keep the live store active through verification, not only through data import.
Inventory your apps and their data
List every installed app and the data it stores outside the core catalog, such as reviews, subscriptions, loyalty points, wholesale pricing or custom fields. Standard exports will not carry all of it. For each item, confirm with the app vendor whether data can be exported, and decide whether it is rebuilt, migrated through the API or dropped.
Record DNS and redirect plans
Document every domain, subdomain, storefront URL pattern and redirect that search engines and campaigns depend on. Map old product, collection and page URLs to their new destinations before cutover, and decide who controls DNS changes and when. Check the redirect list against your top traffic sources so search rankings and paid links are not broken on day one.
Agree a parallel-run period
Agree in writing how long the old and new stores run side by side, who signs off on order, customer and inventory totals, and what triggers a rollback. A parallel run lets you compare order counts, customer records and checkout results before the old store is switched off. Ask your implementation partner to put the duration and acceptance criteria into the written scope.
Questions buyers ask before exporting their Shopify Plus data
How much effort does a full Shopify Plus data export take?
The effort depends mostly on what you need to move, not on the export button itself. Product and customer CSVs are quick to produce from the admin, but the work grows with the parts that do not export cleanly: product images, metafields, automatic discounts and full order history. Each of these needs a separate route, usually the Admin API, and a mapping decision in the target platform. Catalog size, the number of custom fields, how many apps hold data you rely on, and how many years of order history you keep all push the effort up. Ask for an inventory of data types before you estimate anything.
Can our team export Shopify Plus data without outside help?
A team with admin access and someone comfortable with CSV files can export the basic product, customer and order files alone. The gaps appear when you need data outside those files. Shopify's product export does not include images, and the customer export is capped at 15 MB according to the Shopify Help Center, so larger stores need repeated exports. Metafields, full order history and automatic discounts generally require API work, scripting and validation against the target platform's data model. Decide early which of these your own engineers can own and which you want to hand to a specialist.
What access and sign-off does our team need to provide?
Expect to supply admin or staff account access to the Shopify store, API credentials for a private or custom app with read permissions for the data types in scope, and a named owner for the data sign-off. You also need a decision on which apps stay connected during the export, since some apps hold data Shopify does not show. Sign-off should cover record counts, sample checks on products, customers and orders, and written acceptance of what will not be carried over. Keep the original store live until images and records are confirmed in the new environment, as Shopify advises for image re-import.
What does a fixed-scope export engagement from DeployOpen cover?
A fixed-scope engagement covers the agreed data types, the export method for each, the transformation rules needed for the target platform, validation reports and handover documentation. Scope, deliverables and timelines are agreed in writing before work starts, and DeployOpen does not publish a price list, so a quote follows from that written scope. Ask whether the scope includes image retrieval, metafield mapping, order history depth, test imports and a final reconciliation. Anything outside the written scope, such as storefront rebuilding or payment setup, should be scoped separately.
How long does a Shopify Plus data export take?
Timing depends on the factors that drive the work: the number of data types, catalog and order volume, the amount of API scripting required, how many validation cycles your team wants, and how quickly your team can review and sign off each stage. Availability of the Shopify store admin, the target environment and named reviewers also affects the schedule. DeployOpen does not quote durations without a written scope, so ask for a plan with stages and dependencies that you can check against your own release calendar.
What happens to data that cannot be exported directly?
Some data does not leave Shopify in a standard file. Product images are not in the product CSV, so they must be re-imported from their public URLs. Automatic discounts and Shopify Functions logic are typically not exportable as data, so you rebuild them as rules in the target platform. Apps may store data in their own systems, which you need to request from each vendor. Decide per item whether to migrate, rebuild, recreate manually or retire it, and record that decision in the sign-off document so no one assumes the data came across.
Does the export have to happen before the platform decision?
Not necessarily, but the target platform changes which data is worth extracting in which shape. A headless platform with a GraphQL or REST data model may need different mappings than a store with a native product and variant structure. Many teams run a first full export early to measure data quality and volume, then refine the mapping once the target is selected. This keeps the decision informed by real counts rather than assumptions. Ask your implementation partner to confirm which export outputs are useful regardless of the final platform.
How DeployOpen scopes and delivers a Shopify Plus data exit
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms in your own infrastructure. For a Shopify Plus data exit, we start with a written scope that names each export file, each API extraction and each gap that needs manual work before any data moves.
How we scope
- Inventory which product, customer and order exports the store can produce today, and which data needs the Admin API instead
- Record metafields, image sources, automatic discounts and order history gaps so none are discovered after cutover
- Agree deliverables, timelines and responsibilities in writing before any work starts, since most engagements are fixed-scope
- Confirm the target platform, hosting location and who owns the original store during the transition period
How we build
- Build repeatable extraction scripts for the Admin API where CSV exports stop short of metafields or full order history
- Map exported fields to the target platform's data model and document every transformation rule applied
- Test imports in a staging environment, comparing record counts and sample records against the source store
- Plan image re-import from public URLs and keep the original store live until that import is verified
How we hand over
- Deliver a field-level mapping document, an export runbook and a reconciliation report covering counts and exceptions
- Provide the scripts and configuration in your repositories so your own team can rerun or audit the exit
- Walk through open items, known gaps and manual decisions with the people who will own the new store
- Document the evidence trail that supports data handling reviews, without issuing any audit report or certification
How we support
- Offer ongoing support, upgrades and continuous testing for the new platform as a separate retainer after handover
- Agree support boundaries in the written scope, including who responds to incidents and within which channels
- Ask vendors and your own teams to confirm platform licensing, hosting and extension terms before go-live
- Request a quote based on the written scope, since DeployOpen does not publish a price list
