Migrate from Magento or WooCommerce to Drupal Commerce

How much work a Magento or WooCommerce move to Drupal Commerce involves

If your store runs on Magento or WooCommerce and you plan to move it to Drupal Commerce, the short answer is that the data move is the smaller part of the work. Commerce Migrate imports catalog, customer and order data from CSV exports for the Magento and WooCommerce paths, so the migration itself is largely about preparing clean exports and mapping them. The payments, shipping, tax, integrations and order history still need separate planned work, and they are usually where the effort and the risk sit. The Commerce Migrate project page on Drupal.org is the starting point for confirming which paths and releases apply to your setup.

The outcome depends on three things you should document before asking for a quote: the source system version, the data volume, and how much history must carry over. A Magento store on a recent 2.4.x release with a few thousand products and no customer-specific pricing is a different job from a long-running WooCommerce store with years of orders, coupons, subscriptions and custom order statuses. Ask how each export is produced, which fields are in scope, and which orders must be queryable on the new site versus archived. Confirm the Drupal Commerce modules you need for payment gateways and tax, because those are rebuilt rather than migrated.

Agree the scope in writing before any work starts. The written scope should list the entities in the migration, the fields that will be mapped or dropped, the payment and shipping methods to be rebuilt, the external systems to reconnect, and the checks used to accept the migration, such as reconciling order counts and totals against the source. Also confirm who maintains the Drupal Commerce site after launch, since module updates and payment gateway changes recur for as long as the store runs.

What maps cleanly from Magento and WooCommerce to Drupal Commerce

This table compares the main Magento and WooCommerce store data with its Drupal Commerce equivalent and sorts each item into one of three paths: carried by the CSV import, transformed before or after loading, or rebuilt by hand. Read the migration path column first, because it sets the checking effort. Confirm the export formats against the Magento or WooCommerce version in use before field mapping starts.

Capability	Drupal Commerce equivalent	Migration path
Product catalog, variations and categories	Commerce product and product variation entities, with taxonomy terms for categories	Transform: map configurable options and category trees to variation fields and terms; confirm the CSV layout for each.
Customer accounts and addresses	Drupal user accounts with customer profile address fields	Transform: map name, address and country fields; confirm how password hashes and login accounts are handled.
Orders and line items	Commerce order and order item entities with order states	Transform: map order states, totals and currency; check historical line items against the source.
Stock	Stock management through a contributed Commerce stock module or inventory fields	Rebuild or verify: stock locations and reservation logic differ, so set quantities and rules deliberately.
Coupons and promotions	Commerce promotions and coupons with offer and condition plugins	Rebuild: promotion rules do not map one to one; recreate active offers and test them.
Tax rules	Commerce tax types, rates and zones	Rebuild: configure rates and zones by hand from the tax records the store currently uses.
Shipping methods	Commerce shipping methods, rates and carrier integrations	Rebuild: recreate methods, rate tables and carrier connections; historical shipping lines are carried as data.
Payment methods	Commerce payment gateways configured against your processor	Rebuild: card data is not moved into Drupal; reconnect gateways and review PCI DSS scope.
URLs and SEO data	URL aliases, metadata fields and redirects	Transform: map product and category paths and create redirects from old URLs before launch.

Which documented import paths Commerce Migrate provides

Commerce Migrate is the contributed module on Drupal.org that carries store data into Drupal Commerce. Its Magento and WooCommerce paths read CSV exports, so the cards below cover what the module supports, the tools around it and the point where Drupal 11 compatibility has to be settled before scoping.

CSV-based Magento and WooCommerce paths

Commerce Migrate provides migration paths into Drupal Commerce from Ubercart, Commerce 1 and other platforms, and its Magento and WooCommerce paths import data from CSV exports rather than reading the source database directly. Each path expects the export to match the column layout the module reads. Before the build is scoped, compare a sample export from your store against that layout and note which product, customer and order fields have no column to map to.

Stable 4.0.1 release

The stable 4.0.1 release of Commerce Migrate targets Drupal 9.3 and 10. Treat that as the tested baseline for the module, not as proof that it runs on your target version. Check the release notes and issue queue for the exact Drupal core and Commerce versions the team will install, and record them in the migration plan so the rollback and verification steps are tested against the same stack.

Drupal 11 compatibility to confirm

