BigCommerce takes no cut of your sales. It bills you for making them anyway.

No, on any plan, with any payment gateway. This is BigCommerce's headline advantage and it is real. Shopify adds up to 2% on the Basic plan to every order processed through an external gateway, dropping to 1% and 0.5% on higher tiers, and waives it only if you use Shopify Payments. BigCommerce takes nothing. Connect Stripe, PayPal, Braintree, Authorize.net or a processor you have negotiated your own rates with, and you pay that processor and nobody else. For a store doing $500,000 a year on an external gateway, the Shopify surcharge alone would be $10,000 annually, so this is not a rounding difference. On this dimension BigCommerce matches a custom store exactly: both connect straight to a processor with no platform cut. What BigCommerce charges instead is a monthly plan whose tier is set by your sales volume, which is a different mechanism for the same outcome and the thing worth reading the next answer about.

Every BigCommerce plan carries a cap on trailing twelve-month online sales, and crossing it moves you to the next plan whether or not you asked. Standard covers up to $50,000, Plus up to $180,000, and Pro up to $400,000, with Pro adding a further charge for each additional block of sales above that before Enterprise takes over. The mechanism is worth understanding clearly: your monthly bill is indexed to your revenue rather than to what you are using the platform for. A store that grows from $45,000 to $55,000 in annual sales without changing a single feature moves from $39 a month to $105 a month, a $792 annual increase caused entirely by selling more of the same thing on the same store. It is more predictable than a percentage of every order and it is less painful than Shopify's transaction fee for most merchants, but it is still a bill that rises with your success. A custom store's hosting cost does not move when your revenue does.

Take a representative store rather than the headline plan price. Two years on Standard at $39 a month is $936. Crossing the $50,000 sales threshold moves it to Plus at $105 a month, so three years there is $3,780. Apps at $75 a month is $4,500 across the five years, which is a lower app bill than the equivalent Shopify store because more is built in. A premium Stencil theme is around $250 once. That totals $9,466 across five years, and every dollar of it except the theme is recurring, so year six starts again at roughly $2,160. The app number is the one most likely to be wrong in either direction for your store: BigCommerce includes faceted search, customer groups, multi-currency and abandoned-cart recovery that would be paid apps elsewhere, so a store whose needs are covered by the built-ins might spend $25 a month, while one needing a specific ERP or subscription-billing integration can spend $300. Price your own list rather than trusting an average.

More than on Shopify, and this deserves credit. BigCommerce ships an open-source checkout that you can fork and modify on any plan, plus a checkout SDK for building your own front end against their APIs. There is no Plus-tier gate charging $2,300 a month for the privilege, which is a meaningful structural difference between the two platforms. The limits are real but narrower than most comparisons suggest: you are customizing a checkout, not designing a purchase flow from scratch, and the order model, the field set and the payment step behave the way BigCommerce's backend expects. Forked checkout code also becomes yours to maintain against their upstream changes. A custom store starts from your funnel rather than from someone's default: one page or several, guest or account-required, upsells keyed to cart contents, gift messaging, local pickup, a subscription toggle at product or cart level. The gap here is smaller than the one against Shopify, and it is still the difference between adjusting a system and owning one.

BigCommerce is better than Shopify on the structural pieces and still short of a custom build. You can change the product URL base, remove the default prefix, and shape category paths in ways Shopify simply does not permit, so the flat /products/ and /collections/ complaint that applies to Shopify does not apply here. Titles, descriptions, canonicals and sitemaps are all editable, and BigCommerce emits product markup for Google out of the box. The remaining differences are speed and precision. A hosted storefront carries platform weight that a custom page does not, and Google scores page speed and stability as ranking inputs. On structured data, filling out variant-level detail, shipping information, review aggregates and category listing markup completely often means an app or theme changes, and each of those is a dependency that can drift. A custom store writes that markup into the template from the same data the page already displays, so it cannot fall out of sync and does not depend on a subscription staying current.

