Migrating away from BigCommerce to a custom Solidus store

What BigCommerce is, and who should stay on it

BigCommerce is a hosted ecommerce platform. You pay a monthly plan, BigCommerce runs the servers and the security of the platform, and you build your shop inside the boundaries it sets. Among the hosted platforms it has always been one of the more open and one of the more technical. The admin is capable, the catalogue model handles variants and large ranges without a fight, and the developer documentation is genuinely good. If you are comparing it with the field, I set out where it sits against the others in the platform comparison for a UK shop.

I build custom shops on Solidus, the open source Rails ecommerce framework, so you know where I stand. That is exactly why I will start with the honest half. If your shop is early, simple, or modestly sized, and the buying experience is a channel rather than the thing customers come to you for, BigCommerce is a reasonable place to be and leaving it would be a waste of money. This article is not for that shop. It is for the business that has outgrown the platform: the one whose bill climbs every time it has a good year, whose checkout will not do the one thing the business actually needs, and whose owner has started to wonder what it would take to own the shop outright.

This is a platform specific piece. The deep, platform independent questions, how customer records, products, orders, saved cards and subscriptions actually move, belong to the data type guides in this series, and I link each one where it matters rather than repeat it. Start with the overview, what moves and what does not, and come back.

What you own, and what the platform holds

The useful way to look at any hosted platform is to ask what you walk away with on the day you leave.

On BigCommerce you own your data and you can get most of it out cleanly, which is to the platform's credit and more than some rivals manage. What you do not own is the machinery around the data: the checkout, the theme engine, the apps, the hosting and the payment configuration. Those are rented, and they stay behind. None of that is a scandal. It is simply what hosted means, and the point of this article is to help you price it honestly before you decide whether the move is worth it.

The bill that grows with your success

Here is the pressure specific to BigCommerce, and it is a real one. The plan you are on is gated by your sales.

On 1 June 2026 BigCommerce renamed its self serve plans and reset the thresholds.¹ The entry plan, Core, costs 39 US dollars a month billed monthly or 29 billed annually, and it covers a shop up to 30,000 dollars of trailing twelve month sales. Cross that line and the account moves up to Growth, at 105 dollars a month or 79 annually, which runs to 100,000 dollars. Above that sits Scale, at 399 dollars a month or 299 annually, and Scale carries a monthly sales cap of 33,333 dollars, which is roughly 400,000 dollars a year, with a 0.9% charge on sales above the cap. The top self serve tier, Performance, starts at 1,499 dollars a month and adds 0.6% on sales above its own ceiling.¹ The measurement is in US dollars, which is itself worth noting for a shop that banks in pounds: the ceiling you are judged against moves with the exchange rate, not with your accounts.

Read that structure plainly and you see the shape of it. The better your shop does, the higher the tier you are pushed onto, and past a point your own growth is charged by the percentage. The plan fee is small. The mechanism behind it is a bill that scales with the very thing you are working to grow.

Now the fair half, because a one sided piece is not worth reading. Unlike a platform that takes a cut of every order routed through an outside provider, BigCommerce still charges no per sale transaction fee when you use one of its embedded payment providers, and that list covers the gateways most shops actually use: Stripe, PayPal in its several forms, Adyen, Klarna, Worldpay and BigCommerce's own payment product among them.² For a shop on a mainstream gateway that is a genuine advantage, and I would not pretend otherwise. What changed on 1 June 2026 is the edge case: an order processed through a provider that is not on the embedded list now carries an Open Payment Provider Fee, billed to you and not the shopper, at 2% on Core, 1% on Growth and 0.6% on Scale.³ If your gateway is on the list, you pay none of it. If you deliberately chose an off list provider for a better rate or a market specific method, that choice now has a price.

So the honest summary is this. BigCommerce does not tax each individual sale the way some rivals do, and that is a point in its favour. It taxes your growth through the plan tiers and the percentage on sales above each cap, and for most shops that is the bill that eventually stops making sense.