Drupal 11 is the current major version, but the 4.0.1 release targets Drupal 9.3 and 10. Ask the module maintainers in writing whether Commerce Migrate supports Drupal 11 and which Drupal Commerce release it pairs with. If support is missing or partial, the scope needs an allowance for patching or replacing the module, and that work should be priced before the build starts.

Migrate API and Migrate Tools

Commerce Migrate sits on the core Migrate API, so the team uses Migrate Tools Drush commands to run, roll back and re-run imports. Build the migration as versioned definitions in code, run each one against a copy of the production database, and confirm that a rollback removes the imported products, customers and orders cleanly before the first full run.

Field mapping and data checks

Field mapping is the step where most store data is lost or mangled. Map each Magento or WooCommerce attribute, SKU, tax class and customer address field to a Drupal Commerce field, and record every field that has no target. Use row counts and sample comparisons between the export and the Commerce entities to check that products, customers and orders arrive complete.

Rebuilt by hand after import

Payment gateways, shipping methods, tax rules, stock logic and any Magento or WooCommerce extensions do not come across as working configuration from a CSV export. Each of these is a separate build item with its own testing. Ask the implementation partner to list them in the written scope so that the rebuild effort is visible before the migration timeline is agreed.

How the source platform's support dates affect the move

The support lifecycle of the source platform can set the timing of the move, so check it before you fix a migration date. For Magento, Adobe's lifecycle policy gives each 2.4.x release three years of standard support from general availability. Magento Open Source 2.4.9 was released in May 2026 and is supported until May 31, 2029, while 2.4.6 reached end of regular support on August 11, 2026. A store still on 2.4.6 is therefore already outside regular support, and a store on 2.4.7 has a fixed end date of May 31, 2027. Find the exact version in your composer.json and in the admin footer, then record the end-of-support date next to it in your plan.

The planning question is not only what the current release is, but which version the store can export from safely and how long that version has left. Adobe's release schedule says security patches ship at least annually for all supported lines, so a store on an unsupported line may stop receiving fixes before the migration is finished. Confirm with your own team whether the export scripts, custom modules and extensions run on the version you will use as the export point, and whether a patch to reach a supported line is needed first. Adobe's system requirements for 2.4.9 also list PHP 8.5 and MySQL 8.4 or MariaDB 12.3, so check whether the source host can run the tooling you need.

For WooCommerce, do not assume a support window. Confirm the supported WordPress and WooCommerce versions, and the PHP version each requires, from the WooCommerce release notes for the version your store runs before you plan the export. Ask whether the CSV export covers the fields your Drupal Commerce product, customer and order design needs, and whether the plugin version you export from still receives fixes. Treat the export date as a checkpoint: if the source reaches end of support during the build, decide early whether to upgrade the source first or to freeze the export and run a delta load later.

What you rebuild by hand, split by source platform

Magento stores usually carry the most rebuild work because much of their behavior lives in custom code and configuration that a CSV export never contains. The Commerce Migrate CSV path can move catalog, customer and order records, but the logic that produced those records must be designed again in Drupal Commerce. Plan for these items:

Custom modules: Business logic in custom Magento modules, such as pricing, quoting, order routing or fulfillment hooks, has to be re-specified as Drupal Commerce code or configuration. The Magento code cannot be ported line by line, so each behavior needs a written specification and test cases.
Payment gateways: Each gateway, its credentials, capture and refund settings, and stored-card behavior are configured again. Confirm the provider's Drupal Commerce support and its PCI DSS responsibilities before design starts.
Shipping and tax: Carrier methods, zones, rate tables and tax rules are rebuilt from the Magento configuration and checked against the current rules for each market you sell into.
Promotions and pricing: Cart rules, coupon codes, catalog price rules and customer group prices need an inventory of their conditions and stacking behavior, then a rebuild verified with test orders.
Storefront and checkout: Themes, checkout steps and admin customizations are designed again, because Magento templates do not run in Drupal.

Ask for a list of every enabled module, payment method, shipping method and active promotion, and confirm each one has a named owner in the Drupal Commerce build.

Migration sequence from inventory to decommission, with a parallel run

The sequence moves a store's products, customers and orders into Drupal Commerce in controlled stages, proving each stage on copies of the data before the live store is switched off. Each phase ends with a rollback and re-import check so the team knows it can repeat the work or go back.

