Why a Commerce 1 store needs a new site, not an upgrade
Moving a Drupal 7 Commerce 1 store to current Drupal Commerce is a migration into a new Drupal site, not an in-place upgrade. Drupal.org documents that Drupal 6 and 7 sites cannot simply be updated to Drupal 10 or later. They are migrated into a new site using the core Migrate, Migrate Drupal and Migrate Drupal UI modules or Drush, and the themes must be rebuilt because they cannot be migrated. The effort depends on how much store logic, payment and shipping configuration and order history your team needs to carry across, so that inventory should be taken before any target is chosen.
Set the target version and timeline early. Drupal 7 security support ended on January 5, 2025, according to Drupal.org, and the Drupal Association's Extended Security Support Provider Program lists certified vendors for sites that cannot migrate yet. Drupal 10 reaches end of life on December 9, 2026, according to the Drupal core release schedule, and Drupal 12 is scheduled for the week of December 7, 2026. A store that lands on Drupal 10 late in 2026 will need a second move soon after, so the decision should weigh the Drupal 11 path. Confirm with your own team which Drupal Commerce release and PHP version your hosting supports before you commit, since Drupal 11 requires PHP 8.3 or later.
Do not expect a duration until a written scope exists. The work divides into the new site build, the rebuilt theme and checkout, the mapping of products, customers and orders, and the payment and shipping rebuilds, and each part is sized differently. Ask any partner to list which Commerce 1 configuration will be recreated by hand, which data will be migrated by script, and how order history will be verified after cutover. Those answers, rather than a generic estimate, determine the effort and the cost.
What maps cleanly from Commerce 1 and what must be rebuilt
This table compares common Drupal Commerce 1 capabilities with their current Commerce equivalents and marks each row as data that usually migrates, work that needs a rebuild, or a decision the business must make. Use it to scope the project before a migration run, and confirm every row against the Commerce Migrate version you plan to use, since coverage changes between releases.
| Commerce 1 capability | Current Drupal Commerce equivalent | Migration notes |
|---|---|---|
| Products and variations (data): SKUs, titles, prices, status | Product and product variation entities | Usually migrates as data. Check that every SKU is unique and that variation prices carry over without rounding changes. |
| Product types and attached fields | Product types with fields configured in the new site | Rebuild the type configuration first, then map fields. Custom field types from Commerce 1 contrib modules need a decision. |
| Orders and line items (data): order state, totals, line items | Order and order item entities with a state machine | Usually migrates as data for history. Confirm how Commerce 1 order states map to current states, and test totals against live payments. |
| Customer profiles and accounts (data): billing and shipping profiles | Customer profiles and user accounts | Migrates as data when emails are unique. Decide how to handle duplicate customers and whether passwords are carried over or users reset them. |
| Addresses (data): country, administrative area, postal code | Address field on profiles, using the address module format | Usually migrates, but free-text regions and legacy country codes need cleaning before the run. |
| Taxes: rates and tax types (decision) | Tax types and rates configured per store, with tax zones | Needs a decision. Historic tax calculations are rarely recalculated, so decide what is migrated as stored values and what is configured for new orders. |
| Coupons and promotions (decision) | Promotions with offers and conditions, and coupon entities | Needs a rebuild and a decision. Active coupons may migrate, but complex rule logic must be rebuilt and retested. |
| Payment gateway settings (rebuild) | Payment gateways configured in the new site with contributed gateway modules | Rebuild, not migrate. Credentials and tokens are not moved as plain data, so each gateway must be reconnected and tested in a non-production environment. |
| Shipping methods and rates (rebuild) | Shipping methods with contributed shipping modules where needed | Rebuild the rules and rates by hand. Stored shipping amounts on past orders usually migrate as history. |
| Stock (decision) | Stock handling depends on the stock module chosen | Needs a decision on the stock source of truth. Confirm whether current stock levels, reservations and locations must be migrated or reloaded from your inventory system. |
| Commerce 1 contrib modules with no current equivalent (decision) | Varies by module, often replaced by a different contributed module or custom code | Inventory every contrib module on the Commerce 1 site. Each one without a current equivalent needs a rebuild estimate or a business decision to drop it. |
Documented import paths for a Commerce 1 store
A Commerce 1 store usually moves through several paths at once: the Drupal 7 site itself, the Commerce data inside it, and the custom or external sources that feed it. Each path below moves a different slice of the store, so the plan should assign every entity and integration to one path before the build starts.
Core Migrate API for the Drupal 7 site
The core Migrate API, with Migrate Drupal and Migrate Drupal UI, moves the Drupal 7 site's content types, fields, users, taxonomy, files and core configuration into a new site. Drupal 6 and 7 sites cannot be updated in place, so this is the base layer of the move. Themes do not migrate and must be rebuilt, and Commerce entities depend on the Commerce Migrate module. Confirm the Migrate Drupal versions that support your target Drupal and PHP versions before you fix the plan. Themes are always rebuilt by hand.
Drush-driven migration runs
Running the migration from Drush rather than the admin interface makes each rehearsal scriptable, logged and repeatable. The same command sequence can run against a copy of production several times before cutover, which shows how long the store is out of service and which records fail. Ask your partner to record the Drush commands, module versions and configuration in version control so the final run matches the last rehearsal. Drush commands differ between Drupal versions, so verify them against the release you are targeting.
Commerce Migrate for store data
Commerce Migrate maps Commerce 1 products, orders and customer profiles to the entities used by current Drupal Commerce. It is the only documented path for Commerce-specific data, so its compatibility decides how far the plan can go. Check its Drupal.org project page for Drupal 10 and Drupal 11 support and for the Commerce release it targets. Order history, line items and customer addresses need sample-based checks after each run, because a successful import can still change totals or attach orders to the wrong customer.
Migrate Plus and Migrate Tools for custom sources
Migrate Plus adds source plugins for CSV, JSON and XML, and Migrate Tools provides the commands for running, rolling back and re-running migrations. Use them for data outside the Commerce 1 schema, such as loyalty balances, wholesale price lists or supplier feeds, or for custom fields added to products. Plan rollbacks before the first live run, and keep incremental runs in the plan so orders placed during the build are captured. Confirm both modules' compatibility with the target Drupal version on their project pages.
Manual rebuild of gateways and shipping
Payment gateways, shipping methods, tax rules and their credentials are not moved by the migration paths above, so they are rebuilt on the new store. Each gateway needs its own configuration, secrets stored outside the database, and test transactions in the provider's sandbox before go-live. Shipping rates, zones and any tax logic must be recreated and checked against orders from the Commerce 1 store. Ask a partner to list every gateway and carrier in the scope document with an owner, so none is missed at cutover. No automated path rebuilds these settings for you.
Which orders and customers need checking before cutover
Order history, customer accounts, addresses and payment references carry the most business and legal risk in a Commerce 1 to current Commerce move, so they deserve the most checking before cutover. Start by recomputing order totals and tax lines on the new site against the Drupal 7 source for a sample of orders in every state and every tax zone, not just a spot check of recent orders. Compare line items, adjustments, shipping charges and tax amounts to the cent. Map each legacy order state to a state in the new order workflow on paper first, and decide what happens to orders that were in a pending, held or partially paid state, because those rarely map one to one and an incorrect mapping can trigger fulfilment or refund actions the business did not intend.
Customer records need their own checks. Confirm how customer login and password handling works after the move: whether existing password hashes are carried across or users must reset their passwords, and how that decision is communicated to customers. Look for duplicate customer records created when the same person checked out with different email addresses or with guest checkouts, and agree a merge rule before the import runs rather than after. Check currency and rounding on every monetary field, particularly where the legacy store stored prices in minor units or used per-line rounding that differs from the new calculation. Each of these checks should produce a written pass or fail record that the business owner signs off.
Stored payment tokens are the item most likely to be assumed to move and most likely to fail. Payment card data is not moved by a migration of this kind, and gateway tokens are only usable if the gateway provider agrees to transfer or re-associate them, so confirm the position with each gateway provider in writing and plan for customers to re-enter cards where that is the answer. Decide the PCI DSS scope of the new store with your security team before the cutover date, because the payment integration, the hosting and any retained legacy data determine which requirements apply. Ask the security team to confirm what legacy data stays in backups and for how long, and to agree who holds the evidence.
How the move runs from inventory to decommission
The sequence turns a Drupal 7 Commerce 1 store into a current Drupal Commerce site through inventory, a rehearsed pilot, parallel checking and a controlled cutover, with each stage closed by a documented check. It keeps the old store available until the agreed retention period ends.
Inventory Commerce 1 modules and data
Your team and DeployOpen list every contributed module, custom module, payment method, shipping rule, tax rule, product type, order state and customer field on the Drupal 7 store. The output is a written inventory that marks each item as migrating through Commerce Migrate, rebuilding by hand, or retiring. Each item needs an owner and a sign-off before the build starts, so nothing is discovered for the first time at cutover.
Choose target Drupal and Commerce versions
Decide the target Drupal core and Drupal Commerce release together, checking each against the Commerce Migrate module's compatibility notes at the time of the build. Drupal 10 reaches end of life on December 9, 2026, according to the Drupal core release schedule, so the team should confirm whether the target should be Drupal 11 with a planned follow-on upgrade. The output is a signed version decision record that names the PHP and database versions the hosting must provide.
Run a pilot migration on production copy
DeployOpen restores a recent copy of the production database and files into a non-production environment, then runs the Commerce Migrate migrations in dependency order: customers and users, products and variations, then orders. Each migration run is logged with its source and destination counts, and mismatches are recorded as defects. The step closes when a full pilot run completes with every migration reporting its expected counts and the rollback check has removed the migrated data cleanly.
Rebuild themes, payments and shipping
Drupal 7 themes cannot be migrated, so the storefront theme is rebuilt on the target version, and payment gateways, shipping methods and tax rules are configured again through their current contributed modules. Test transactions run against the gateway sandbox, and shipping and tax calculations are compared with the Commerce 1 results for a set of sample carts. The step closes when checkout completes end to end for every payment method and the sample carts match the legacy totals.
Reconcile orders and customers
Finance and support staff compare migrated orders, line items, totals, adjustments and customer records against the legacy store, using agreed sample sets and a full-count comparison of order totals by period. Mismatched records are classified as migration defects, data cleaning items or accepted exceptions with a written reason. The output is a reconciliation report that signs off order history and customer accounts, including login and password reset behavior for migrated users.
Run a parallel check against the same orders
For an agreed period, both stores receive the same test orders and the same account changes, and the outputs are compared: order numbers, totals, tax, shipping, payment status and emails. Differences are logged and fixed in the migration scripts or the rebuilt configuration, then the parallel run is repeated until results match. The step closes with a written parallel run report that the business owner accepts as the basis for cutover.
Cut over with a documented rollback plan
The cutover runbook sets the freeze window for the Commerce 1 store, the final incremental migration, DNS or routing changes, payment gateway webhook updates and post-cutover checks. The rollback plan states the conditions for reverting, the steps to restore the legacy site and the owner who makes that call. The step closes when the final migration run completes, the reconciliation checks pass on live data, and the rollback procedure has been rehearsed on the pilot environment.
Decommission the old site after retention
The Commerce 1 site stays read-only and available for the retention period agreed at the start of the project, so that order history queries and disputes can be checked against the original data. After that period, the team archives the database and file backups under the retention policy, removes public access and revokes credentials and gateway keys tied to the old store. The output is a decommission record that confirms the archive location, the deletion date and the access revocation.
What drives the cost and duration of a Commerce migration
This table compares the factors that move the effort of a Drupal 7 Commerce 1 move, and shows which ones are paid once and which keep costing money after launch. Use the last column to turn each driver into a specific item for a written scope and quote. The main takeaway is that product data, order history and payment and shipping rules usually set the effort more than the module count does.
| Driver | Why it changes cost or effort | What to ask for in a quote |
|---|---|---|
| Products and variations | Each product type, attribute set and variation needs mapping, and large catalogs need more validation passes before cutover. | Counts of product types, variations and images, plus the mapping approach for attributes and SKUs. |
| Order history volume and age | Older orders may use fields or statuses that need transformation, and the volume drives migration run time and checking effort. | Order count by year, the statuses in use, and the plan for historical versus open orders. |
| Customers and accounts | Duplicate accounts, merged emails and role differences need decisions before data moves. | How duplicates are matched, who signs off the rules, and whether passwords migrate or reset. |
| Contributed modules and custom code | Each Commerce 1 contrib module or custom plugin needs a current equivalent, a rebuild or a decision to drop it. | A module inventory with a current equivalent or replacement noted for each item. |
| Payment gateways | Each gateway needs a current connector, test transactions and a stored-card or token strategy, which may need provider cooperation. | Gateway list, token handling plan and the test scenarios the quote covers. |
| Shipping rules and tax | Rate tables, zones and tax rules are often rebuilt by hand because they do not migrate cleanly. | Count of shipping methods and zones, tax rules, and who verifies rates. |
| Multilingual or multi-currency | Translated products and several currencies multiply mapping, testing and display checks. | Languages, currencies, translated fields and the verification sample for each. |
| Theme rebuild scope | Drupal 7 themes cannot be migrated, so the storefront, checkout and account pages are rebuilt. | Number of templates and checkout steps to rebuild, and the design sign-off process. |
| ERP or accounting integration | Order, stock and invoice feeds need new connectors and reconciliation against the source system. | Systems involved, data direction, and the reconciliation method for totals and stock. |
| Target Drupal version | Drupal 10 and 11 have different PHP and module requirements, and a later Drupal 11 upgrade is a separate piece of work. | The target version, PHP version, and whether the quote includes the later Drupal 11 upgrade. |
| Parallel-run cycles | Each trial migration and comparison pass adds testing time before the final cutover. | Number of trial runs, what each run checks, and the cutover window agreed in writing. |
| Recurring module and core updates | Contributed modules and Drupal releases keep changing after launch, so updates recur for the life of the store. | Whether an operations retainer covers updates, security patches and testing after go-live. |
What usually goes wrong in Commerce 1 migrations and how to prevent it
Commerce 1 migrations rarely fail in one dramatic place. They fail where money, identity and timing meet: totals that shift, customers who cannot sign in, and a platform that loses support while the project is still running. Each risk below has a prevention step that belongs in the plan before the build starts.
Order totals and tax drifting
Order totals, tax lines and adjustments can change when Commerce 1 data is mapped onto current Drupal Commerce order and tax models. A small rounding or tax-zone difference can repeat across thousands of historical orders and reports. Before cutover, compare totals, line-level tax and currency for a sample of orders across each product type and tax region, and agree which differences are acceptable before the run.
Customers unable to sign in
Account records may migrate, but password hashes, email addresses, roles and blocked status do not always carry over in the form the new site expects. Customers who cannot log in generate support volume on launch day. Test sign-in with migrated accounts from each role, confirm how password resets behave, and decide in advance how customers with unusual or missing credentials will be handled.
Payment tokens not transferring
Stored card references and recurring payment tokens belong to a payment gateway, not to the store database. They may not move with the customer data, and some gateways will not accept an export from another site. Confirm with each gateway whether tokens can be transferred and under what conditions. If they cannot, plan for customers to re-enter payment details and for the gateway work to be scoped separately.
Contributed module with no target
A Commerce 1 store often depends on contributed modules for shipping, tax, product types or checkout panes. Some have no current equivalent, or the equivalent covers only part of the behavior. Inventory every enabled contributed module and custom hook early, mark each one as replaced, rebuilt or dropped, and get business sign-off on dropped features before development starts rather than during UAT.
Drupal 10 end of life forcing a rushed cutover
Drupal 10 reaches end of life on December 9, 2026, according to the Drupal core release schedule, and Drupal 12 is scheduled for the week of December 7, 2026. A migration that starts late can end up being cut over close to that date, leaving little room for parallel testing or rollback. Set the target version first, then work backward from the end-of-life date to set your own milestones with slack built in.
Staying on Drupal 7 without support
Drupal 7 security support ended on January 5, 2025. Sites that cannot migrate yet can look at certified extended security support providers listed by the Drupal Association, but that is a paid stopgap, not a migration. Whether to pay for extended support while the project runs is a business decision that must be made with the buyer, with the cost, the period covered and the risk of staying on an end-of-life platform written down.
Questions teams ask before a Commerce 1 migration
How much does a Drupal Commerce 1 migration cost?
The cost depends on the scope agreed in writing, so no figure can be given before that scope exists. The main drivers are the number of products, variations, orders and customer records, how many payment gateways, shipping methods and tax rules must be rebuilt, how many custom checkout or pricing rules exist, and how much of the existing data needs manual checking. Some work is fixed, such as the discovery review and the migration plan. Other work is variable, such as custom module rewrites and the number of test cycles. Ask for a quote that separates one-time migration work from any recurring support or hosting costs, and ask which items are priced per unit and which are priced as a block.
How long does a Commerce 1 migration take?
Duration is set mainly by the amount of custom code, the volume and state of order history, and how many integrations must be rebuilt. A store with standard product types and a single payment gateway usually takes less time than one with custom checkout panes, multi-currency pricing and an ERP feed. Other timing factors include how quickly the business can review sample data, how many rounds of user acceptance testing are planned, and whether a freeze window is needed for the final data load. Ask for a timeline that shows each review point and the dependencies on your team, rather than a single end date.
Can our in-house team run a Commerce 1 migration?
An in-house team can run the migration if it has Drupal 7 and current Drupal developers, someone who understands the store's product and order data, and time to test thoroughly. The hardest parts are usually not the module setup but the data decisions: which historical orders to carry over, how to map Commerce 1 line items and adjustments onto current order types, and how to verify totals and tax. Teams often underestimate the effort needed to rebuild payment and shipping integrations and to test them against live gateways. A partner can take on any part of this work, and the split should be written into the scope.
What does the migration need from the business team?
The business team owns the decisions the code cannot make. They need to confirm which products, customers and orders must move, which can be archived, and which fields are still used. They also need to approve field mappings for tax, currency and discounts, sign off on sample records in each test cycle, and name the people who will check order totals, refunds and customer accounts after launch. Expect to provide access to the current gateway and shipping accounts, a list of reports the team relies on, and a named decision-maker who can accept or reject changes quickly during testing.
Is the Drupal 11 upgrade part of the same project?
It can be, but it is a separate decision that should be made explicitly in the written scope. Drupal 6 and 7 sites cannot be updated in place to Drupal 10 or later. They are migrated into a new site, and themes must be rebuilt. Drupal 10 reaches end of life on December 9, 2026, and Drupal 11 is the current major version, so a new Commerce build may target Drupal 11 directly if the contributed modules support it. Confirm the module compatibility of each Commerce component on the target version before work starts, and ask whether the scope includes a later upgrade path. Drupal 7 security support ended on January 5, 2025, which makes timing relevant to this decision.
Can orders be migrated without downtime?
Usually not completely, because the final load of orders, customers and payments must be taken from a frozen source. The practical approach is to run one or more trial migrations on copies of the data, then schedule a short cutover window for the last incremental run, the DNS or routing change and verification of the new store. Downtime depends on data volume, the number of order records that change during the window, and whether the gateway can be reconnected quickly. Ask for a cutover plan that names the freeze point, the rollback steps and who approves go-live, and confirm how orders placed on the old site during the window will be handled.
How DeployOpen scopes, delivers and supports a Commerce migration
DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Drupal Commerce 1 to current Commerce migration, we start from a written scope that names the store data, payment and shipping paths, and checks you need before any build begins.
How we scope
- Inventory the Drupal 7 Commerce 1 store, its enabled contributed modules and the products, orders and customers in scope.
- Agree in writing which order history, payment and shipping rebuilds, and customer data checks the migration covers.
- Confirm the target Drupal and Drupal Commerce versions, PHP version and hosting before any build starts.
How we build
- Build the migration with the core Migrate API and the Commerce Migrate module, documenting each mapping decision.
- Rebuild payment gateways, tax and shipping configuration by hand where the migration path does not carry them over.
- Run repeated trial migrations into a staging copy and reconcile order totals, customer records and product variations.
How we hand over
- Deliver the migration scripts, field mapping documentation and a record of each trial run and its reconciliation results.
- Provide a rollback procedure and test it against the staging store before cutover is planned.
- Walk your team through the new store's configuration, order workflows and the list of items that still need manual checks.
How we support
- Support the store after go-live under a retainer if you want ongoing help with updates, backups and monitoring.
- Plan the follow-on Drupal 11 upgrade as a separate written scope so your team can budget and schedule it.
- Confirm with your own team and the Drupal.org project pages which module versions your store will depend on.
