Ubercart to Drupal Commerce migration

What moving from Ubercart to Drupal Commerce involves

An Ubercart store on Drupal 6 or 7 cannot be upgraded in place. It has to be rebuilt as a new Drupal Commerce site and the data carried across. Catalog and customer data can move through the Commerce Migrate Ubercart sub-module, which is part of the Commerce Migrate project on Drupal.org. Products, orders and customers are the parts of the store that the module is designed to bring across, so they are the starting point for the migration plan. Payment gateways, shipping methods, tax rules and order history are different. They depend on how the store was configured and on the integrations behind it, so they need to be rebuilt and checked by hand rather than assumed to carry over.

The effort depends mostly on how much of the store sits outside the default catalog. A store with a small catalog, one payment gateway and standard shipping is a far simpler project than one with custom product attributes, several payment processors, tax calculated by an external service, or a warehouse or accounting feed. Ask any partner to inventory each Ubercart module in use, each payment and shipping method, and each external system that reads or writes orders. That inventory is what turns a qualitative complexity judgment into a written scope and quote.

Before committing, confirm three things with your own team. First, which Commerce Migrate Ubercart version matches your source Drupal version and target Commerce release, since the module's compatibility should be checked against its project page. Second, which order history must stay visible to customers and staff, and in what form. Third, who signs off that a sample of migrated orders, balances and customer accounts matches the source system. Those checks are the most common places where a store launches with gaps, so they should be written into the acceptance criteria from the start.

Which Ubercart features map cleanly to Drupal Commerce

This table compares common Ubercart features with their Drupal Commerce equivalents and marks each as mapping cleanly, needing data transformation, or requiring a manual rebuild. Use it to scope the migration, then confirm the exact coverage of each item against the Commerce Migrate Ubercart module in a test run before you commit to a plan.

Ubercart feature	Drupal Commerce equivalent	Migration status
Products and product nodes	Commerce product types and product variations	Maps with transformation: product nodes must be split into products and variations, so confirm the field mapping
Product attributes and options	Product attributes and attribute values on variations	Needs transformation: attribute sets must be restructured and checked against each variation
Orders and order line items	Commerce orders and order items	Maps with transformation: order totals and line items should be verified against source records
Order statuses	Order states and workflows	Rebuild by hand: status names and transitions usually need a deliberate mapping to Commerce workflows
Customers and user accounts	Customer profiles linked to Drupal users	Maps with transformation: confirm how accounts and profiles are linked and how duplicates are handled
Addresses	Commerce address fields on profiles	Needs transformation: country, state and format values often need normalizing
Coupons and discounts	Commerce promotions and coupons	Rebuild by hand: discount rules rarely map one to one and should be recreated and tested
Taxes	Commerce tax types, rates and zones	Rebuild by hand: tax configuration must be rebuilt and checked against your jurisdictions
Payment methods and gateways	Commerce payment gateways and payment methods	Rebuild by hand: gateway accounts and stored payment data cannot simply be copied, so confirm with the gateway
Shipping quotes and methods	Commerce shipping methods and rates	Rebuild by hand: rate logic and carrier integrations must be designed again and tested
Custom order fields	Custom fields on Commerce order entities	Needs transformation: each custom field requires an explicit mapping and a decision on whether it is kept

Documented import paths and what each one covers

The documented route for Ubercart store data is the Commerce Migrate Ubercart sub-module, which belongs to the Commerce Migrate project on Drupal.org. It is designed to bring Ubercart store data into Drupal Commerce, so it is the starting point for products, orders and customers. It does not rebuild the commerce logic around that data, so payment gateways, shipping methods, tax rules and checkout behavior still need separate design work.

Products: Confirm which product types, variations, attributes and images the sub-module maps, and which ones you will recreate by hand.
Orders: Check how order states, line items, adjustments and totals arrive, since order history is the part most often reviewed by finance teams.
Customers: Confirm how Ubercart user accounts, addresses and roles map to Drupal users and Commerce customer profiles.
Payment and shipping configuration: Expect these to be rebuilt in Commerce rather than moved as settings.
Versions: Confirm the module release, the Drupal Commerce version and the source Ubercart version on Drupal.org before planning.