Inventory data and integrations
Before any import, the team lists what the source store holds: product types and variations, customer accounts, order history, refunds, coupons, tax and shipping rules, and every system the store talks to, such as the ERP, payment gateway, shipping carrier, email service and analytics. The partner and the store owner agree which data must move, which can be archived as read-only exports, and which will be dropped. The step ends with a signed-off inventory and a list of integrations that must be rebuilt on the Drupal side. Confirm with your store team which fields are actually used, since legacy stores often carry unused attributes.
Run a pilot import on a copy
The team takes a full export of the source store, loads it into a non-production Drupal Commerce site running Commerce Migrate, and runs the CSV-based import for products, customers and orders. The pilot is run against a copy so the live store is untouched. Counts are compared between the export and the imported entities, and a sample of records is checked by hand. The step is complete when the import runs from a clean Drupal database and a second run after rolling back produces the same counts. Record every error and warning, because each one becomes a mapping or cleanup task in the next phase.
Map fields and validate the data
Working from the pilot results, the team maps each source column to a Commerce product, variation, customer profile or order field, and writes down transformations such as currency handling, address formats, order status names and tax values. Validation scripts or reports check for orphaned order lines, duplicate customer emails and products without prices. Business owners review order and customer samples to confirm that totals, statuses and addresses match what staff see in the old admin. The step ends with a versioned mapping document and a validation report that shows zero unresolved errors in the sample set. Each mapping change is followed by a fresh rollback and re-import of the test site.
Rebuild payments and shipping
Migration does not carry over payment credentials or shipping integrations, so the team rebuilds them in Drupal Commerce using the payment gateway and shipping modules that match the store's providers. Tokenized card references, saved payment methods and carrier accounts are confirmed with each provider, since some cannot be moved and customers may need to re-enter them. Tax rules, shipping zones, rates and checkout flows are rebuilt and tested with test transactions in sandbox environments. The step is done when test orders complete through every payment path and shipping option, and each refund or cancellation path works on imported orders. Scope and cost of this work depend heavily on the number of providers and custom rules.
Run a parallel period with order checks
For a defined period set during scoping, the old and new stores both accept orders, or the team reconciles new orders from the old store into Drupal Commerce on a schedule. Staff compare order counts, totals, tax, shipping charges, inventory levels and customer records between the two systems each day. Discrepancies are logged with a root cause and assigned to the mapping, the payment integration or the process owner. The step closes when the reconciliation log shows no unexplained differences for the agreed checks and the business signs off. Confirm with the partner in writing how the parallel run is staffed and what happens to stock levels that both systems can change.
Cut over to the new store
The team runs a final incremental import of data changed since the last sync, freezes changes on the old store, repeats the reconciliation checks, and points domains, DNS and integrations at Drupal Commerce. A documented rollback plan states the exact conditions under which traffic returns to the old store and how orders placed during the window will be reconciled. Monitoring and error tracking are watched during the first trading period, with the partner on call according to the agreed support arrangement. The step is complete when live orders are flowing through Drupal Commerce, the integrations confirm receipt, and the rollback plan has been tested against the staging copy. Confirm the cutover window and support hours with your provider.
Decommission the old store
Once the business has accepted the new store and the agreed retention period for the old data has been set, the team archives a final export of the source database, media and logs to storage the organization controls, and records where each archived dataset lives and who may access it. Access to the old admin, API keys, payment and carrier credentials, and scheduled jobs are revoked, and the hosting is shut down or reduced to read-only. The step ends with a decommissioning record that lists retained data, its location and its review date. Check retention requirements with your legal and compliance team before deleting anything, because customer and tax records may have their own obligations.

What drives migration cost and duration

This table lists the factors that move cost and effort up or down on a Magento or WooCommerce to Drupal Commerce move, and whether each one is paid once or recurs. Use it to see which inputs your quote should be built on and which questions to put to any partner before you agree a written scope.

