SkyVerge WooCommerce Extensions

One of the most common problems for WooCommerce stores that have multiple environments (such as a staging and live version of the site) is how to move data back and forth between these environments. For example, what if you use an eCommerce-friendly host like SiteGround or Kinsta with a one-click staging environment you can use? You could update a design on the staging site, but to push that information live, you have a couple choices:

  • re-do the work on the live site by hand.
  • push the staging site to live (overwriting the live site). But, you risk losing data that’s been added to the live site since cloning happened.

Wait, why can’t you just “merge in” all of the new stuff? On the surface, it doesn’t seem like it’s too tough of a problem, right? “I have orders on Site A, and I’m building new products and refreshing design on Site B. Let’s either move the orders to Site B, or the new design and products to Site A.” Should be easy. ๐Ÿ˜‰

That’s the basic problem we’ll look at today:

What is the best way to move WooCommerce orders between sites while keeping the order number the same between them?

In reality, this is quite a complex problem when data on one site diverges from data on the other. Before we dig deeper, know this solution is best when you have sites that each have new data (e.g., one may have new products, options, or other stuff, while the other has new orders or customers). If you’re moving data wholesale from one site to another, one of our favorite tools for moving data is WP MigrateDB Pro. However, WP MigrateDB Pro is best if you’re moving entire tables (all data) from one site to another.

So when is WP MigrateDB Pro not the ideal solution? What can get so hairy? Let’s look at why merging data between sites is so difficult.

The Pledge

This is where we show you something seemingly ordinary, right? Let’s take a look at this “innocuous” eCommerce data: orders, products, coupons. Each of these is represented in different areas on your WooCommerce site.

That’s because each of them is a unique “post type”, or kind of content.

The same goes for other content on your site added via extensions: subscriptions, user memberships, maybe even custom order statuses. They’re all different data…or are they?

The Turn

Now let’s make this data extraordinary (at least in the truest sense of the word, anyway). The issue is that, behind the scenes in WordPress, these are all the same thing: posts. So are your blog posts, pages, and many other kinds of content on the site: user memberships, subscription records, vouchers — all of these are “posts” or “custom post types”.

They use the existing WordPress “post” data structure for storing things: posts and post meta. Doing so gives developers ready-made tools to work with with this data: WP_Query and other ways of retrieving posts, or functions like update_post_meta() or get_post_meta() to update or get meta data for posts. These “APIs” can save you a lot of time when building a new solution, and are really valuable to make your code friendly to other WordPress developers out of the box.

However, the problem is that all of this data now uses a common identifier: the post ID. The post ID is the “counter” that tells all posts on the site apart — every post on a WordPress site has a unique, auto-incremented post ID. (Sort of like a Social Security Number or driver’s license number.)

This is also why your order numbers are not sequential by default: the order number typically uses the post ID; this ID is generated by a counter that’s also incremented each time a product, blog post, page, or other content is added.

Now we start to see why order migrations are hard: we can’t just migrate a single database table that contains orders — they’re mixed up with every kind of other content on your site (products, pages, posts, and more). So unless you can move that entire “posts” table between sites (if the blog posts, orders, products, and all other content is the same — which is where WP MigrateDB Pro comes in), along with every table that contains meta, such as the post meta table, order items meta, order items, and other tables, then we need a way to move orders alone.

The Prestige

The third act! This won’t quite be magic, but it is possible to move WooCommerce orders between sites and keep order number the same. However, we can’t keep order ID (post ID) the same.

Wait, what? While on most sites, order ID is used as order number, these concepts are not identical. The order number can be filtered and changed, so we could make order numbers match between sites that have different post IDs or differing content. We just can’t force the post IDs to match, as a post on the destination site may already use the desired post ID, so WordPress won’t overwrite its data.

There are a few steps to syncing order numbers between sites, but before we get into it, know that migrating data is always hard. While there are plugins to help you, you need to be knowledgeable about what you’re doing, as porting data from one site to another requires a thorough understanding of what you’re changing or adding.

