Migrating away from WooCommerce to a custom store

WooCommerce is WordPress with a till, and you already own the database

WooCommerce is a plugin that turns a WordPress site into a shop. It is free, open source under the GPLv3, runs on your own hosting, and sits on more than 7 million WordPress sites, which makes it the most widely used way to sell online.¹ If you run a small, content led shop on it and someone keeps the plugins patched, this article is not trying to move you. A well run WooCommerce shop is a perfectly good shop, and I will say near the end exactly who should stay.

The twist with WooCommerce, and the reason it is different from every hosted platform in this series, is what you own. On Shopify or BigCommerce your data lives on someone else's servers and you get it out through whatever export they choose to give you. On WooCommerce the shop is a WordPress install on hosting you pay for, and the data sits in a MySQL database you can already reach. So the usual headline of a migration article, "can I get my data out", barely applies. You can. The export is the cleanest of any platform I write about.

That changes the whole question. With WooCommerce the reason to move is almost never that you are locked out of your data. It is that the stack underneath the shop has become a maintenance and risk problem, and owning the files does not make it maintainable. This article is about that honest trade: when a fragile tower of plugins is worth replacing with one owned, tested Rails application on Solidus, and when it is not. For the platform independent detail on how each kind of data actually moves, I link the data type guides as they come up rather than repeat them. The whole map is in what moves and what does not.

What you own, which really is almost everything

Three doors lead out of a WooCommerce shop, and unlike a hosted platform you hold the keys to all three.

The first is the database. WooCommerce stores its data in your WordPress MySQL database, so with database access you can read customers, products, orders and almost anything else directly. Since WooCommerce 8.2, released in October 2023, new shops store orders in dedicated tables such as wc_orders rather than in the old WordPress posts and postmeta tables, which makes order data cleaner to read than it used to be.² Products still live in the WordPress posts and postmeta structure, which is tidier for reading than it is for writing.

The second is the REST API. WooCommerce ships a REST API at /wp-json/wc/v3/, the current version being v3, covering products, orders, customers, coupons, refunds and more.³ Over HTTPS you authenticate with a consumer key and secret as Basic Auth credentials, which you generate under WooCommerce, Settings, Advanced, REST API, choosing read, write or read and write access for a chosen user. Over plain HTTP it falls back to OAuth 1.0a one legged signing with HMAC-SHA1 or HMAC-SHA256.³ There is no per minute rate limit baked into the core REST API. The one rate limit WooCommerce documents is on the newer Store API, and it is off by default: when switched on through a filter it caps POST requests at 25 in a 10 second window, with a stricter option of 3 checkout requests per 60 seconds.⁴ In practice the ceiling on a bulk export is your own server and host, not WooCommerce, so a large pull is a matter of paging politely rather than fighting a quota.

The third is the built in product CSV importer and exporter. WooCommerce includes a CSV tool for importing, exporting and bulk updating products out of the box.⁵ It handles simple, variable, grouped, external and downloadable products, images by URL, categories, attributes and prices, and it reads and writes custom fields when you prefix the column header with meta:, for example meta:product_depth.⁵ On export you tick an option to include all custom meta.⁵ It is genuinely useful, and it has honest edges: unrecognised columns are not imported by default, the importer cannot set alt text on images or assign a specific post ID to a new product, exported variation names may drop their attribute values, and the maximum upload size is set at your server level, so very large catalogues are split into batches.⁵

Between these three, customer, product and order data is all reachable. This is the easiest export story in the series, and it is worth saying plainly before the rest of the article explains why people still leave.

The one thing that does not come out: passwords

The single export that WooCommerce cannot hand you clean is the one no platform can. WordPress never stores a password. It stores a hash. For years those were phpass portable hashes with a $P$ prefix, and as of WordPress 6.8 new and changed passwords are hashed with bcrypt, written with a $wp$2y$ prefix, with older hashes rehashed to bcrypt the next time a user logs in.⁶ A hash is a one way function, so there is nothing to decrypt and nothing to carry into a new shop's own hashing scheme. The clean path is a password reset at first login on the new store, which is a planned message rather than a problem. The customer accounts guide covers how to run that reset as a relaunch rather than a surprise.

The real reason to move is the plugin tower, not the data