BigCommerce is broadly comparable to Shopify and slower than a custom build, and the reason is architectural rather than a hosting quality gap. A hosted storefront runs a theme framework, a template layer and a set of scripts on every page, and each installed app adds its own code to that load. A clean BigCommerce store shows its main content on mobile in roughly two to three seconds. Add five apps for reviews, live chat, popups, loyalty and analytics and that stretches toward four seconds, because every app is more code the visitor's browser downloads and runs before the page becomes usable. BigCommerce's advantage is that it needs fewer apps than Shopify for the same feature set, so the degradation curve starts later. A custom store sends the finished page straight to the browser with no framework underneath, holds under a second across the whole funnel including cart and checkout, and does not get slower as features are added, because features run on the server rather than in the visitor's browser.

BigCommerce meters API calls by plan tier, and it is the constraint most likely to catch a store that did its research on price alone. Every integration you run consumes that budget: an ERP syncing inventory, an accounting connector pulling orders, a warehouse system posting fulfilment updates, a marketplace listing tool, a custom dashboard. For a store with two or three light integrations the ceiling is invisible. For one with a real operational stack it becomes a scheduling problem, where syncs get batched and slowed to stay inside quota, or a reason to move to a higher plan for headroom rather than for features. The pattern to watch for is a plan upgrade driven by integration volume rather than by anything customer-facing. A custom store talks to your database directly with no metered budget between your code and your data, and integrations are limited by what the other system permits rather than by your storefront plan.

You own your data and you rent the store. BigCommerce gives good export access to products, customers and orders, and its API is genuinely open, so extracting information is not the fight it can be elsewhere. What does not come with you is the store itself. The theme runs inside BigCommerce's Stencil framework, the catalog structure follows their data model, the checkout behaves the way their backend requires, and the apps are integrations with their platform rather than software you hold. Stop paying and the storefront goes offline; the export file is a list of products and customers, not a working store. Leaving means rebuilding, which is exactly the switching cost that makes a plan price rise easy to absorb and hard to argue with. A custom store is source code, a database and files on a server you control. Change hosts because one is cheaper, hand the codebase to a different developer, or park the store during a slow season and bring it back without asking anyone.

For the functionality most stores use, yes: catalog with variants and options, cart and checkout, discounts and promotions, inventory, shipping rate calculation, customer accounts and order history, and payment through the processor of your choice. Several things BigCommerce charges for as built-ins are ordinary work in a custom build, including faceted filtering, customer groups with tiered pricing, and abandoned-cart follow-up. Where BigCommerce is harder to replicate is the breadth of what arrives configured on day one: multi-currency handling, native marketplace and social channel connectors for Amazon, eBay, Meta and Google, B2B price lists and quote workflows, and a large catalog of pre-built integrations with ERP and accounting systems. Each of those is buildable, and each costs real money to build. If your operation depends on several of them at once, that bundle is doing genuine work and a custom build has to earn its way past it feature by feature rather than on cost alone.

Six to ten weeks for most stores, depending on catalog size and how many integrations need rebuilding. BigCommerce's API is one of the better ones to migrate away from, so pulling products, variants, customers, orders and category structure is largely scripted rather than a manual spreadsheet exercise. The work that consumes the schedule is rebuilding whatever your apps were doing, reshaping the catalog around how your customers search rather than how the platform organized it, and mapping every product and category address Google has indexed to its new home with automatic forwarding in place before launch rather than after. Stores with subscription billing, B2B price lists, multi-currency pricing or a live ERP connection need more planning at the start. Your existing store stays live and taking orders until the new one is built and tested, so there is no trading downtime, and search rankings generally hold through a careful migration and often improve because the new store is faster.

When the platform is doing operational work rather than hosting a catalog. B2B selling with customer groups, price lists, quote workflows and account-specific pricing is a genuine strength and expensive to build from scratch. Multi-currency and multi-storefront operations get real infrastructure for the plan fee. Stores selling across Amazon, eBay, Meta and Google through native connectors managed in one dashboard are buying integration work they would otherwise commission. Teams running a headless build where BigCommerce is the commerce backend behind their own front end get a mature API and stay off the storefront performance question entirely. And stores validating a product idea should not commission a custom build for something that may not exist in six months. The case for moving is strongest when your bill is rising because your revenue crossed a threshold rather than because your requirements changed, when the app stack keeps growing, and when the storefront is doing nothing a purpose-built store could not do faster and without a monthly plan.