Driver	Why it changes cost or effort	One-time or recurring	What to ask for in a quote
Products and variations	Each product type, variation axis and attribute set needs mapping and checking in the CSV export, and variations often need manual correction.	One-time	Product count by type, how variations are stored, and the mapping and validation steps included.
Customers and order volume	Larger customer and order files take longer to import, reconcile and verify, and raise the cost of spot checks.	One-time	Record counts for each entity and the reconciliation report the migration will produce.
Years of order history	Every extra year kept adds data to map, test and display, and more edge cases in tax, currency and status values.	One-time	Which years are in scope, and whether older orders are imported or archived read-only.
Custom Magento modules or WooCommerce plugins	Data stored by custom extensions has no ready mapping, so each custom field or table must be analyzed and rebuilt by hand.	One-time	An inventory of custom modules and plugins, and the effort assumed for each data set they own.
Payment and shipping integrations	Gateways, tokens, shipping methods and rate rules are not carried over by a data import and must be rebuilt and tested in Drupal Commerce.	One-time build, plus recurring gateway fees charged by the provider	Each integration named, the test transactions included, and who holds gateway credentials.
ERP, CRM and accounting links	Each system that receives orders, stock or customer records needs a new connector and a reconciliation plan for IDs.	One-time build, recurring hosting and maintenance of the connector	Interfaces in scope, sync direction, and whether the connector is maintained after launch.
Data quality	Duplicate customers, missing addresses, inconsistent SKUs and invalid tax codes add cleaning rounds before any load.	One-time	A data quality assessment before the scope is fixed, and the cleaning work assigned to a named party.
URL and SEO redirect requirements	Mapping old product, category and order-related URLs to new paths requires a redirect table, checks against search data and a plan for rankings.	One-time build, with redirect rules kept in place over time	The redirect map source, how long redirects are kept, and the verification method.
Parallel-run cycles	Each trial load, comparison of stores and correction round repeats import, review and fix work, so cost grows with the number of cycles.	One-time, with a hosting cost for each parallel environment	The number of trial loads included, the cutover rehearsal, and the rollback procedure priced separately.

What usually goes wrong with customer and order history

Most problems in a store migration appear after the data arrives, when totals, stock or search traffic no longer match the source. The cards below cover the risks that the CSV path and a rushed cutover tend to create, and the checks that catch them before customers do.

Customer passwords and accounts

CSV exports from Magento and WooCommerce generally do not carry usable password hashes, so customers cannot sign in with their old credentials on day one. Decide early whether accounts are recreated with a forced reset, invited by email, or kept on an external identity provider. Confirm with your team which customer fields, addresses and consent records the export actually includes, and test a sample login before the cutover plan is fixed.

Order totals and tax that do not reconcile

Imported orders can show subtotals, discounts, shipping or tax that differ from the source by a few cents or by whole line items, especially where rounding, coupons or multi-currency settings differed. Build a reconciliation report that compares order counts, grand totals and tax per order and per period against the source system, and sign it off with finance before any order is treated as final.

Stock levels out of sync at cutover

If the old store keeps taking orders while the new one is loaded, inventory on the new site starts stale and overselling follows. Set a dated freeze window in which the source store stops accepting orders or stock changes, take a final export inside that window, and agree who can override stock during the first days live.

Broken product URLs and lost search rankings

Magento and WooCommerce use their own URL patterns for products, categories and filtered pages, and those paths will not match Drupal aliases by default. Without a redirect map from every indexed old URL to its new equivalent, inbound links and search rankings are lost. Export the URL list from the source and their analytics, map each path, and test the redirects on staging with a crawl before launch.

Stored payment tokens that cannot move

Saved cards live in the payment provider's vault and are tied to the original gateway merchant account, so they generally cannot be exported as plain data into Drupal Commerce. Plan for customers to re-enter cards, or ask the current and new payment providers whether a supported token migration exists. Confirm the scope of payment data in your environment before any export, because it affects PCI DSS scope.

Commerce Migrate release that misses the Drupal version

The Commerce Migrate module has version requirements that must match the Drupal core you plan to run, so a mismatch can block the import or leave the site on an unsupported base. Check the current release notes and compatibility before choosing the Drupal version, and pin both in a test build. The stable 4.0.1 release targets Drupal 9.3 and 10, so confirm the target line with your team before committing to Drupal 11.

Questions buyers ask before moving a store to Drupal Commerce

What does it cost to move a Magento or WooCommerce store to Drupal Commerce?