Rules of Engagement

There a few cardinal rules for migrating data between sites to know up-front:

  • Keep a source of truth at all times. Only one of the sites you’re working on can be changed; the other site must be the record of truth (e.g., it has all of the orders or data you want to move); you move data from that origin site (source of truth) to the destination site.If you have “new” information (such as new orders) on both sites, no one can help you, including this article. You must sort out the mess manually, and you’re on your own — no developer in the world can automate this.

    There is absolutely no automatic way to know which orders should be discarded and which should be kept when there are clashes. Or, even if all orders should be retained, there’s no programmatic way to know which orders would keep their order numbers, but which would get order numbers re-assigned. You need a custom script that handles this on a case-by-case basis (with criteria to use) or individual human-made decisions.

    So, products could change on one site and orders on the other, but you can’t change orders on both sites.

  • If you have the ability to practice your data imports, PRACTICE. For example, SiteGround lets you have multiple staging sites — you could clone a live site right before you want to merge to it to test the process. While the import plugin we’ll use has a “dry run” capacity, this just dry runs to ensure there are no formatting errors in a file, it does not ensure the merge will happen the way you think it should.
  • Tied to the point above, be aware that data merges are irreversible once done. If you haven’t practiced the exact process you’re doing, then you must have a current backup ready in case things go wrong.

Tools of the Trade

Here are the tools I’m going to use in this guide to migrate orders from my live site to my staging site:

  • Sequential Order Numbers (free) – this is a plugin our team has built to make order numbers on your site sequential. The reason we’ll use it here is to ensure we have order number as a way to match orders between sites, not order ID. The Sequential Orders Numbers Pro plugin ($49) can also be used.
  • Customer / Order CSV Export ($79) – This will let me get order data out of my live site in the expected format.
  • Customer / Coupon / Order CSV Import ($79) – This will bring data into my staging site, and it works with both Sequential Order Numbers (and the Pro version), and CSV Export.

Install Sequential Order Numbers / Pro on BOTH sites. This is important — you not only need to get the order number from the origin site, but use it on the destination site as well. This will not change existing order numbers; it matches them up so its order number will equal the existing ID. It does change order numbers going forward to be sequential if you leave it activated on the origin site. Regardless, it must stay active on the destination site going forward to keep the order numbers synced.

CSV Export should be installed on the origin site, and the import plugin on the destination site to bring the data in.


Once you have the plugins activated, you’ll take these steps:

  1. Ensure the CSV Export format for your customers and orders is set to “CSV Import” (do this on both sections). I’m going to omit moving customers in this scenario, but if you need to move new customers as well, do it first. Just as we will be cognizant not to use order ID here, be aware of using user ID between sites.WooCommerce CSV Export settings
  2. Export the orders from the origin site you want to move. You can start the export and move onto something else, as an admin notice will pop up once it’s done.
  3. Take the new order CSV file over to the destination site. When you import this file, be aware of a few options for the import:
    • If you don’t have products that match up between sites, either fix it so SKUs do match up, or allow unknown products in the import.
    • If you don’t think you need to merge data, don’t do it.
    • If you do need to merge data, it should be fine, but we want to force merging based on order number, not ID. So, be sure to skip order ID in the import file.
  4. Even if you’re not merging, still skip order ID (and to be safe, and line item IDs, too) in the file mapping. Order ID is used to merge data within the same site (e.g., updating tracking information for orders). Since you’re not merging or doing anything within a site, order ID and any other database identifiers are useless.WooCommerce CSV Import row mapping

    If you try to use order ID on a site whose orders won’t match the IDs in the file, bad things will happen. You’ll probably overwrite data you don’t want to change, so be conscious of what the data you’re importing represents.

  5. Do a dry run to make sure your format is correct. Remember, this doesn’t ensure that things turn out the way you expect, as the plugin has no idea of your expectations. This ensures that the file can be read and processed. The CSV Import plugin is a hammer, it won’t frame a house for you — you have to choose how to swing it ๐Ÿ™‚
  6. If the dry run processes correctly, do a live import!