On BigCommerce	What it costs you
Plan tier	Set by trailing twelve month sales in US dollars, forced upward as you grow1
Sales above the Scale cap	0.9% on sales over 33,333 dollars a month; 0.6% on Performance1
Embedded gateway (Stripe, PayPal, Klarna and so on)	No per sale platform fee, a real advantage2
Off list gateway	Open Payment Provider Fee, 2% to 0.6% by tier, since 1 June 20263

The export and the API, honestly

The good news first, and it is real. BigCommerce is more open than most hosted platforms, so the raw material of a migration comes out without a fight.

Products and customers export to CSV from the control panel, and the same files can be reimported, which makes the catalogue and the customer list a mapping exercise rather than a rescue operation.⁴ Orders are the exception worth knowing before you plan: they export, but BigCommerce does not accept orders back in by CSV, so order history moves through the API, not a spreadsheet.⁵ For the detail of how each of these data types maps onto a new shop, which fields matter and where the traps are, I have written a guide per type: products and catalogue data, customer accounts and addresses, and order and purchase history.

For anything beyond a flat file, BigCommerce gives you a proper API, and this is where it earns its reputation. There is a REST Management API for server side reads and writes, a GraphQL Admin API that queries and mutates store data on the server, and a GraphQL Storefront API that serves products, customers and carts from the shopper's point of view, alongside account and B2B APIs.⁶ For a migration that means I can pull your full history programmatically, reconcile it, and load it into the new shop with every record checked, rather than trusting a one click export.

The one number to plan around is the rate limit. API access is throttled by a quota that refreshes every thirty seconds: a Scale store gets 60,000 requests an hour, which is 450 in each thirty second window, while Growth and Core stores get 20,000 an hour, or 150 per window, and a request over the limit comes back as a 429 with a header telling you how long until the quota resets.⁷ For a shop with tens of thousands of orders that is not a wall, but it does mean the export is a paced, scripted job rather than a single afternoon, and it is one reason I rehearse the full import on a copy of your data before anyone commits to a date.

One hard ceiling, the same on every platform and worth stating plainly: passwords do not come across. BigCommerce will not export customer passwords in a CSV, and a customer imported without one is simply asked to reset it on their next visit.⁴ That is correct and expected behaviour, not a failing, and the customer accounts guide explains how I turn that reset into a planned relaunch message rather than a cutover day surprise.

The traps that are particular to BigCommerce

Every platform has a handful of places where leaving is harder than the clean CSV export suggests. On BigCommerce these are the ones to look at early.

The checkout and the payment setup are the platform's, not yours. The hosted checkout is configured, not coded. You can adjust and extend it within the limits BigCommerce allows, but the flow itself belongs to the platform, which is fine until the business needs a step the platform does not offer: a delivery slot, a trade customer's negotiated pricing, an unusual tax or invoicing rule. On a shop you own, the checkout is your own application code.

Saved cards live with the gateway, not with BigCommerce. This is the single most important thing to settle before you move, and it is good news more often than owners expect. A customer's stored card is held, in tokenised form, by the payment provider, not by BigCommerce. So if your shop already takes payment through, say, Stripe, and the new Solidus shop connects to that same Stripe account, the saved cards simply stay where they are and keep working. Where the cards sit inside a provider you are also leaving, moving them is the hardest part of any migration and may need the losing provider's cooperation. I treat this as the first question, not the last, and the payment tokens and saved cards guide walks through exactly how to confirm it.

Subscriptions run through apps, so there is no single export. BigCommerce has no native recurring billing; a subscription shop runs on an app or a gateway that supports stored payment instruments.⁸ That matters at migration time because the subscriptions, their billing dates, their saved payment methods and their histories live in that app or that gateway, each with its own rules for getting the data out. Confirm the route before you commit, exactly as the subscriptions and recurring payments guide sets out.

The theme does not travel. BigCommerce storefronts are built on Stencil, its own theme framework, which uses Handlebars templates and a BigCommerce specific object model.⁹ It is a decent system, but a Stencil theme is written for BigCommerce and does not port to another platform. The front end is a rebuild, which is a cost on the day and, if you want a shop that looks like your brand rather than a themed template, an opportunity.

