When a plan tier starts costing more than it saves

First, plan tiers linked to sales volume: growth pushes you up a tier and the increase is not tied to any extra cost you incurred. Second, API and resource limits that force integration architecture around a quota rather than around your business. Third, platform-imposed rules — what you can sell, what you can customise, what the checkout may do — that were fine until one of them collided with your model. If none of these apply and the store runs well, staying is cheaper than any migration you will be quoted.

• Plan cost tied to revenue rather than usage
• API limits shaping integration design
• Platform rules colliding with your business model
• Not applicable to you? Then stay — moving is not free

BigCommerce holds structured commerce data and exposes it properly, so products, variants, categories, customers, orders and content export cleanly compared with builder-based platforms. Variant modelling still needs mapping — option sets do not map one-to-one onto WooCommerce attributes and variations — but the data quality is usually good enough that the mapping is a decision exercise rather than a data-cleaning one. Customer passwords, as always, do not transfer, so plan the reset communication as part of launch.

The storefront theme does not move. Any app installed from the platform marketplace needs a WooCommerce equivalent chosen and configured. Checkout customisations and scripts are rebuilt against a different checkout. Platform-native features you rely on — customer groups, price lists, product filtering behaviour, promotion rules — each need a specific replacement identified before the project starts, not discovered mid-build. Write that inventory down: it is usually the difference between an accurate quote and an unpleasant one.

Product and category URL patterns differ between the platforms, which means most of your indexed URLs will change. The discipline is the same as any migration and it is not optional: export the complete live URL list, prioritise by clicks from Search Console, map every old URL to a new one, verify redirects on staging, and watch coverage daily for two weeks after launch. Pay particular attention to faceted and filtered URLs, and decide deliberately which combinations should be indexable — category page SEO covers the rules that keep filters from flooding the index.

Cost that tracks what you use rather than what you earn, no ceiling on customisation, direct database and API access for integrations, and complete ownership of the checkout and the customer relationship. For stores whose plan tier has outgrown their needs, the recurring saving alone often funds the migration within a year. The frontend also stops being constrained by the platform's theme layer, which is what makes a fast storefront a design decision rather than a negotiation.

Hosting, updates, security, backups, uptime and compliance posture become yours. So does performance: no platform is quietly optimising the storefront for you any more. That is exactly why the plugin stack and the storefront architecture deserve deliberate decisions in the migration plan — a WooCommerce store assembled carelessly can be slower and less reliable than the hosted platform it replaced, and that outcome is entirely avoidable but not automatic.

Write down your current annual platform cost, the cost of the apps you pay for on top, and the specific limitation that triggered this. Then price the migration and the ongoing maintenance you will now own. If the recurring saving does not pay back the project within roughly a year, the limitation had better be genuinely blocking, because otherwise you are buying a lateral move. The cost estimator gives a planning range for the project side of that comparison.