If the data comes out easily, why leave? Because a real WooCommerce shop is rarely just WooCommerce. It is WordPress, plus WooCommerce, plus a payment gateway plugin, plus a subscriptions extension, plus a German legal texts plugin, plus a reviews plugin, plus a page builder, plus a caching plugin, plus a security plugin, plus a backup plugin, plus whatever the last agency added to solve last year's problem. Every one of those has to agree with every other one, and all of them have to stay updated, and the shop breaks when any two of them disagree after an update nobody dared to apply.

That is a maintenance and risk problem, and it has three sharp edges.

The first is security. Patchstack counted 11,334 new vulnerabilities across the WordPress ecosystem in 2025, 91% of them in plugins and 9% in themes, with only six in WordPress core, and 46% of them had no fix from the developer by the time they were disclosed.⁷ The shop is not WordPress core, which is well defended. The shop is the dozen plugins around it, and each one is a door you have to keep shut. A breach that touches personal data has to be reported to the regulator within 72 hours where feasible under the UK GDPR, so this is a boardroom risk, not just a developer's worry.⁸

The second is performance. A small catalogue on good hosting is fine. Past a few thousand products, a busy order flow or a traffic spike, the WordPress and MySQL stack needs the kind of caching, tuning and hosting attention that quietly eats the word "free" out of the price. The platform was built as a blogging engine with a shop bolted on, and it behaves like one under load.

The third, and the real point, is that owning the files does not make the stack maintainable. You own a tower built from parts made by a dozen different companies, each on its own release schedule, none of them responsible for the whole. When one of them is abandoned, or sold, or changes its licence, that is your problem to solve, usually at an agency's day rate and usually under time pressure.

The custom alternative is not "more of the same, but mine". It is a different shape. A Solidus store is one Rails application, written and tested as a whole, deployed as a whole, where the payment flow, the subscription logic and the checkout are code you own rather than plugins you hope still agree with each other. You trade a fragile tower for a single owned building. That is the trade, and whether it is worth it depends entirely on how heavy your tower has become.

The traps that are specific to WooCommerce

A migration off WooCommerce is mostly easy data and a handful of genuinely hard knots. The knots are worth naming before you start.

Payment gateways and saved cards. Each payment gateway is a separate plugin, and each stores its configuration and its saved card tokens in its own way. WooCommerce keeps saved methods through its payment token system, where tokens live in the database and are fetched per customer and, optionally, per gateway, so a token is always tied to the gateway that created it.⁹ What is stored is a reference, never the raw card, because the card data sits with the processor. The consequence for a move is the same as everywhere in this series: a token is meaningless to a different gateway, so saved cards only travel if you keep the same processor, and even then only between providers certified to PCI DSS Level 1, which Stripe, for example, will do on request but without the subscriptions or payment history.¹⁰ The best outcome is to connect the new Solidus store to the same Stripe or gateway account the shop already uses, so the vaulted cards never move at all. The payment tokens guide is the place for the full detail.

Subscriptions. Recurring billing on WooCommerce almost always runs through the paid WooCommerce Subscriptions extension, a yearly licence that integrates with more than 25 payment gateways for automatic renewals, with manual renewals available on any gateway.¹¹ The catch for a migration is that automatic renewals depend on the gateway holding a reusable token, so a subscription is only as portable as the token behind it. Subscriptions are managed on your own site rather than inside the gateway account, which means the schedule, the next payment date and the billing history are yours to export, but the authority to charge the card again lives with the processor.¹¹ This is the hardest knot in a WooCommerce move, and it is the first thing I map, not the last. The subscriptions guide walks through keeping active subscribers billing without a gap.

SEO and the URL structure. WooCommerce uses WordPress permalinks, and years of links and rankings hang off them. A move keeps that value only if every old product, category and content URL maps to a permanent redirect that points straight at its new home and stays in place for at least a year, which is exactly what Google's own guidance for a site move with URL changes asks for.¹² On the shops I build the redirect map is a database table with an admin screen, so it survives every future deploy and your own staff can add one when they spot a stray. The mechanics of products, slugs and redirects are in the products and catalogue guide.