Ask the team that will run the migration to show you a sample of migrated orders and customers from a copy of your database, and to list every field the mapping leaves out.

How the migration runs from inventory to decommission

The sequence moves Ubercart stores into Drupal Commerce in controlled stages, so each stage ends with a check that the store, its orders and its money flows match the source before the next stage starts. The old site is switched off only after order history has been verified.

Inventory the store before any data moves
Your team and the DeployOpen engineers list everything the Ubercart site does: product types and attributes, order statuses, customer accounts, tax rules, payment gateways, shipping methods, coupons, and any custom modules or template overrides. The output is a written inventory that marks each item as migrated by Commerce Migrate Ubercart, rebuilt by hand, or retired. Ask for this inventory as a deliverable in any quote, because it defines the scope that everything after it depends on.
Map Ubercart data to Commerce entities
Engineers document how each Ubercart object becomes a Drupal Commerce product, product variation, order, order item, profile or user, and flag any field that has no direct equivalent. Custom Ubercart modules are reviewed for data they write to the database, since those tables are not covered by the standard migration. The check that closes this step is a signed-off mapping document that your business owners have reviewed for order and customer records.
Run a pilot migration on a production copy
The team restores a copy of the production Ubercart database and Drupal files into a non-production environment and runs the Commerce Migrate Ubercart migrations end to end. Engineers record row counts, failed rows and the reasons for each failure. The pilot is complete when the failure list is understood and each remaining exception has a documented fix or a documented manual step.
Rebuild payment gateways and shipping rules
Payment gateways, shipping methods and tax rules are configured again in Drupal Commerce, because the migration does not carry over live credentials or equivalent logic. Your payment provider confirms test transactions, refunds and webhooks in a sandbox, and your team confirms rate tables and zones against real orders. The step closes when each payment and shipping path has been tested with a transaction that a finance reviewer has signed off.
Reconcile orders in a parallel run
The new store runs in a staging environment alongside the live Ubercart site while the same test orders are placed on both. Totals, taxes, shipping charges, order states and customer records are compared line by line, and differences are logged against the inventory. The parallel run is complete when every difference is either corrected or accepted in writing by the business owner.
Cut over during a freeze window
Your team announces a freeze window in which the Ubercart site stops accepting orders and changes. A final migration runs from the frozen database, DNS or routing moves to Drupal Commerce, and engineers check order counts, customer logins and payment callbacks against the pre-freeze figures. The window closes when the new store accepts a live test order and the reconciliation totals match the freeze snapshot.
Verify order history after launch
After cutover, your support and finance teams sample historical orders, refunds, customer accounts and invoices in the new store and compare them with the archived Ubercart data. The old database and files are kept read-only for the agreed retention period. The check that closes this stage is a written order history report that your owners have accepted.
Decommission the Ubercart site
Once order history checks pass, the Ubercart site is taken offline, its credentials and payment keys are revoked, and a final backup is archived under your retention policy. DeployOpen documents what was retired and where the archive is stored, so that auditors and future staff can find historical records. Decommissioning is complete when the old hosting is removed and the archive has been restored successfully at least once.

Rebuilding payments, shipping and tax

Gateway credentials, tokenized card references, shipping methods, rate logic and tax rules are not portable data. Plan to configure each of them on the Drupal Commerce side and test them there before cutover. Ubercart payment gateway settings, stored card tokens and shipping quote rules belong to the Ubercart installation and its gateway accounts, so the new store needs its own payment gateway configurations, shipping methods and tax rules set up with the payment provider's current requirements. Treat the old order records as history: they show what was charged and shipped, but they do not give the new store the ability to charge, quote or calculate tax. Confirm with your payment provider whether any saved card references can be moved at all, and if not, which customers must re-enter payment details.

