Commerce Migrate Ubercart is a migration using Commerce Migrate and the Migrate suite that can migrate 6.x and 7.x Ubercart stores from either the existing Drupal database or an external database on the same machine.

Visit admin/content/migrate/ubercart_migration_options to configure import options, including the source database and filesystem locations.

Please read the README.txt for the 7.x-2.x branch and all the details on this page. There are specific requirements for setup before a migration.

Do NOT follow the 7.x-1.x instructions, they are no longer valid.

What currently works:

  • The migration will ask you to create any missing product_types in the D7 system.
  • Each product type gets its own migration. Duplicate SKUs will get _2 and _3 (automatic de-duping).
  • Each product type gets its own node migration, which creates the matching product_display nodes. NIDs are preserved by default (duplication errors if you re-used nid 5 for example).
  • Customer billing profiles are created from the billing info of each Ubercart order. If you have a user migration (perhaps defined in the migrate_d2d wizard) you can maintain the user reference in each order.
  • Orders (and line items) come through. Line items maintain their references to the products so they will appear in Views-based reports.
  • Taxes and shipping are now in the dev branch as of 2014-06-06.
  • Payments are now in the dev branch as of 2014-06-06.

What doesn't work yet:

  • Attributes - patches welcome. You can copy the file as a starting point and then register the new file in and the info file.
  • There are a number of things that will never be able to be addressed, as with all migrations. Every migration will require review and work on the migrated store.

The new 7.x-2.x branch - making use of migrate_d2d

A new 7.x-2.x branch has started in #1832736: Class registration for Migrate 2.5 or later to work with the new version of migrate and migrate_d2d modules. It is specifically coded to use migrate 2.6+ and migrate_d2d 2.1+, however you can probably run with migrate 2.5 and migrate_d2d 2.0 without issue, but you will lack all of the UI for fields. Older versions are not supported in this branch and should be completely uninstalled before proceeding.

The new branch is a significant overhaul that takes advantage of the migrate_ui and migrate_d2d packages. This allows you to go to the commerce_migrate_ubercart migrations in the UI and click "edit" to map fields that are not provided by this module out-of-the-box. It is probably a good idea to use migrate_d2d's "wizard" to create user and files migrations that run first, and then can be referenced as a "source migration" for the fields you add to preserve mappings to the old content as often these get new uid/fid/nids in the new system.

There is an option in the commerce_migrate_ubercart page to put the machine name of your user migration if you want the previous purchases to link to the user's account.


There are a few weird things about installing that trip people up. These instructions will probably help you with any D7 migration module.

  • You must install migrate before commerce_migrate_ubercart. The installer needs migrate's hooks to be available. If you skipped this step, it is ok, just make sure you do all of these other steps and you will be back in order:
  • To make all the migration classes visible to commerce_migrate_ubercart you must clear the caches.
  • Once you have all of your classes visible to the module, you must go to the commerce_migrate_ubercart configure page and put in your settings. You will need a second database in your settings.php. If you want to map users, put the machine name of your user migration. Don't have one? Use migrate_d2d to create one.
  • When you are ready to begin click "register statically defined migrations" on migrate module's configuration page.
  • Go back to the main migrate page and click the name of the commerce_migrate_ubercart group. Run the migrations in order, one-by-one. Grouped migrations can sometimes get wonky if you run them all at once.
  • If you need to roll back, start from the last one and work your way up to avoid creating orphan content. Drupal needs complete entities to delete properly, and if part is missing it can be annoying to clear out all of your field tables related to the migration. If you do this by accident, just keep re-running, and when you get duplicate errors, rollback and then clear the table mentioned by the error. Even better if you just take a backup at the start and then you can easily go back without having to clear out any tables.


If you are upgrading from the 7.x-1.x series, be sure to at least re-save your configuration, or consider uninstalling it (and the old version of migrate) first.

Users of previous versions of the 7.x-2.x branch can simply go to the configuration page and click "register statically defined migrations" to get the new migrations, and run them to update your existing sites with the new migrations (payments, taxes, shipping in particular can be added without rolling back [obviously test this on a dev copy of your site first]).

Since 7.x-2.0-alpha3 product relationships are tied together much better. If you were having trouble getting your migrated data to show in views it will help to use the latest version.

Your experiences and needs are invited in the issue queue. You may need to provide a database for testing. There's no guarantee that every permutation can be addressed, of course.


Supporting organizations: 
Refactored 2.4 api to 2.5/2.6 api, added some migrations, support.

Project information