No fixed price applies, because the cost follows from the written scope. The main components are discovery and data mapping, the Commerce Migrate import work, rebuilding payment, shipping and tax logic by hand, theme and checkout work, and test cycles. Most of the cost is one-time project work. Recurring costs sit in hosting, security updates and module maintenance after launch. Ask any partner to split the quote into these components, to name which items depend on how many products, customers and order records you have, and to state which payment and shipping integrations are included. DeployOpen does not publish a price list, and a quote follows from the written scope.

How long does a store migration take?

Duration depends mainly on the size and cleanliness of your data, how many custom features the store uses, and how many payment and shipping integrations must be rebuilt. Commerce Migrate reads CSV exports, so the import itself is often the shorter part. The longer phases are cleaning product attributes, deciding how old orders and customer accounts map, and testing checkout end to end. Ask for a timeline in the written scope that lists each phase, the test rounds included, and the decisions your team must make before each phase can close.

What must our team provide before a migration starts?

Your team needs to supply four things early:

Complete CSV exports of products, customers and orders from the source store, with the export settings documented.
A named data owner for products, customers and orders who can answer field-level questions.
Written decisions on payment gateways, shipping methods, tax rules and which discounts carry over.
Dedicated test time from people who know checkout, returns and order management.

Without these, the migration team has to guess at mappings, and the guesses tend to surface during user acceptance testing.

Can our internal team migrate the store without a partner?

Yes, if you have engineers who know Drupal, Drupal Commerce and your source platform's data model, and the time to test. Commerce Migrate is a contributed project on Drupal.org, so the import path is open to any team. The harder work is the rebuild: payment and shipping configuration, custom checkout logic, and reconciling data that does not map cleanly. Confirm that your team can cover those items, staff the testing, and maintain the result after launch. A partner is most useful when those skills or hours are missing.

Will full order history come across to Drupal Commerce?

Order history depends on what the CSV exports contain and how the target store models orders, line items and adjustments. Confirm which order fields, line items, statuses and dates your export includes, and check whether refunds, partial shipments and discounts are represented. Plan a reconciliation step that compares order totals and counts against the source system for a sample of periods. Some historical detail may need to be stored in a reference form rather than as live Commerce orders, and that choice should be agreed before the build starts.

What happens to customer passwords and saved payment tokens?

Passwords and payment tokens are usually not portable in a plain CSV export, and you should not expect them to move automatically. Customer passwords typically need to be reset, or customers need a controlled re-activation path, depending on how the source platform hashed them and what your security policy allows. Saved card tokens are tied to the original payment provider, so they normally must be re-collected or migrated through that provider's own process. Confirm both points with your payment provider and in the written scope, and plan customer communication before cutover.

Which parts of the store must be rebuilt by hand?

Expect to rebuild the parts that are logic rather than data. This usually includes payment gateway configuration, shipping rules and carrier connections, tax calculation, promotions with custom conditions, custom checkout steps, the storefront theme, and any integrations with ERP or fulfillment systems. Product data, categories and basic customer records are the parts most likely to import directly. Ask for a written inventory of these items so you can see which rebuilds are in scope and which remain with your team.

How DeployOpen works on this

DeployOpen is a Chainscore Labs company that plans, implements and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Magento or WooCommerce move into Drupal Commerce, we start with a written scope that names the source exports, the data to be moved and the parts that will be rebuilt by hand.

How we scope

Inventory the Magento or WooCommerce version, extensions and CSV exports that will feed the Commerce Migrate paths.
List which products, customers and orders move, and which order history and account data stay in an archive.
Agree in writing which payment, shipping, tax and stock integrations are rebuilt, and which are out of scope.

How we build

Map source CSV columns to Drupal Commerce product, customer and order entities, and record each transformation rule.
Run migrations into a non-production environment repeatedly, with rollback tested before each full load.
Rebuild storefront checkout, payment gateways and shipping rules by hand, then test them against sample orders.

How we hand over

Deliver the mapping document, migration scripts, reconciliation reports and a list of data that was not moved.
Document the runbook for the final cutover, including freeze windows, redirects and the rollback decision point.
Walk your team through the Drupal Commerce site so they can maintain products, orders and integrations after launch.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the migration is complete.
Plan Drupal and Drupal Commerce update routines, so future module releases do not reopen the migration work.
Confirm with us during scoping which post-launch support, monitoring and backup responsibilities will sit with your team.