Before cutover, bring in your payment provider and the owner of your PCI DSS scope. The scope owner needs to know which components will handle cardholder data in the new store, whether the Commerce payment flow uses hosted fields or redirects, and where any stored references are kept. This decision drives the control evidence you will need, so settle it before the build is locked rather than after go-live. Ask the provider to confirm sandbox credentials, webhook endpoints and the production cutover steps in writing, and make sure the old Ubercart gateway is disabled once the new one is live.

Test refunds and failed payments in staging before any real order flows through. Run declined cards, timeouts, partial captures, full and partial refunds, and a payment that succeeds at the gateway but fails to write back to the order. Check that each outcome updates the order balance, payment status and any notifications correctly. Also run shipping quotes and tax calculations against a sample of migrated orders with known outcomes, and compare the totals with the figures recorded in Ubercart. Any mismatch is a rule to fix on the Commerce side, not a reason to edit historical orders.

How to check order history after the move

Order history is the part of an Ubercart store that customers, finance teams and auditors rely on most, so it needs its own verification pass after the migration runs. The checks below compare the old and new stores from several angles, because a count that matches can still hide wrong totals, missing adjustments or orders that no longer belong to the right customer.

Order counts and totals by period

Compare the number of orders and the summed order totals for each month or quarter between the Ubercart source and the new Drupal Commerce site. Run the same date ranges against both databases before the final import and again after cutover. Differences usually point to skipped orders, currency or rounding changes, or tax being counted differently. The finance lead should sign off on each closed period, and any gap should be explained in writing before the old store is retired.

Line items and adjustments

Check that each order keeps its product lines, quantities, unit prices and discounts, and that taxes, shipping charges and manual adjustments appear as the same amounts. Ubercart stores these as separate order components, so confirm that each one has a counterpart in Drupal Commerce rather than being folded into a single figure. Sample a set of complex orders with coupons, bundles or partial refunds. The store owner and the developer who wrote the mapping should both review the sample.

Customer account linkage

Confirm that every migrated order is attached to the correct customer account, including guest checkouts that never created a login. Check that email addresses, billing and shipping profiles and any duplicate accounts resolved as expected. A wrong link can expose one customer's history to another, so treat this check as a privacy control and not only a data quality task. The customer support lead should sign off after reviewing a sample of repeat buyers and guest orders.

Order states and payment records

Compare each order's workflow state, such as pending, completed or canceled, with the source status. Verify that payment transactions, card references and refund records were carried over or deliberately archived, since payment gateways often cannot be re-run against historical data. Record which payment history lives in the new store and which stays in the gateway or an archive. The payments owner and the finance lead should approve the state mapping before go-live.

Invoices and receipts

Regenerate a set of invoices or receipts from the new site and compare them with the originals that customers received. Check the order number format, dates, tax lines, store name and currency symbols, because customers and accountants will notice changes to these first. Confirm which documents must be kept as legal records and where the originals will be stored. The finance lead and the business owner should sign off on the sample before the old store is switched off.

What drives cost and duration in an Ubercart move

This table lists the factors that change the effort of moving an Ubercart store to Drupal Commerce, whether each one is paid once or keeps recurring, and what to request in a written scope. Read it before asking for a quote, because the same store can vary widely depending on these inputs.

