Migrating from Drupal Commerce 1.x to Drupal Commerce 2.0

Drupal Commerce 2.0 has finally reached 2.0 status with an official stable release on September 20, 2017! Sound the horns! More Cowbell!

Naturally, our clients are starting to think about migrating Drupal 7 Commerce 1.x to the new Drupal 8 Commerce 2.0 platform, this article is an effort to help you decide if migration is right for you, and how to approach the tasks at hand.

Not to brag (ok, we are bragging), but we have some incredible insight into the process of migration because two of our very own are core migration module maintainers (quietone & heddn). I reached out to these two when putting together this article.

Do you need to migrate?

The quick answer is not yet, but you should be starting to think about it. You don’t need to migrate, but you will want to. Check out a few reasons why you’ll be begging to make the leap:

Drupal 7 and Commerce 1 will only be supported for so long now that new versions of both are out. The end-of-life dates haven’t yet been set, but that doesn’t mean you shouldn’t start to prepare for the inevitable.
End-of-life means that the worldwide network of Drupal developers will pivot their energy away from D7/DC1 and focus their skills, efforts, engineering and security practices on the new and shiny version of the platform. That means that if you want all of the good (and free) Drupal juice, you need to hop over to D8 and DC2 to reap the rewards.
Drupal Commerce 2 introduces a better update path. What does that mean? It means that new features will be introduced into the core through micro-updates, major migrations will be a thing of the past. Yup, you read that right - This is the last full migration you’ll ever need to make.
Features, oh the new features. All yours! From tax integration, multi-language support, currency setups, shipping, fulfillment, APIs left and right, oh the list goes on and on. You get the bells AND the whistles, and they will just keep coming as new updates roll out without any effort or expense on your part. Migration can be mighty sexy.

When the inevitable does happen and the masses are using the new version of the platform, Drupal 7 and Commerce 1 will be laid to rest by the community. There will most likely be a big scramble from those who haven’t already planned for the future. Being ahead of that curve could be advantageous, not to mention opportunistic and allow for your company and eCommerce store to have a voice in driving the roadmap of Commerce 2.

What can you expect from migrating?

You’re thinking back to the initial build, configuration and custom module development of your D7/Commerce 1 site, and you’re thinking, how in the sweet blue sky can we possibly migrate this glorious unicorn over to D8 and Commerce 2 without going through all of that planning, pain and expense again?

We hear you. Any migration does require some technical expertise to complete successfully, but any competent development team should be able to pull it off. Shying away from an absolutely necessary business upgrade is not the answer.

Ecommerce migrations have two parts

Moving from Drupal 7 to Drupal 8 (think of your core moving up a notch, themes, templates and CMS are all getting pimped out). This does require a “re-do” not just a port.
Migrating the commerce engine and all its parts and associated data to Commerce 2.0.

How long will a migration take?

That’s the first question we are asked. We’ve seen a pure content migration take as little as 50 hours for a very simple site. For more complex migrations, where we’re bringing in unique data from various sources, it could easily take 200+ hours for the migration alone, and the D8 framework and templating are in addition. Step one is to find out where you fall on the spectrum of difficulty and begin to parse out the to-do list accordingly before jumping into the undertaking.

Take migration as an opportunity to level up your online business; It’s an opportunity to come up with a fresh design that takes into account today’s technology, design and UX standards that shape the way users ultimately use your website. If you’re on D7 and Commerce 1, it’s time for that site evolution conversation to begin.

How does migration happen?

As mentioned earlier, migrating does require a number of technical steps. Time to get into some of the nerdy details: Here’s a general approach that we’ve been using successfully.

