When a BigCommerce 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 make a quota, not your business, the thing your integrations are designed around. Third, platform-imposed rules — what you can sell, what you can customize, what the checkout may do — that were fine until one of them collided with your model. If none of the three applies and the store runs well, stay; no quote will beat what you already have.

• Put last year's plan fees next to what hosting would cost at the same volume
• Count the integrations shaped by a call quota instead of by your workflow
• List what you have wanted to change in the checkout and could not
• If all three lists come back empty, keep the plan you have

BigCommerce holds structured commerce data and exposes it properly, so products, variants, categories, customers, orders and content export cleanly compared with builder-based platforms. The route matters. The CSV export covers the catalog, while the Catalog and Orders APIs are what you need for variant-level detail and order history. Variant modeling still needs mapping, because option sets do not map one-to-one onto WooCommerce attributes and variations — but the data quality is usually good enough that the mapping asks for decisions, not data cleaning. Customer passwords stay behind on BigCommerce's side, so customers choose new ones on first login, and they should hear that from you before they hit the error.

The storefront theme does not move. Any app installed from the platform marketplace needs a WooCommerce equivalent chosen and configured. Checkout customizations and scripts are rebuilt against a different checkout. Platform-native features you rely on (customer groups, price lists, product filtering behavior, promotion rules) each need a specific replacement identified before the project starts, not discovered mid-build. Write that inventory down before anyone quotes: on a typical store it runs to a dozen or more line items, and it is the difference between an accurate estimate and an unpleasant one.

Most of your indexed URLs will change. BigCommerce's default short URL setting puts products at the root, as /product-name/, while WooCommerce prefixes them with /product/ and categories with /product-category/. A store that has renamed products over the years also carries its own list of 301s in BigCommerce's redirect settings, and those old addresses need a destination too. Export the live URL list and the existing redirects, prioritize by clicks from Search Console, map every old URL to a new one, verify 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 usage instead of revenue, no ceiling on customization, and complete ownership of the checkout and the customer relationship. Direct database access is the underrated one. A SQL query against your own orders table is something no hosted platform hands you. Where the plan tier has outgrown the store's needs, the recurring saving alone often funds the migration within a year. The frontend stops answering to the platform's theme layer as well. A fast storefront becomes a design decision rather than a negotiation.

Everything BigCommerce ran under the plan fee (hosting, updates, security, backups, uptime, compliance) is yours after the move. So is performance: no platform is quietly optimizing the storefront for you any more. PCI scope is the one people misjudge: hosted payment fields keep you in SAQ A, and the moment card data touches your own page you are answering SAQ A-EP instead. 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 BigCommerce store it replaced. 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. Otherwise you are buying a lateral move. The cost estimator gives a planning range for the project side of that comparison.