Driver	Why it changes effort	One-time or recurring	What to ask for in the written scope
Product count and attributes	Each product, variation and attribute set must be mapped, checked and sometimes reshaped into Commerce product types and variations.	One-time	Product and variation counts by type, attribute inventory, and the mapping approach for each attribute set.
Order volume and history depth	More orders and older history extend migration runs, reconciliation checks and spot reviews of order totals and states.	One-time	Order count by year, the date range to migrate, and whether historical orders are archived or imported.
Customer records and accounts	Customer and address data need deduplication, matching to Commerce customer profiles and privacy review before import.	One-time	Customer count, account linkage rules, and who approves the data cleanup decisions.
Custom Ubercart modules and hooks	Site-specific code, custom order workflows and altered checkout logic have no direct equivalent and must be rewritten for Commerce.	One-time, with ongoing maintenance of any custom code kept	Inventory of custom modules, the behavior each one provides, and which features must be kept at launch.
Payment gateways	Each gateway needs a Commerce payment gateway configured, tested in sandbox mode and confirmed against stored payment references.	One-time setup, recurring gateway fees and maintenance set by the provider	List of gateways in use, transaction types needed, and whether stored card tokens or recurring billing must move.
Shipping methods and rules	Rates, zones and carrier connections are rebuilt on Commerce shipping and must be tested against real order examples.	One-time, with recurring rate and carrier updates	Shipping methods, zones, carrier integrations and rules that depend on product or customer data.
Multisite or multilingual setup	Each site, store or language adds mapping, translated product data and separate checks of URLs and pricing.	One-time, plus ongoing content work per language	Number of sites or stores, languages in use, and whether translations migrate or are re-entered.
ERP or accounting integration	Orders, tax and inventory feeds to an ERP or accounting system must be re-pointed and reconciled against migrated history.	One-time build, recurring sync monitoring	Target systems, data fields exchanged, sync frequency, and the reconciliation method agreed before cutover.
Theme rebuild	Ubercart themes do not migrate, so templates for product, cart, checkout and order pages are rebuilt for the new site.	One-time, with recurring design changes	Number of page templates, design approval steps, and whether checkout must match an existing brand style exactly.
Order history checks	Test cases for order totals, statuses, taxes and refunds must be written and signed off before cutover.	One-time	Sample size for checks, the test cases to cover, and who signs off on the results.

What usually goes wrong and how to prevent it

Ubercart to Drupal Commerce projects tend to fail at the edges: custom code nobody inventoried, data that exists in one system but not the other, and money-related behavior that only shows up under real transactions. Each card below names one failure point, why it matters for this migration, and the check that catches it before cutover.

Missed custom Ubercart hooks

Many Ubercart stores carry custom modules that alter checkout, product display, order totals or emails through Ubercart hooks. Commerce Migrate Ubercart moves the standard data, but it cannot reproduce behavior your own code added. Inventory every custom module and every hook it implements, then assign each one a Commerce equivalent, a rebuild item or a documented retirement decision. Ask for the inventory before estimating the build.

Order history gaps

Orders, line items, adjustments and status changes can land in the new store with missing fields or flattened history, which breaks customer service lookups and reconciliation. Compare record counts by status and date range between the old database and the new store, then sample individual orders across every status your store used. Confirm which historical fields are carried over and which are only kept as read-only reference.

Payment tokens that do not transfer

Saved card references are bound to the payment gateway and the merchant account that created them, so they usually cannot move to a new gateway integration. Customers with saved cards will need to re-enter payment details, or you will need a gateway-supported token migration agreed in advance with the processor. Confirm this with your gateway before cutover and plan the customer message and the subscription impact.

Tax and shipping drift

Rates, zones, tax rules and shipping methods are often rebuilt by hand, and small differences change totals at checkout even when the product data is correct. Build a test matrix of addresses, quantities and shipping methods, then compare the old and new totals line by line. Pay particular attention to rounding, tax-inclusive pricing and any rule that Ubercart handled through custom code.

Untested refunds and returns

Refund and return flows are the paths least often exercised before launch, yet they touch payment, inventory and accounting at once. Test full and partial refunds on migrated orders, including orders placed under the old gateway, and confirm that the reversal reaches the processor and the ledger. Record the expected outcome for each case so that finance can sign off on the results.

SEO loss from changed URLs

Product and category paths in Ubercart often differ from the URL patterns Drupal Commerce generates, and old links from search results and external sites will then return errors. Export every indexed product and category URL, define a mapping to the new paths, and implement permanent redirects before go-live. Track crawl errors for several weeks after cutover so that missed paths surface quickly.

Staff working in two systems