The URLs are the platform's, and they carry your rankings. BigCommerce uses its own URL structure for products and categories. When you move, every one of those addresses has to redirect to its new home, or the traffic and the rankings behind it drain away through a wall of 404 pages. Google's own guidance is to map every old URL to its new one, use permanent 301 redirects straight to the destination, and keep them for as long as possible.¹⁰ The redirect map is the least glamorous and most valuable deliverable of the whole project, and the products and catalogue guide covers how it is built.

The app marketplace is a convenience that becomes a dependency. A grown BigCommerce shop usually runs a string of paid apps: reviews, subscriptions, feeds, tax, invoicing. Each is a monthly fee and each is another company holding your customer data. When you move, the features those apps provided have to be rebuilt or replaced, and that list is part of the honest scope.

The honest move to a shop you own

A migration off BigCommerce onto a custom Solidus store is not a button. It is a project, and done properly it is a calm one, because Solidus is an ordinary Ruby on Rails application and a PostgreSQL database that you own outright, on servers you control, which you can hand to any Rails developer tomorrow.¹¹ Here is the honest shape of it.

The sequence is the one I follow for every platform. Decide, in discovery, what actually moves and who on your side owns the data. Build the new shop and write the import scripts against a copy of your real BigCommerce export, running them again and again until the result is clean. Run the two shops in parallel for a few weeks with the catalogue frozen, rehearse the final import at least twice, and cut over on a quiet weekday morning with the old shop left untouched for thirty days as your fallback. Each data type follows its own guide: products, customers, orders, payment tokens and subscriptions.

Two questions decide whether the move is simple or hard, and both are about payments, so I settle them first. Can your saved cards stay with their current gateway, reconnected to the new shop? And can every live subscription be moved with its billing date and payment method intact? If the answers are yes, the rest is careful data work. If they are no, we know the real cost before anyone signs, which is the entire point of asking first. For the money side of the decision over a five year horizon, build and hosting included, read the five year total cost of ownership, and for the deeper question of who holds your records and on what terms, who actually owns your business data. The same plan would move you to several destinations; I happen to build on Solidus, and the Shopify version of this piece, migrating away from Shopify, covers the near neighbour.

A worked example

Let me make it concrete with an invented shop.

Saltmarsh Kitchen (saltmarshkitchen.example) is a Brighton kitchenware business doing about 900,000 pounds a year online, which in the dollars BigCommerce measures is comfortably past the Scale cap. It has been on BigCommerce for four years, runs on the Growth plan plus a Scale upgrade forced by last year's trading, and pays for a reviews app, a subscriptions app for its monthly spice club, and an invoicing app for the trade accounts that supply local cafes. Its owner wrote to me after the year end numbers, with two complaints. The platform bill had risen every year the shop grew, and the one feature the business really wanted, a build your own gift box where the customer picks six items at a fixed price, was quoted as an app that nearly fit and a compromise on the checkout.

The export was the easy part, exactly as it should be on BigCommerce. Products and customers came out as CSV and the order history came through the API, paced around the rate limit over a couple of scripted evenings.⁷⁴⁵ The passwords stayed behind, as they always do, so the plan included a service message to every account holder before cutover and a short welcome page that set a new password on first visit.⁴

The two payment questions carried the risk, and we answered them first. The shop's cards were vaulted with Stripe, so the new Solidus shop connected to the same Stripe account and the saved cards never moved at all. The spice club subscriptions lived in the subscriptions app, so before any date was agreed I confirmed with the app's provider that the plans, billing dates and payment methods could be exported and reloaded. Only once both answers were in hand did we set a cutover week in the shop's quietest month, well away from Christmas.

The gift box that the old checkout could not do became a few hours of ordinary Rails code in the new one, tested like everything else. Saltmarsh now owns its shop, pays for hosting rather than a plan that climbs with its sales, and the spice club runs on billing logic the business can see and change. That is an invented shop, not a client story, but every step in it is a step I would take.