Get a source database dump from the existing Drupal 7 Commerce 1.x site. TIP: Potentially, get the site code too. It isn't strictly necessary, but helpful.
Install a vanilla Drupal 8 site with no content and only the modules enabled that you want to migrate into. Enable Commerce 2, the date module, pathauto, Google Analytics, etc. TIP: Don't bother adding any content or configuring this site; You’ll end up losing all of the configurations after the migration.
Using Drush, create all my migration configurations and export the configuration to YAML files. TIP: We use Drush because the migration modules GUI is very simplistic and doesn't allow for any site re-architecture.
If we need to collapse node types, combine product types, use media on D8, etc., it makes more sense to migrate the content directly from Drupal 7 into the new structure. However, this is only possible with a custom migration where we build the configuration, export the YAML files and start customizing and mapping to the new destinations.
Now we would apply this patch (by heddn) and run all the migrations. In the future, we might not need this patch, but at the time of writing, we do. This lets us see what migration errors exist and how much more work we have to do. If there are errors on this first migration, and they're always are, we fix the errors and run the migration again. TIP: At this point, we’re only focusing on migrating configuration, not content. Getting the configuration migration solid is the first milestone and usually doesn't take that many hours.
Next is content migration. This is where we have lots of fun combining content types and moving all the files into shiny new media entities, etc. We won't re-run the config migration at this point, so if we need to start tweaking the config on the site, flipping knobs and switches, we can do that now.
The majority of the migration effort is spent making sure all content is migratable. Things that are notoriously hard are field collection/paragraphs, multi-lingual sites and media, video, audio or file fields. TIP: Look out for the odd line-item fees or product classes that take some extra work.
Basically, anything that seems dirty, ugly, hacky, and wasn't in core in Drupal 7 or Commerce 1 is going to take some time to migrate cleanly. Make a list, check it twice.
At this point, we can set up a staging environment and compare the new site on Drupal 8 to the previous Drupal 7 site. If this is for a client, they can oftentimes become involved at this stage. We’re looking for missing content fields, malformed dates, missing files and anything else that seems amiss. We haven't run our final migration yet, just trying to gauge how close we are. We'll run the actual final migration later on.
Now, or maybe a little earlier after we've landed on a stable Drupal 8 site configuration, we can also start doing other site-building and theming work. We cannot place blocks or be certain about what node or product ids are going to be since we haven't run the final migration. But we can use Recreate Block Content module and hope for the best.
We’re getting very close now. Theming is now complete and we should have creative and client signoff of the site's appearance. We should now have a solid migration process and be able to schedule a go-live date.
On, or as close to go-live as possible, we can start migrating files and data. For files, We like to rsync all the Drupal 7 files to the Drupal 8 destination beforehand. File migrations are quite slow, but rsyncing is much faster. For the remaining data, depending on its size, the final migration can take anywhere from minutes to several hours. Sometimes we can jump-start the migration a little by running it a day or two in advance, but know that any new content or users created in those couple of days will disappear once we take the new site live. The exact timing of the migration really depends on the site. TIP: Have a rollback available in case you need to take a second crack at this.
After some final testing, backups, and other launch tasks, we can flick the switch and take the new Drupal 8 Commerce 2.0 site live! Break out the champagne and celebrate!

What if there are problems after launch?

This is an important question. If we’ve all done our jobs correctly, with prudent testing, then there really shouldn’t be any (or many) problems after launch.

However, with large migrations, there are so many variables at play. It would be unrealistic and unwise to think that there won’t be any bugs; they may not be launch-stopping but they will need attention and clean up nonetheless. Internal development teams and external service providers should all have systems in place to deal with potential issues; it’s all hands on deck to test and report on the new setup's success and issues.

How do we handle this step? Acro Commerce does this by providing a bug warranty for 90 days whereas we will fix any bug that arises within this initial timeframe, free of charge. We also offer various service level agreements (SLAs) for additional, ongoing support.

In conclusion

We hope that this article provides some insight into what’s involved with migrating your Drupal 7 Commerce 1 site to Drupal 8 Commerce 2, and gets the conversation started for your business. It sounds like a big job because it is - but it’s totally worth it. Not only will you end up with the latest and greatest in Drupal and Drupal Commerce, but you’ll now be set up for proper eCommerce into the future. New revenue streams, new marketing directions, or just the “same ol’ thing” but faster and with a new coat of paint, the direction is yours to take.

Of course, if you'd like a hand we're always here to help.