Content that is not product data. This is the WooCommerce specific tidy up. A lot of what looks like product information is really page builder output: a product described in Elementor or a similar builder stores its layout as a wall of shortcodes and meta in postmeta, not as clean fields. Custom fields added by a theme or a plugin are the same. None of that exports through the product CSV as structured data, because it was never structured data. Part of a good move is deciding what was genuine product information, which migrates cleanly, and what was presentation glued on by a builder, which is rebuilt properly in the new storefront rather than carried across as noise.

What moves, what needs work, what is locked

The honest shape of a WooCommerce move, in one table.

What	How it moves	Effort
Products, variants, prices, images, categories	REST API, CSV exporter, or direct database read	Low, mostly mapping and checking
Customers and addresses	REST API or database, one row per customer	Low
Order history	wc_orders tables or REST API, cleaner since HPOS	Low to medium
Passwords	Do not move, reset at first login	Planned, not hard
Saved cards and tokens	Only by keeping the same gateway account	Hard, plan first
Active subscriptions	Depend on the gateway token, not the shop	Hardest, plan first
SEO value in URLs	Full redirect map, 301 for each old URL	Medium, the best days of the project
Page builder and custom field content	Rebuilt, not migrated	Medium, decide what was real

The pattern is the opposite of a hosted platform. The data is easy and the money questions, cards and subscriptions, are the hard part, so they go first in the plan, not last.

The honest move plan

A move off WooCommerce onto a custom Solidus store runs in the same order as any shop migration, with the WooCommerce specific notes folded in. First, name the person on your side who understands the data, the one who knows why the old product codes have suffixes and which customers are trade. Without that person you get a beautiful new shop full of wrong data. Second, settle the hard knots before anything else: which gateway stays, whether active subscriptions can keep their tokens, and what the subscription schedule looks like. Third, build the store and write the import scripts, running them again and again against a copy of the real database until the final import holds no surprises. Fourth, build the redirect map from the last twelve months of traffic, one row per URL, tested. Fifth, run both shops in parallel with the old catalogue frozen, rehearse the cutover twice, then switch over on a quiet weekday morning and keep the old shop untouched for thirty days as the fallback. The full method, the cutover sequence and the mistakes to avoid are in the five year cost and migration guide, and the pillar article is the map over all of it.

A worked example

Meadowgate Pet Supplies (meadowgatepet.example) is an invented Leeds shop selling food, toys and accessories, turning over about £900,000 a year online, with roughly 2,500 products and a growing monthly food subscription that a core of regular customers has come to rely on. It has been on WooCommerce for six years. The shop works, but the owner has stopped sleeping well. There are fourteen active plugins. The last WordPress update broke the relationship between the subscriptions plugin and the reviews plugin for a weekend, and three months ago a security scanner flagged an abandoned plugin with a known vulnerability that had no patch, which is exactly the kind of case Patchstack counts.⁷ The agency that built it has moved on. The owner does not want a bigger WooCommerce. She wants to stop living on top of a tower that sways.

Here is how I would weigh her move. The data is the easy half. Her 2,500 products, her customers and six years of orders all export cleanly through the REST API and the database, and the HPOS order tables make the order history tidier than she expects.³² Passwords reset at first login, with a service message prepared in advance.⁶ None of that keeps me up at night.

The subscription is the half I map first. Her monthly food boxes run through WooCommerce Subscriptions on a gateway that vaults the card.¹¹ Before I promise her anything, I confirm one thing in writing: whether her subscribers' cards can keep billing on the new store without being re entered. If the new Solidus shop connects to the same Stripe account, the tokens stay where they are and the subscriptions continue. If not, we plan a re authorisation campaign and accept some churn. I tell her that honestly on day one, because discovering it in week eleven is how migrations go wrong.¹⁰

What she gains is a single Rails application where the subscription logic, the checkout and the trade pricing she wants to add are tested code she owns, not three plugins negotiating a truce after every update. What she gives up is the weekend launch and the marketplace of plugins. A Solidus build costs more in year one than carrying on, and she needs a Rails developer she trusts. For a shop her size, kept awake by the maintenance and the risk rather than by the bill, that trade is usually worth it. For a quieter shop it would not be, and I would tell her so.

Who should stay on WooCommerce

I would not move a small, content led shop with a modest catalogue, a light plugin list and someone who keeps it patched. If WordPress is already where your content lives, your catalogue is in the hundreds not the thousands, and nothing about the shop keeps you up at night, WooCommerce is a reasonable and genuinely owned answer, and a rebuild would be spending money to solve a problem you do not have. Write down the revenue, the plugin count or the incident that would make you reconsider, so the decision is made on purpose rather than in a panic after a breach.

