Drupal Commerce → to Shopify

Drupal Commerce to Shopify: moving the store, and deciding what happens to the site around it

A Drupal store usually sits inside a content site with years of articles, landing pages, taxonomy and media, and the commerce side is one set of modules among many. Before anything moves, you have to decide whether Shopify takes over commerce only, with Drupal kept for content, or the whole site. This guide covers a Drupal Commerce to Shopify migration for Commerce 2.x and 3.x on Drupal 10 and 11, for Commerce 1.x on Drupal 7, and for Ubercart stores, which we handle the same way.

Why stores leave Drupal Commerce

• Drupal 7 is out of support. Drupal 7 reached end of life on January 5, 2025, and with it the Commerce 1.x and Ubercart stores built on it.
• Commerce is a framework, not a product. Drupal Commerce is flexible because almost everything is configured or coded: order types, checkout flows, pricing, stock. That flexibility needs a Drupal developer for changes a Shopify merchant makes in the admin.
• Major upgrades are projects. Commerce 3.x requires Drupal 10.3 or later, so staying current means core upgrades, Composer updates and contributed module compatibility checks, often at the same time.
• Contributed modules age unevenly. Stock, subscriptions, shipping and payment gateways live in separate modules. Commerce Recurring, for example, is still on a release candidate, and one lagging module can hold back the rest.
• Hosting, security and PCI scope. A self-hosted store puts patching, backups and your share of PCI compliance on you and your host. Shopify is a PCI DSS Level 1 service provider and runs the checkout.
• Checkout and payments. Shop Pay, accelerated wallets and a checkout Shopify maintains replace a checkout flow you configure and test yourself.

To be fair, Drupal remains one of the strongest content platforms available, with fine-grained permissions, structured content and serious multilingual support. If content is the core of your business, keeping Drupal and moving only commerce may be the right answer. We cover that choice below.

What migrates from Drupal Commerce to Shopify

Drupal has no single export screen for commerce data. We extract through the database, which on a self-hosted site means nothing is limited to what an export exposes, and cross-check with Views Data Export or the JSON:API module where a site already uses them. On Drupal 10 and 11 the entities are clearly separated: products, product variations, attributes and attribute values, stores, orders and order items, profiles for addresses, and payments.

Data	Source on Drupal Commerce	Moves to Shopify?
Products with titles, bodies, images, product types and extra fields	Product entities (Commerce 2.x and 3.x), product display nodes (Commerce 1.x), product nodes (Ubercart)	Yes. Custom fields on each product type become metafields with definitions.
Variations with SKUs, prices, list prices, weights and attribute values	Product variation entities and attribute value entities	Yes, as Shopify variants. Attributes become options, up to three per product.
Stock	Commerce Stock or a custom field, since Commerce core has no inventory	Yes, per variant and per location.
Taxonomy terms used for catalogs, brands and filters	Taxonomy vocabularies referenced from product fields	Yes, as collections, the vendor field, or metafields exposed as storefront filters.
Orders with order items, adjustments, taxes, shipping and states	Order and order item entities, including order type	Yes. Real orders with the original number and date, a matching transaction, and refunds where money went back.
Shipments and tracking numbers	Commerce Shipping shipment entities	Yes, as fulfillments with carrier and tracking.
Customers and addresses	User accounts plus customer profile entities (billing and shipping)	Yes. Roles become tags or B2B companies.
Passwords	Drupal 7 $S$ hashes, or bcrypt $2y$ hashes on Drupal 10.1 and later	No. Shopify cannot use Drupal hashes. Customers reset on first login or use passwordless sign-in.
Subscriptions	Commerce Recurring subscription entities and billing schedules	Partly. Contracts can be imported; stored payment methods need gateway work. See below.
Promotions and coupons	Promotion and coupon entities	Rebuilt as Shopify discounts.
Reviews	Comments or a review module	Yes, into Judge.me or your chosen review app.
Articles, pages, media and translations	Nodes, media entities, content translations	Depends on the decision below: moved to Shopify blogs and pages, or left in Drupal.
Theme, views, blocks and custom modules	Theme and module code	No. The design is rebuilt on Shopify and each module is mapped to an app or native feature, or dropped.

Path aliases, redirects and Drupal URLs

Every Drupal page has a system path and, usually, an alias. On Commerce 2.x and 3.x a product’s system path is /product/42, and a specific variation is selected with a query string such as /product/42?v=108. Pathauto generates aliases like /product/blue-shirt or /shop/shirts/blue-shirt. On Commerce 1.x and Ubercart, products are shown through nodes, so the system path is /node/123 with an alias on top. Taxonomy pages sit at /taxonomy/term/7 or an alias like /category/shirts. Multilingual sites add a language prefix, for example /fr/produit/chemise-bleue.

The detail that catches people out: system paths stay live alongside aliases, so Google has often indexed both, and the Redirect module usually holds years of older redirects of its own. We build the Shopify redirect map from the alias table (path_alias on Drupal 8 and later, url_alias on Drupal 7), then add the system paths, the variation query strings, language prefixes and the existing Redirect module entries, flattened so nothing chains, plus anything in Search Console the database no longer knows. Everything lands on /products/handle, /collections/handle, /pages/handle or /blogs/news/handle. If Drupal stays for content, the store moves to a subdomain or path and the redirects are written on the Drupal side. Every redirect is requested against the live domain before launch.

Tools

Cart2Cart, a partner of ours, and LitExtension both list Drupal Commerce as a source, and both are fine for a first pass on products and customers. Their limits are the ones we see on every platform: tracking numbers on shipped orders do not come across, refunded orders tend to land as plain paid orders, and the redirects they generate are built from guessed slugs rather than the aliases Drupal actually served. We finish those parts ourselves, reading the Drupal database directly and reconciling every count against the source tables.

