E-commerce migration
Migrate to Drupal Commercewith products and content on one platform
Products in Drupal Commerce are entities you design, so the catalogue has to be modelled before a single record moves. Here is how the Migrate API fits, and where the tooling stops.
A commerce system built from Drupal entities
Drupal Commerce doesn't have one fixed product shape. You define product types with their own attributes, and a product page can carry one or many variations. Because products sit in the same entity system as your content, a product can use the same fields, views and editorial workflow as an article. That is the reason to choose it, and it also means someone has to design those types: an import can't assume a schema that doesn't yet exist.
The current Commerce Core 3.x line works with Drupal 10.3 and above and Drupal 11. The older 2.x line covers Drupal 9.3 and 10, and Commerce 1.x depends on Drupal 7. Which of these you start from sets the size of the job, and a Drupal 7 store is effectively a rebuild into a new system.
How the data gets there
Drupal's Migrate API is the standard route. A migration describes a source plugin that reads CSV, SQL or JSON, a chain of process plugins that transform the values, and a destination such as a user, a term or a Commerce product variation. These definitions live in code, so they run repeatedly on a test site, and a rehearsal can be repeated until it comes out clean.
The Commerce Migrate module is worth checking before writing your own, with its limits in mind. It handles Commerce 1.x and Ubercart as stable sources. Its CSV routes for Magento 2, Shopify and WooCommerce 3 are marked experimental, with no further work planned. The project is listed as minimally maintained, and its latest release, from April 2024, states compatibility up to Drupal 10. For a Drupal 11 target we would expect to write custom migrations and borrow from it where it helps.
What to settle before the import
- Product types and which attributes define a variation, so the catalogue doesn't have to be remodelled after launch.
- Pricing and currency, including whether price lists or promotions are handled in core, in a contributed module or in custom code.
- URL aliases. Pathauto patterns can often reproduce old paths, and whatever they can't reproduce goes into the redirect module.
- Payment gateways. Each needs a maintained module for your Commerce version, and that should be confirmed on drupal.org first.
- Customer logins. How password hashes transfer depends on the source, so we test real accounts during the first rehearsal.
When Drupal Commerce is the wrong answer
Drupal Commerce makes most sense when content and commerce have to work closely together and you already have Drupal skills in-house or a partner to supply them. For a straightforward catalogue with little editorial content, a hosted platform or WooCommerce usually costs less to run. We will tell you that if it's true for you.
What we can show you
We have no published Drupal Commerce migration. Our published migration work is in PHP systems: two PHP 5.6 to Laravel moves, with data checked against the original at each stage. The discipline transfers, but the platform experience on this site doesn't, so ask us about it directly when we talk.
Drupal Commerce migration questions
Can Commerce Migrate move our store automatically?
From Commerce 1.x or Ubercart, it gives you a stable starting point. From Magento, Shopify or WooCommerce, its CSV routes are experimental with no further work planned, so expect custom migrations.
Which Drupal version should we build on?
A new build should use a version the current Commerce Core 3.x line supports, which means Drupal 10.3 and above, or Drupal 11. We check the modules you need against that version before committing to it.
Is Drupal Commerce the right target?
Tell us how much of your site is content, how much is catalogue and what you run today. We will give you a straight view, including when another platform fits better.
We reply within one business day (IST).