4 Data Migration Considerations for Ecommerce Replatforming

Paul Smith is a well-known fashion site on Magento 2

It’s nearly impossible to overstate this: a modern ecommerce site is a complex ecosystem. As you evaluate your site, you will not only look at the frontend where your customers view and experience your brand. You’ll also review your backend operations where multiple systems can integrate with your inventory, fulfillment, shipping, and more.

Given the complexity, it’s vital to remember that no site change is done in isolation. Retailers have to keep this idea top of mind, especially during ecommerce replatforming. As you transition from your old system to a new one, you’ll be gaining numerous benefits, including improved site load time and efficiency. (Just to name a few.)

But in order for merchants to reap the full benefits of replatforming, the transfer of data between the old and new systems has to be seamless. By this we mean product attributes and images, customer and order history data, as well as data behind things like gift cards, coupons, product ratings, and reviews. Here’s how we help clients think about data migration at Command C.

Consideration #1: What data do you want to bring over to your new site? How do you plan to structure that product data?

When data gets transferred, assumptions often get made. But this is not the time to assume anything. Yes, many platforms come with a tool to support data migration. But you have to determine whether or not the platform tool will support every aspect of your data needs.

For example, if you’ve been on your current platform for a long time, then your data has taken a specific form within that platform. Over time, you and your team have grown accustomed to viewing your data in that particular structure. Further, during the process of growing your company, you’ve probably created various workarounds so you can see the full data picture. Perhaps you added a tag for customers who purchased a certain amount last year. Or maybe there’s an operations flag on products that need to be ordered from a vendor 90 days in advance, rather than 30. It can be anything. But it’s probably specific – and important – to the way you run the business.

This kind of unique logic can get lost in data migration if there’s no plan for it. Therefore, at Command C, we make it a priority to help clients view their data as an outsider would view it. We ask questions like, “Why is your current data set up the way it is? What needs to come into the new system? What can you lose? And once your historic data is in the new platform, how will you read it in its entirety?”

The answers to these questions will shape our data migration strategy into the future.

Consideration #2: How are you going to use this information moving forward?

As you replatform, eliminating unneeded legacy data will speed up your new site. So while you want to maintain the continuity of things like product, customer, and order history, you can benefit by streamlining your data. But before you refine it, you need to define how you plan to use the data in the new site.

In the case of Shopify, for example, the platform organizes data by tags and metafields. As you continue to import new data, such as new customers, will you use tags or metafields for this updated information?

Then there’s the unique challenge of migrating order histories. They represent a specific moment in time. Over the course of your business, your prices, shipping methods, product models – you name it – have probably changed. How much of the order history information will you need?

It’s also important to know how the new platform handles order history, particularly when it comes to discontinued products and/or variants. Some platforms allow you to create an order history without having to re-create the previously sold product.

Other platforms, however, require you to create or import the discontinued product into the system before you’re able to import an order containing that product. If the discontinued product data is not there, the system will mark the order as an error and not import it. With this in mind, decisions about order history can add new factors into migrating product information.

The solution to these issues will vary among retailers. If you bring over all of your order history, it could add unnecessary load to your site and weigh it down. At the same time, your customers may want to access their past orders, and you’ll want to provide them. This will certainly be the case if your business model works from product replenishment orders, such as household supplies or pet food.

Again, the final answer will depend on your business, but keep in mind that you could land on a middle-ground solution. If you have a site where customers don’t frequently need to review their order history, you may not need to migrate them at all. In cases like these, Command C can write a tool that fetches an order history from the old system on demand. This allows customers to get the information they need while keeping your new site as streamlined as possible.

Consideration #3: How clean is current data and how will it be exported from your current system?

As ecommerce systems grow over time, they often begin to contain outdated, duplicate, or incorrect data. For instance, the product attributes or tags may have changed over time. A customer may have multiple accounts. Or they may have initially checked out as a guest before creating their account. Product photos may be outdated, blurry from compression, or the wrong size for the new platform. The data migration process is often a great time to tidy up existing data. This could include things like removing or merging duplicate customer accounts, cleaning up product information, or reformatting product photos.

Once the data has been cleaned up, it’s also important to understand how it can be exported from the old system and loaded into the new system. Often, different data types require different formats.

For example, at Command C, one of the most common ways we work with exported data is through CSV files. These need to be clean and “machine-readable,” meaning that an importer tool can easily interpret the data. Once we get these CSV files, we typically rewrite them into a format that the new platform will accept. At other times, we write our own integration with an API that will migrate all of our information into the new platform. (This second scenario is less common.)

The CSV approach is also good because it gives retailers the opportunity to really simplify their data prior to the transfer. For starters, you can eliminate whole columns that you don’t need any longer or rename columns with clearer definitions for the new site.

But keep in mind: every retailer is unique. There’s no one-size-fits-all solution. In every case, we work with clients to determine the best data export method for them.

Consideration #4: Data migration should happen ONCE

Your data holds the history of your retail company to date. We want this data to be as clean as possible. In replatforming, merchants get a fresh start for their business. Yet, in order for this fresh start to be as close to perfection as possible, the data should only be transferred once.

With this in mind, think about where else your data resides, such as in an ERP, CRM, or an email platform. How will your migrated data synchronize with those external systems? We always work to ensure that the migrated data doesn’t cause conflicts or duplicate records – on either end of the integration.

We’re sharing these four considerations in order to help retailers avoid worst-case scenarios. For example, it would be a big problem to transfer your data, launch your new site, and then realize that you’re missing important information. Or bring over superfluous data that slows down your new site. Worst yet, your data migration could create duplicate records for every order in your fulfillment system. (Now THERE’S a scary thought.)

It may be tempting to skip some of these steps in order to launch on a new platform ASAP. From our experience, however, ignoring the details in data migration can cause much larger issues down the road. At Command C, we work closely with clients to lock in a strategy before the data migration – and to ensure that it only happens once.