Migrating to WooCommerce from anywhere else

Guides for WooCommerce migration nearly always assume you are coming from Shopify. Plenty of people are not. They are on Wix, Squarespace, BigCommerce, Magento, PrestaShop, OpenCart, Ecwid, Etsy, or something a developer built in 2014 and then stopped answering emails about.

The platforms differ. The migration does not, much. This is the platform-agnostic version, with the specific quirks noted where they matter.

The route that always works

Before the platform-specific notes, the general principle: every store that sells to the public publishes its catalogue. It has to. Titles, prices, descriptions, images and stock state are all on the product pages, and on any modern platform they are also in structured JSON-LD in the page head, because that is what search engines and social previews read.

That means the storefront is a complete and universal data source, available regardless of whether the platform offers an export, whether you have admin access, and whether the vendor wants to make leaving easy.

It is also the only source that works when the answer to "can you export your products?" is "I do not know, the person who set it up left".

Tools like Scrapify read that public data and write it out in WooCommerce's import schema. No plugin on the source, no admin login, no vendor cooperation required.

Wix

Export: Store Products, then the export option in the catalogue view. Produces a CSV.

What you get: name, description, price, SKU, ribbon, basic options, one image URL reliably.

What is missing: the full image gallery, custom fields, product-level SEO settings, and often the complete variant matrix if you use Wix's option system heavily.

URL structure: /product-page/{slug}, which maps predictably to WooCommerce's /product/{slug}. That makes the redirect map mostly formulaic, which is a rare gift.

Watch for: Wix descriptions frequently contain platform-specific markup that renders badly outside Wix. Spot check a dozen after import and strip anything odd.

Squarespace

Export: Settings, Import and Export, Export, and choose Products. You get a CSV in Squarespace's own shape.

What you get: title, description, SKU, price, sale price, stock, variant rows, and hosted image URLs.

What is missing: category assignment is inconsistent, because Squarespace organises products by page rather than by taxonomy. You will usually rebuild categories by hand.

URL structure: /shop/{slug} or /store/{slug} depending on your page naming. Simple to map, but check the actual page slug rather than assuming.

Watch for: Squarespace's image URLs carry format parameters. Strip anything after the filename or you may import a thumbnail instead of a full-resolution image.

Magento

Export: System, Data Transfer, Export, entity type Products. Configurable and thorough.

What you get: essentially everything. Magento's export is the most complete of any platform here.

The problem is the opposite one. Magento exports 200 or more columns including attribute sets, websites, store views and multi-source inventory. Most of it has no WooCommerce equivalent, and finding the 25 columns you need inside it is genuinely tedious.

Configurable products map to WooCommerce variable products, and simple products that are children of a configurable become variations. Magento expresses this relationship through configurable_variations, which needs parsing into WooCommerce's parent and variation row structure.

URL structure: highly customisable, typically /{url-key}.html. The .html suffix means essentially nothing maps automatically, so budget for a real redirect map.

BigCommerce

Export: Products, Export, with a choice of templates. Pick the default export template rather than the Bulk Edit one, which omits fields.

What you get: a solid, complete export including variants, custom fields and images.

Watch for: BigCommerce uses a parent row followed by child rows in a shape close to WooCommerce's, so the conversion is more mechanical than most. Its "Product Rules" system for variant pricing has no direct WooCommerce equivalent and needs re-expressing as per-variation prices.

URL structure: /{slug}/ at the root by default, with no /product/ prefix. Either change WooCommerce's permalink base to match, or accept a full redirect map.

PrestaShop and OpenCart

Export: both have built-in CSV export, and both are incomplete in the same place: combinations, which is what they call variants.

PrestaShop exports products and combinations as separate files that you have to join on product ID. OpenCart's default export similarly separates options from products.

Watch for: both store multilingual content in ways that flatten badly. If you run a multi-language store, export one language at a time and treat the others as a second project with WPML or Polylang.

Etsy and marketplaces

Export: Etsy offers a listings CSV under Settings, Options, Download Data.

What you get: title, description, price, quantity, tags, materials, and image URLs.

What is missing: variations are exported in a barely usable flattened form, and there is no category structure to speak of because Etsy's taxonomy is its own.

Watch for: Etsy listings are written for Etsy's search algorithm, which is keyword-stuffed in a way that reads badly on your own site and does not help you rank on Google. Budget time to rewrite rather than importing verbatim.

When there is no export at all

Custom builds, abandoned platforms, and vendors who make leaving deliberately painful all land here. So do the cases where an export technically exists but produces something unusable.

The storefront route applies. What you can recover:

Customers and orders are the genuine limit, and correctly so. If you cannot get into the admin, that data is not recoverable, and any tool claiming otherwise is doing something you should not want.

Redirects, whatever you are coming from

Every platform has its own URL shape, so this step is universal.

WooCommerce lets you change its product permalink base under Settings, Permalinks. Where the source used a simple prefix, matching it eliminates most of the redirect work in one setting change. Take that shortcut when it is available.

Get your real URL list from Google Search Console rather than crawling the site, because Search Console knows about pages a crawler will not reach, including ones with backlinks pointing at them.

Should you migrate order history?

Usually not into live WooCommerce tables.

Historical orders rarely function correctly on a new platform. Line items reference products that now have different IDs, tax and shipping calculations were made by rules that no longer exist, payment records point at a gateway you have left, and refunds cannot be processed through it anyway.

What you get is a set of records that look like orders, confuse your reporting, and occasionally interfere with stock.

Export them to CSV, store them somewhere searchable, and start WooCommerce with a clean order table. Customer accounts are worth migrating, because email and address data is genuinely useful, but everyone will need a password reset regardless of source platform, since no two platforms share a hashing scheme.

The order to do it in

1. Export the indexed URL list from Search Console. Do this first, while the old store is still live and reporting.
2. Get the product data out, by export or from the storefront.
3. Convert to the WooCommerce schema. See the schema reference.
4. Import into a staging site, never production.
5. Verify counts, images, variants and prices. See the error guide when something looks wrong.
6. Rebuild categories and navigation for how customers shop, not how the old platform organised things.
7. Build and load the redirect map.
8. Test checkout end to end with a real payment and a real refund.
9. Go live, then keep the old store running unlinked for 30 days.

The old store staying up is not paranoia. It is the only way to check something you forgot, and it costs one more month of hosting you were paying for anyway.

Frequently asked questions