How we run it

1. Audit. Drupal and Commerce versions (or Ubercart), product and order types, contributed modules, subscriptions, languages, content volume, URL patterns, integrations and database access. The result is a fixed-price scope and a recommendation on keeping Drupal for content.
2. Build in a free Shopify development store. As a Shopify Plus Partner we build in development stores, so you pay Shopify nothing until launch. Theme, checkout, payments, shipping, taxes and Markets are set up here.
3. Catalog. Products, variations, attributes as options, extra fields as metafields, taxonomy as collections and filters, images and SEO fields.
4. Customers. Accounts, billing and shipping profiles, roles and marketing consent.
5. Orders. Order items, adjustments, taxes, shipping, transactions, refunds and fulfillments with tracking, under original numbers and dates.
6. Redirects. Aliases, system paths, variation query strings, language prefixes and existing Redirect module entries, tested one by one.
7. Sample, then full import. A sample of each entity including refunded, multi-shipment and anonymous orders for your sign-off, then the full run, reconciled against the Drupal tables.
8. Cutover. DNS or the store path moves to Shopify and a delta sync brings across orders and customers created since the full run.
9. Post-launch SEO evaluation. Once Google has re-crawled the store and the first real analytics are in, we review coverage, 404s, rankings and conversion, and fix what we find.

Cost and timeline

A Drupal Commerce to Shopify migration starts from $2,500 for stores under 500 products and 5,000 orders ($3,500 for larger stores), and typically takes six to eight weeks for smaller stores. B2B pricing, multiple Commerce stores, subscriptions, headless builds and integrations such as ERP or accounting are quoted as a fixed price after the audit. A large content migration is scoped separately from the store. Terms are 50% to begin and 50% once the store is live and you are fully satisfied with the figures.

Drupal 7, Ubercart and Commerce 1 end of life

Drupal 7 security support from the Drupal project ended on January 5, 2025. Commerce 1.x and Ubercart 3.x run only on Drupal 7, and Ubercart never shipped a stable release for Drupal 8 or later, so there is no in-place upgrade path for either. Moving to Drupal 10 or 11 means a full migration to Commerce 3.x anyway.

If you need time, the Drupal Association lists certified vendors in its extended security support program, currently HeroDevs and Tag1 Consulting. That covers core and some contributed modules, but it does not modernize the checkout or your payment gateway integrations, and older gateway modules are often the first thing to break. We treat extended support as a bridge while the Shopify store is built, not an alternative.

Drupal 7 data has its own shape. Commerce 1.x separates the product entity from the product display node that customers see, so one display can reference several products that become one Shopify product with variants. Ubercart stores attributes and option adjustments on the node, and options that change price map the same way.

Keep Drupal for content, or move everything?

There are three workable patterns, and we recommend one in the audit.

• Move everything to Shopify. Best when content supports the store rather than the other way round: a blog, a few landing pages, an about section. Shopify’s blogs, pages and metaobjects handle that well, and you run one platform.
• Keep Drupal, put the store on a subdomain. The store runs on Shopify at shop.example.com with a theme matched to the Drupal design, and Drupal keeps the main domain. It is the simplest split, but it separates content and products across two hosts for SEO, and navigation has to be kept in step on both sides.
• Keep Drupal and sell inside it. Shopify’s Buy Button channel embeds products, collections and a cart into Drupal pages, with checkout on Shopify. For a full headless build, Drupal renders pages and pulls products from Shopify’s Storefront API. Headless gives the most control and costs the most to maintain.

In every split pattern Drupal is still a site you patch and host, so a Drupal 7 site must be upgraded either way.

Multilingual content to Shopify Markets and Translate & Adapt

Drupal stores translations per entity and per field, and serves them from language prefixes or domains. Shopify handles this with Markets and translations: each market gets a domain or subfolder such as /fr/, and the store can sell in up to 20 languages on non-Plus plans and 30 on Plus. We export Drupal’s translations for products, variations, taxonomy terms, pages and articles, and load them into Shopify’s translation layer, where they appear in the Translate & Adapt app for your team to maintain.

The redirect map follows the languages: /fr/produit/chemise-bleue redirects to /fr/products/blue-shirt, not to the English page. Translated handles are set per language where the old site had translated aliases. Drupal sites that used node-per-language translation need the translated nodes grouped back onto one source item first, which we do from the translation set IDs.

Commerce Recurring subscriptions

Commerce Recurring subscriptions have a billing schedule, a state and a stored payment method. Shopify can import subscription contracts into its Subscriptions app by CSV or through the API, but the saved cards are tokens held by your gateway. Moving them requires working with the gateway and Shopify Support, and when that is not possible customers add a new payment method through their account. We map every active subscription and agree the renewal plan with you before cutover.

What you get at handover

A reconciliation ledger from the Drupal tables to the live Shopify counts for products, variants, customers, orders, fulfillments and subscriptions, with every exclusion named; the redirect verification list with the status each old URL returned, including system paths and language prefixes; the attribute and field to option and metafield map; the content decision and what moved where; the translation coverage by language; and a recorded walkthrough of the Shopify admin for your team.

Questions we settle in the survey

• Which Drupal and Commerce versions are you on, or is it Ubercart, and do we have database access?
• Does the content stay in Drupal, or does everything move?
• How many languages and Commerce stores are there?
• Are there active subscriptions, and which gateway holds the cards?
• Do you need live carrier rates at checkout? Third-party carrier-calculated shipping needs Advanced or Plus, or Grow on annual billing, so it decides the plan.
• Which custom or contributed modules does the business rely on day to day?

Frequently asked questions

Start with the migration survey. If your content site runs on WordPress instead, see the WordPress guide, and for heavily customized Drupal builds, the custom-build store guide.