During a parallel run, support staff may look up an order in Ubercart while a customer has already placed an order in Drupal Commerce, and inventory or pricing edits can be made in only one place. Set a written rule for which system is authoritative for each object, define a freeze window for product and price changes, and name an owner who signs off on the cutover date. Agree on how refunds and support notes are recorded during the overlap.

Questions buyers ask before moving Ubercart to Drupal Commerce

What drives the cost of an Ubercart to Drupal Commerce migration?

The cost follows the amount of store data to move and how much of the store must be rebuilt by hand, not the migration module alone. The main cost drivers are the number of products, product attributes and variations, the volume of order history you need to keep, how many customers and addresses carry over, and how many payment gateways, shipping methods, tax rules and custom Ubercart modules must be recreated in Drupal Commerce. Commerce Migrate includes a Commerce Migrate Ubercart sub-module, which covers the data mapping work, but payment and shipping rebuilds are separate pieces of work. Ask any partner for a fixed-scope quote with each component listed, including what is one-time (the build and the first full migration run) and what recurs (hosting, module updates and support if you buy a retainer).

Should we migrate before Drupal 7 security support ends?

Drupal 7 security support ended on January 5, 2025, according to Drupal.org, so a site still running Ubercart on Drupal 7 is already past its core security window. The Drupal Association's Extended Security Support Provider Program lists HeroDevs and Tag1 Consulting as certified vendors for sites that cannot migrate yet, and that route buys time at a recurring cost. Migration is the lasting fix, because Drupal 7 sites cannot simply be updated to current Drupal. Start planning now, since payment, shipping and order checks usually take longer than the data import itself. Ask your partner for a written timeline that names the stages and the points where your team must sign off.

What does our store team need to provide during the project?

The store team is the source of truth for business rules, so it needs to commit time before the build starts. Expect to provide access to the live Ubercart site and a recent database copy, a list of active payment gateways with their test and live credentials handled through your secrets process, shipping rules and carrier accounts, tax rules, product categories and customer groups, and sample orders for each unusual case. Someone with authority must decide which historical orders, customers and products are kept, archived or dropped. Without these decisions, developers will guess, and the guesses show up at checkout after launch. Confirm named owners for each area and how quickly they can answer questions.

Can our in-house team run this migration without a partner?

An in-house team can run it if it already has Drupal development experience, Drupal Commerce knowledge and time to test thoroughly. The Commerce Migrate module and the core Migrate API are documented on Drupal.org, and an engineer who has run Drupal migrations will recognize most of the process. The harder parts are rebuilding payment gateways and shipping calculations, reconciling order totals and verifying customer records against your obligations. Consider a partner if your team has not shipped a Drupal Commerce store, if your payment setup is unusual, or if you cannot free two people for the test cycles. A fixed-scope engagement can also cover only the parts you choose to hand over, such as the payment rebuild or the verification checks.

Can we keep taking orders on the Ubercart store during the move?

Yes, but only if the plan includes a cutover window and a delta sync, because orders placed after the first copy will not exist on the new site. A common approach is to run a full migration into a staging site, repeat the test runs until results are stable, then freeze checkout briefly on the old store, run an incremental import of orders and customers created since the last pass, and switch DNS or the storefront. Keep the old Ubercart site read-only for a defined period so staff can look up anything missing. Confirm with your partner how the incremental run is tested and how long checkout must be paused, because that window depends on your order volume and payment setup.

How do we verify that migrated order history is correct?

Verify with counts, totals and sampled records, and sign off against your own accounting reports. Compare the number of products, customers and orders on both sites, then reconcile order totals, tax, shipping and discounts for a date range your finance team chooses. Check order states, payment records and refunds, because a status that maps incorrectly can change how a customer's history reads. Sample individual orders, including ones with multiple shipments, returns, cancelled items and unusual addresses. Keep the migration logs and the mapping document so issues can be traced and fixed in a repeat run. Ask your partner to define these checks in writing before the first import, so acceptance criteria are agreed rather than argued after launch.

What about payments and shipping that must be rebuilt?

