StoreEngine’s Migration add-on moves your products, active coupons and orders across in a few clicks. Enable the add-on, open Tools → eCommarce Migration, run it on a staging copy first, verify the data, then deactivate the old plugin. The migration takes minutes. The preparation around it is what decides whether it goes well.

Replatforming has a reputation for being terrifying, and that reputation was earned by people who ran an untested import against a live store on a Friday afternoon. The tooling is genuinely straightforward now. The discipline around it is what has not changed.

Quick takeawayThe Migration add-on transfers all products (simple and variable), all active coupons, and all orders including refunds and related data.The WooCommerce plugin must stay installed and active during migration. Deactivating it first stops the process from running.Customer records are not part of the migration add-on — those move through the Export/Import CSV add-on instead.Payment gateways, shipping zones, tax rules and theme templates are rebuilt, not migrated. Budget time for them.Run it on staging first. StoreEngine’s own documentation names this as best practice, and it is the one step people skip.

Why do store owners replatform in the first place?

Nobody migrates a working store for entertainment. The trigger is almost always the same shape: the store got slower, the plugin stack got more fragile, and somewhere in the middle the checkout started losing people.

The numbers on that are unusually stark. Stores that load in one second convert at around 3.05%. At five seconds, that falls to 1.08% — roughly a third of the revenue from the same traffic. Meanwhile the average mobile page in 2026 takes 8.6 seconds to load, against 2.5 seconds on desktop, and 53% of mobile visits are abandoned when a page takes longer than three seconds. A two-second delay pushes cart abandonment as high as 87%.

The second trigger is architectural rather than numerical. A store that needs eleven plugins to sell a subscription with an order bump and a licence key is not a store with a feature problem. It is a store with an integration surface problem, and every plugin update is a chance for something to break in a way nobody notices until a customer emails.

StoreEngine’s pitch here is consolidation: subscriptions, memberships, installment plans, invoicing, licence management, affiliates, order bumps, upsells and abandoned cart recovery are built in rather than assembled. Whether that trade is right for you depends on how much of your current stack you actually use.

What exactly does the Migration add-on transfer?

This is the section to read carefully, because the gap between what people assume migrates and what actually migrates is where the bad afternoons live.

The add-on transfers three things: all products, including both simple and variable types; all active coupons; and all orders, including refunds and related data. That covers the bulk of what a typical store cares about, and it covers it automatically.

What it does not cover is equally important. Customer records are not part of the migration add-on — StoreEngine handles thos e through its separate Export/Import add-on, which moves customers, products, orders and memberships through CSV files. Expired and inactive coupons are outside the scope. Subscription and membership records, theme templates, custom page layouts, third-party extension data and payment gateway credentials all need their own plan.

Critical prerequisite: The WooCommerce plugin has to be installed and active for the migration to run at all. The add-on reads from it directly. Deactivating the old plugin before you migrate does not clean the slate — it just stops the process working.

It is also worth knowing that the add-on currently supports migration from WooCommerce only. Support for additional platforms is on the roadmap, but if you are coming from somewhere else today, the CSV route is your path.

What should you do before you run anything?

Six things, in this order. None of them are optional on a store with real revenue.

1. Take a full backup. Files and database, stored somewhere that is not the same server. Verify you can actually restore it rather than assuming. StoreEngine 2.2.0 added scheduled backups, so automate this step if you can.
2. Clone to staging. Run the entire migration there first. StoreEngine’s documentation calls this out explicitly, and it is the step that turns an unknown into a rehearsal.
3. Record your counts. Write down how many products, orders and active coupons you have right now. Without a baseline you cannot verify anything afterwards.
4. Audit your extensions. List every commerce-related plugin you run and decide, for each one, whether StoreEngine covers it natively, whether you need an alternative, or whether you can drop it.
5. Export your customers. Since they sit outside the migration add-on, get the CSV out before you start rather than mid-flight.
6. Pick a quiet window. Look at your own order timestamps and find the genuine trough. For most stores that is not the middle of the night, it is a weekday morning.

How do you run the migration, step by step?

With the preparation done, the migration itself is short enough to feel anticlimactic. That is the intended experience. For the live screenshots and current UI, see the official Migration Add-on documentation.

7. Enable the Migration Tool add-on. From the StoreEngine Dashboard, go to Add-ons, search for “Migration Tool,” and toggle it on.

8. Navigate to Tools → Migration. Once enabled, head to the StoreEngine Dashboard → Tools menu, then click the Migration tab. You’ll see the WooCommerce Migration panel showing what will be transferred. This is where you review the scope before proceeding.

9. Click Run Migration and confirm. A confirmation prompt will appear asking “Are you sure you want to migrate WooCommerce data to StoreEngine?” This is your last chance to cancel. Review once more, then click Confirm to proceed.

10. Wait for the success message. StoreEngine processes your data. The time depends on store size — small stores finish in seconds, large ones may take minutes. A success message will confirm when the transfer is complete.

After the success message: Do not deactivate WooCommerce yet. Do not assume the migration is complete. The success message confirms data moved, but you still need to reconcile counts, verify product data, rebuild payment gateways, and run a test order.

What should you verify before you trust it?

A success message tells you the data moved. It does not tell you the store sells. Those are different claims, and only one of them has been tested at this point.

Work through verification in two passes. The first pass is data integrity: reconcile your product, order and coupon counts against the baseline you recorded, then open several variable products and confirm every variation, price and stock level survived. Variable products are where import bugs hide, because a partial import still looks fine in a list view.

The second pass is store function, and this is where most of your remaining work sits. Payment gateways need reconnecting — credentials do not migrate, and neither should they. Shipping zones and rates need rebuilding. Tax rules need configuring. Then place one real order, with a real card, and refund yourself.

When is it safe to deactivate the old plugin?

After the migration is complete and you have confirmed everything works correctly in StoreEngine, you can safely deactivate the WooCommerce plugin and run your store entirely on StoreEngine. That is the documented sequence, and the ordering is deliberate: verify first, deactivate second.

In practice, give it longer than feels necessary. Deactivate rather than delete, leave it in place for a week or two, and let a full billing cycle pass if you sell subscriptions. An inactive plugin costs you nothing but disk space. A deleted one costs you your fallback.

Watch your support inbox during that window too. Customers surface the problems your checklist did not — a specific coupon that stopped applying, an order they cannot find in their account, a download link that expired. Those reports arrive in the first fortnight or not at all.

What could go wrong, and how do you avoid it?

The pattern across all of these is the same. Nothing on that list is catastrophic if you found it on staging with a backup sitting beside you. Every one of them is a genuinely bad day if you found it on a live store at peak traffic.

Frequently asked questions

Always reference the official docs: This post covers the same steps as the StoreEngine Migration Add-on documentation, with narrative and context around each stage. For the most current details and screenshots, see the official docs.