Now when the orders have been transferred, you’ll see that they have the same order numbers between both sites. ????

Published by Beka Rice

Beka leads product direction for SkyVerge and technical documentation. She spends a lot of time on research and interviews, but likes to write so she has an excuse to spend more time jamming out to anything from The Clash to Lady Gaga.


  1. Fantastic post! Is there a way to do this sync in a continuous manner (say scheduled every 1 hour)?

    The intended scope is:
    Woocommerce Site A = will be the record of truth!
    Woocommerce Site B = will be the target site where the Order details with numbers will be synced using the method explained by you.

    Request from you to suggest a manner to make the data transfer process a scheduled activity.

    Thanks a lot!

    • It’s certainly possible, but at present would require custom development to start the import without user input

      • Thanks Beka, I realized that! I would appreciate if you would update your post with some pointers on this automation approach!

  2. Thanks for this article Beka! We ended up having to do this for a new site design on an existing woocommerce site. Running my live import of orders now (crossing my fingers ๐Ÿ˜‰ — Also great talk at the WooConference! I had to buy the video streaming ticket but well worth it. Keep up the great work!

    • Glad to hear it was useful, John! And thanks for the kind words, it’s mind-blowing to me how many people tuned in from all over the world, glad to you were able to catch it ๐Ÿ˜€

  3. Thanks for the info!

    Do you have a sense of if this method will break subscriptions? I’m on SiteGround, created a new design on my staging environment, and am trying to push to production without losing the orders. I’ve had a handful of subscriptions come through in the meantime, and don’t want the customers to have to re-enter their orders …

    • I’d move your design over rather than pushing to production — even if you have to put the site into maintenance mode for a short period of time, it sounds like re-doing design work is a far better option here.

      • Yup, I did push to production and it did break the subscriptions. Thankfully I only had 1 customer, so I can get them to reestablish, but lesson learned!

  4. Thank you so much for this. I thought I had totally screwed up as we had done a lot of work on our test site and the orders numbers came in differently with a different plugin. You saved me!

  5. Thanks for this guide !

    I was thinking of doing it this way :

    Staging site : get everything neat and just before cloning to production, I wipe everything related to Woocommerce ( orders, customers…) and import the fresh ones from the live site ( while putting it in maintenance mode for a few minutes).

    It will be tricky for some plugins like Woocommerce Points & Rewards as I can’t find a way to export the points !

    Will this work ?


    • if you’re cloning from live to staging, then we always recommend a “fresh” copy / wipe staging first. the migration back to production is the harder one, where this guide is most helpful. As for migrating points, our plugins referenced here should cover this, as I think points are stored as order & user meta. If you do go this route and have questions, our support team can definitely take a look!

  6. Hi Guys,

    I just wanted to make sure I understood the functions of this plugin for what I’m trying to do. I cloned a woo site over to local by flywheel so that I can do design changes. New order have come in into the live site. Would it be possible to transfer the orders, new customers, etc to the local site and then push to live? I think that in the future, putting the site on hold for a bit would be best. Although in this case, it was a major re-design and couldn’t put the site on hold.

    Cheers! ๐Ÿ™‚

    • Hey Ferd, you could do this, but I would recommend just making the design changes on the live site instead — putting the site into maintenance mode for a bit while you port over the new designs is a lot easier to manage then trying to ensure you preserve order numbers.

  7. This COULD be our solution.

    I’m curious … though …

    What happens in the case of order e-mails and the links embedded within those?

    Where the user clicks a link and is redirected to a page on the site displaying their order?

    Is the “permalink” for that order generated from the POST ID or the Order Number? If we move the orders over, will those links still work (be directed to the correct order) or will they return an error?

Hmm, looks like this article is quite old! Its content may be outdated, so comments are now closed.