Your platform bill keeps growing and you want to own the store

Start with the number you can see, then hunt for the ones you cannot. The subscription tier is the published, honest part: a few tens of dollars a month on mainstream plans, climbing into the hundreds once you need extra staff accounts, better reporting or a lower card rate. Underneath sits payment processing — the card rate everybody pays, plus, on some platforms, an extra percentage charged when you use an outside gateway instead of the platform's own. Then comes the layer that actually decides your total: apps. Reviews, subscriptions, bundles, upsells, feed management, back-in-stock alerts, a page builder. Each is ten to fifty dollars a month, and each looked reasonable on the day you installed it. Add theme licences and the freelancer who edits that theme whenever you need something it was not built to do.

• Subscription tier at today's published price, not the one you signed
• Card processing, plus any surcharge for an outside gateway
• Every app on its own line, at its current monthly fee
• Theme licences and the hours you pay someone to edit them

Nothing here is free except the licence. Managed WordPress hosting that survives a traffic spike starts around the price of a mid-tier platform subscription and rises with catalogue size and traffic; cheap shared hosting is the most expensive decision in this whole exercise, and you pay for it in Core Web Vitals and lost orders. Premium plugins replace the apps you cancelled, usually as annual licences rather than monthly fees, which lowers the yearly total but front-loads it. Then the line most spreadsheets omit: somebody has to own the installation. Core, theme and plugin updates, a staging environment to test them on, backups you have actually restored once, security patching, and a broken checkout on a Sunday. That is a person, a retainer, or it is you. The plugin stack is also where performance quietly dies — plugin bloat explains the mechanism.

• Managed hosting sized for your catalogue, not the cheapest shared plan
• Annual plugin licences in place of monthly app subscriptions
• A staging site and a backup routine you have tested at least once
• A named person or retainer responsible for updates and outages

The trade is not cheap versus expensive. It is predictable rent versus ownership plus responsibility, and responsibility has a price even when no invoice names it. Run the sum properly. Take your platform total for the last twelve months, including apps and processing. Subtract everything you would still pay after moving: card processing does not disappear, and several apps have paid WooCommerce equivalents. What remains is your annual saving. Against it put the one-off migration and rebuild, plus the recurring cost of hosting and whoever maintains it. Divide, and you have a payback period in months. Under about eighteen months the case is usually strong. Past three years, you are spending a large sum to change the name on your invoice. Two variables move this more than any other: revenue, because percentage fees scale while subscriptions do not, and app count. What the work costs is published so you can run this before speaking to anyone.

A CSV export and import handles the straightforward majority of a catalogue: title, description, price, stock, images, simple variants. The remaining fraction is where migrations lose their schedule. Option structures differ between platforms, so a product with four or five distinct choices may need restructuring rather than transferring. Custom fields and metafields carry no guaranteed destination; you decide, per field, whether it becomes a WooCommerce attribute, a custom field, or content in the description. Bundles, digital downloads, pre-orders and gift cards were usually app features rather than platform features, so they migrate as data without the behaviour attached. Media needs re-uploading with alt text intact. Budget deliberate time for the last fifteen percent of the catalogue, and audit it against the old store afterwards rather than trusting the importer's success count.

Customer records move; passwords do not. They are stored as one-way hashes with a platform-specific algorithm and salt, so there is no export that can recreate a working login. Every returning customer will have to reset, which means one honest email explaining why, sent at the right moment, and a reset flow you have tested on mobile before you send it. Expect a support spike for a fortnight and staff it. Order history is a second decision. It imports as records for reference and reporting, but refunds, captures and gateway actions against old orders generally cannot be replayed through the new store — those transactions belong to the original processor. Keep the old admin readable, or export a permanent archive, for whatever retention period your accountant and tax authority require.

This single item determines more of the outcome than the rebuild does. Hosted platforms impose their own URL grammar — collection and product paths with a fixed prefix, and often the same product reachable at more than one address. WooCommerce uses different defaults again. Nothing carries across on its own, so every indexed URL needs a permanent redirect to its closest equivalent, published on day one rather than a week later. Build the list from three sources rather than one: the old XML sitemap, the indexed-pages report in Search Console, and server logs or analytics for the long tail that still earns links. Map one to one wherever a real equivalent exists. Bulk-redirecting whatever is left to the homepage is treated as a soft 404 and throws away exactly the pages you were trying to protect. Redesigning without losing SEO covers the same discipline in more detail.

• Export every indexed URL from sitemap, Search Console and server logs
• Map products, categories, blog posts and policy pages one to one
• Use 301, never 302, and never a bulk redirect to the homepage
• Keep the map live permanently; twelve months is not long enough

Somewhere in your app list is one with no comparable WooCommerce plugin, and finding it late is what turns a migration into a rescue. Inventory every app now, mark each as replaceable, rebuildable or lost, and price the rebuildable ones before committing. Recurring subscriptions are the hardest single item: stored payment tokens belong to the processor and the merchant account they were created under, so moving an active subscriber base means either a gateway-approved token migration or asking customers to re-authorise. Start that conversation with your processor before you start with the store. Gateways themselves need fresh onboarding, underwriting and live test transactions. Then run both stores in parallel: build on a staging domain, freeze catalogue edits, take a final delta of orders and customers, switch DNS at your quietest hour, and keep the old store reachable but out of the index while you watch errors.

If the store runs fine, revenue is modest, and nobody on your team wants to own a WordPress installation, the platform fee is buying you something real and you should keep paying it. It covers uptime, patching, a narrower PCI scope, a support queue and a compatibility guarantee between the pieces. The honest test is not whether you could save a few hundred dollars a month. It is who applies the security update in March. If the answer is nobody, or a freelancer you have never met, the saving is a loan against future downtime. Try the cheaper fixes first: cancel apps you stopped using, review your card rate once volume justifies it, drop a subscription tier, replace two apps with one. Move when the platform genuinely blocks something you need to build, not when the invoice merely annoys you. Choosing who does the work is a separate decision from the platform one.