When you should stay, and when to move

I will end where I began, because the honesty is the point.

Stay on BigCommerce if your shop is below the size where the plan tiers bite, if a mainstream embedded gateway covers your payments, and if the hosted checkout does what your business needs. At that size the platform runs your shop for a modest fee, handles the hosting and the security, and leaving would cost more than it saves. BigCommerce is a capable platform and plenty of shops are right to stay on it.

Move when your own growth has become the thing you are paying for, when the checkout or the subscriptions logic has hit a wall the platform cannot take down, and when you would rather spend the budget on a shop you own than on rent that rises with every good year. If that is where you are, the move is a known quantity, and the result is yours.

If you want a second opinion on your own numbers, bring them to a free workshop, and the first two weeks of work are on me. We will go through what would move cleanly, what the two payment questions answer for your shop, and whether a move off BigCommerce actually pays for you. Sometimes the honest answer is to stay, and if it is, I will say so. My rates are on the pricing page.

Footnotes

1. BigCommerce, Plan and pricing updates 2026 (plan names Core, Growth, Scale and Performance, monthly and annual prices, trailing twelve month sales thresholds, overage rates, effective 1 June 2026), accessed 14 November 2026, https://www.bigcommerce.com/dm/plan-pricing-updates-2026 ↩ ↩² ↩³ ↩⁴

2. BigCommerce, Embedded Payment Providers (the providers that carry no Open Payment Provider Fee, including Stripe, PayPal, Adyen, Klarna, Worldpay and BigCommerce Payments), accessed 14 November 2026, https://www.bigcommerce.com/payments/embedded-payment-providers/ ↩ ↩²

3. BigCommerce, Setting the record straight: what is actually changing with our pricing on June 1 (the Open Payment Provider Fee and the embedded provider list), accessed 14 November 2026, https://www.bigcommerce.com/blog/bigcommerce-self-serve-pricing-changes/ ↩ ↩²

4. BigCommerce Help Center, Importing and exporting customers (customer data exports to CSV, passwords cannot be exported, an imported customer without a password goes through the reset process), accessed 14 November 2026, https://support.bigcommerce.com/articles/en_US/Knowledge/Importing-Exporting-Customers ↩ ↩² ↩³ ↩⁴

5. BigCommerce Help Center, Data transfer in BigCommerce (products and customers transfer by CSV, orders cannot be imported by CSV and move through the API), accessed 14 November 2026, https://support.bigcommerce.com/articles/en_US/Knowledge/Data-Transfer-in-BigCommerce ↩ ↩²

6. BigCommerce developer documentation, GraphQL API overview (the GraphQL Admin API for server side store data, the GraphQL Storefront API for products, customers and carts, alongside Account and B2B APIs), accessed 14 November 2026, https://docs.bigcommerce.com/developer/api-reference/graphql/overview ↩

7. BigCommerce developer documentation, API rate limits (Scale 60,000 per hour or 450 per thirty seconds, Growth and Core 20,000 per hour or 150 per thirty seconds, quota refreshed every thirty seconds, 429 on exceeding it), accessed 14 November 2026, https://docs.bigcommerce.com/docs/start/best-practices/api-rate-limits ↩ ↩²

8. BigCommerce Help Center, Setting up recurring billing (recurring billing needs an app or a specific payment gateway that supports stored payment instruments), accessed 14 November 2026, https://support.bigcommerce.com/articles/en_US/Knowledge/Setting-up-Recurring-Billing ↩

9. BigCommerce developer documentation, Stencil (the Handlebars based theme framework for BigCommerce storefronts), accessed 14 November 2026, https://docs.bigcommerce.com/docs/storefront/stencil ↩

10. Google Search Central, Site moves with URL changes (map every old URL to its new one, use permanent 301 redirects straight to the destination, keep them in place), accessed 14 November 2026, https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes ↩

11. Solidus, solidusio/solidus repository and licence on GitHub (open source Ruby on Rails ecommerce under the BSD 3 clause licence), accessed 14 November 2026, https://github.com/solidusio/solidus ↩