Payment gateways and shipping methods are rebuilt on Drupal Commerce with contributed modules, not carried over automatically, so each one needs its own test plan. Confirm that a payment provider has a maintained Drupal Commerce integration, check how stored card tokens or subscriptions will be handled, and confirm your card data scope with your payment provider and assessor before testing. For shipping, list every rate rule, carrier and package rule, then test each with real addresses. Because these components change how money moves, treat them as separate sign-offs rather than part of the data import. Ask for the rebuild to be quoted as its own line item.

What should we check on the Drupal core version and PHP before starting?

Confirm your current Drupal version and your target Drupal Commerce stack, because the migration path and module compatibility depend on both. Drupal 10 requires PHP 8.1 or later, Drupal 11 requires PHP 8.3 or later and no supported Drupal version runs on PHP 7, so older hosting will need an upgrade first. Drupal runs on Apache, Nginx and other web servers, with MariaDB, MySQL, PostgreSQL or SQLite as the database, so confirm your target hosting stack. Also check the Commerce Migrate module's current compatibility notes on Drupal.org before choosing a target version, since they set which upgrade steps follow.

What the team must provide and what they receive

The migration depends on what the client supplies in the first weeks, so the database access for a working copy comes first. The team needs a restored copy of the Ubercart database from the Drupal 6 or 7 site, along with the file system, so product images, order attachments and any files referenced by Ubercart fields can be checked. Also provide the payment gateway and shipping method configuration as it stands in production (which gateways are active, which shipping quote methods and rate tables are in use, and which tax rules apply), plus any custom modules or theme code that touch carts, checkout panes or order status. Name a business owner for order statuses, refund practice, tax treatment and customer account rules. Their decisions set the mapping, and they should not be left to the developers. Confirm early who signs off each stage: the store owner for product and customer data, finance for order totals and tax, and the operations lead for fulfillment states.

In return, the client receives a written inventory of the source store, covering products, product attributes, orders, line items, customers, payment records, shipping data and custom code, with each item marked as migrated, rebuilt or retired. The mapping document records how each Ubercart object and field maps to its Drupal Commerce entity, which is the main reference when a reviewer asks why a field moved where it did. Reconciliation reports compare record counts, order totals and tax amounts between the source and target before and after each trial run. A runbook sets out the cutover steps, rollback point and post-launch checks. Where possible, the work is agreed in a fixed scope document before it starts, with deliverables, acceptance tests and any items excluded (such as custom checkout code that will not be carried over). Ask for these documents to be named in the written scope so acceptance is measured against them.

How DeployOpen scopes and delivers an Ubercart to Commerce migration

DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens and supports self-hosted open-source platforms inside the client's own infrastructure. For an Ubercart to Drupal Commerce migration, we start with a written scope that maps your products, orders, customers, payments and shipping before any code is written.

How we scope

Inventory the Ubercart version, enabled modules, product types and order statuses in use today.
Agree in writing which products, orders, customers and order history records move across.
Identify payment gateways and shipping methods that must be rebuilt on Drupal Commerce.
Confirm the target Drupal Commerce and Drupal core versions, and where the new site will be hosted.

How we build

Run Commerce Migrate Ubercart in a staging environment against a copy of the production database.
Rebuild payment and shipping configuration by hand, then test each gateway with sandbox transactions.
Map order history, line items, tax and addresses, and check totals against the source system.
Record every mapping decision and rerun migrations until results match the agreed scope.

How we hand over

Deliver a written runbook covering the migration steps, rollback procedure and known gaps.
Provide reconciliation reports comparing order counts, totals and customer records before and after cutover.
Document payment, shipping and tax configuration so your team can maintain it without us.
Walk your operations and finance staff through order history checks and open issues before go-live.

How we support

Offer post-launch support for order and payment issues during the stabilization period, scoped in writing.
Make ongoing support, upgrades and continuous testing available as a retainer after handover.
Plan the path to later Drupal Commerce and Drupal core releases as part of the handover documentation.
Confirm support terms, response expectations and access requirements in the written scope before work begins.