The shops that should move are the ones where the tower has become the job: where keeping the plugins agreeing, patched and performant takes more attention than the shop earns back, where a security scare has already happened or clearly will, and where the features you need next are fights against the platform rather than parts of it. If the way people buy from you is becoming part of why they buy from you, the plugin tower is the wrong foundation, and I compare all five platforms honestly in the platform comparison. WooCommerce and the hosted platforms sit at opposite ends of the same question of ownership, which is why the contrast with leaving Shopify is worth reading alongside this. If you want the deeper argument about who holds your records, who actually owns your business data is the one to read.

If you are weighing it up, bring your plugin list, your subscription setup and twelve months of agency invoices to a free workshop, and the first two weeks of work are on me. I will map what moves cleanly, what needs work and what is locked, and if the honest answer is to stay on WooCommerce and patch it well, I will tell you that too.

Footnotes

1. WordPress.org, WooCommerce plugin page (active installations, current version, open source and GPLv3 licence, requires WordPress), accessed 14 November 2026, https://wordpress.org/plugins/woocommerce/ ↩

2. WooCommerce, High Performance Order Storage (orders stored in custom tables, enabled by default for new installations from WooCommerce 8.2, released October 2023), accessed 14 November 2026, https://developer.woocommerce.com/docs/features/high-performance-order-storage/ ↩ ↩²

3. WooCommerce, REST API Documentation (current version wc/v3, base route, HTTPS Basic Auth and HTTP OAuth 1.0a one legged authentication, key generation), accessed 14 November 2026, https://woocommerce.github.io/woocommerce-rest-api-docs/ ↩ ↩² ↩³

4. WooCommerce, Store API rate limiting (disabled by default, controlled through the woocommerce_store_api_rate_limit_options filter, POST only, default 25 requests per 10 seconds, checkout option of 3 per 60 seconds), accessed 14 November 2026, https://developer.woocommerce.com/docs/apis/store-api/rate-limiting/ ↩

5. WooCommerce, Product CSV Importer and Exporter (supported product types and columns, the meta: prefix for custom fields, export all custom meta, and documented limitations), accessed 14 November 2026, https://woocommerce.com/document/product-csv-importer-exporter/ ↩ ↩² ↩³ ↩⁴

6. Make WordPress Core, Password hashing upgrades in WordPress 6.8 (phpass to bcrypt, the $wp$2y$ prefix, existing hashes rehashed on login), 17 February 2025, https://make.wordpress.org/core/2025/02/17/wordpress-6-8-will-use-bcrypt-for-password-hashing/ ↩ ↩²

7. Patchstack, State of WordPress Security in 2026 (11,334 new vulnerabilities in 2025, 91% in plugins and 9% in themes, six in core, 46% unpatched at disclosure), 2026, https://patchstack.com/whitepaper/state-of-wordpress-security-in-2026/ ↩ ↩²

8. Regulation (EU) 2016/679 (General Data Protection Regulation), Articles 28 and 33, EUR Lex, https://eur-lex.europa.eu/eli/reg/2016/679/oj, and UK GDPR, Article 33, legislation.gov.uk, https://www.legislation.gov.uk/eur/2016/679/article/33 ↩

9. WooCommerce, WC_Payment_Tokens class reference (tokens stored in the database, get_customer_tokens with an optional gateway filter, delete by ID), accessed 14 November 2026, https://woocommerce.github.io/code-reference/classes/WC-Payment-Tokens.html ↩

10. Stripe, Request a payment data export (card data exported only to a processor certified at PCI DSS Level 1, without subscriptions or payment history), Stripe documentation, https://docs.stripe.com/get-started/data-migrations/pan-export ↩ ↩²

11. WooCommerce, WooCommerce Subscriptions product page (a paid annual extension, integrations with over 25 payment gateways for automatic recurring payments, manual renewals on any gateway, subscriptions managed on your own site), accessed 14 November 2026, https://woocommerce.com/products/woocommerce-subscriptions/ ↩ ↩² ↩³

12. Google Search Central, Site moves with URL changes (map each old URL to a permanent redirect pointing at its final destination, kept for at least a year), https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes ↩