Core entities export cleanly. The work concentrates on product modifiers, customer group pricing and the features BigCommerce provides natively that Shopify handles differently.
The entities move. Some of the product behaviour does not.
BigCommerce exposes its core entities well, so products, customers and orders generally come across without drama. Three areas consistently need real decisions, and all three are about how products are configured and priced.
Product modifiers are the first. BigCommerce separates variant-producing options from modifiers that adjust a product without creating a distinct sellable item: a personalisation field, an added service, a surcharge. Shopify’s model does not draw that line the same way, so each modifier has to be classified as a variant, a line-item property, an application or a separate product. That classification is the single largest source of variance in the project.
Customer group pricing is the second. BigCommerce provides group-level discounts and price lists natively, and businesses that use them are often running a trade operation alongside retail. Reproducing that on Shopify depends on the plan and on whether the relationship is genuinely B2B or simply a discount tier.
The third is app replacement. Both platforms have large application ecosystems and they do not overlap neatly. Reviews, loyalty, subscriptions and feed management each need an equivalent chosen, configured and, where possible, populated with the historical data that made them worth having.
Confirmed against your store, not assumed from this table.
| Entity | Normally transfers | Where a decision is needed |
|---|---|---|
| Products and variants | Yes, including images, SKUs and stock | Products whose option structure exceeds what Shopify holds in a single product |
| Product modifiers | Not as variants | Each modifier classified: variant, line-item property, application or separate product |
| Categories | Yes, as collections | Nested categories flatten, so hierarchy is rebuilt in navigation and linking |
| Customers and groups | Customer records yes, group pricing no | How trade pricing is reproduced, and on which Shopify plan |
| Price lists | Not directly | Whether these represent B2B catalogues, discounts or market pricing |
| Orders | Usually, as historical records | Retention window, and how refunds and partial shipments are represented |
| Pages and blog | Yes, with formatting review | Content that only existed to support a template or a widget |
| Redirects | The existing 301 list is exportable and worth keeping | Collapsing inherited chains rather than adding to them |
BigCommerce stores usually arrive with a redirect list already in place from earlier changes. Migrating it as-is creates chains, so it is rebuilt to point at final destinations.
Each is a build decision with a cost, not a mapping line.
A modifier adding an engraving, a surcharge or a service is holding commercial logic. Line-item properties handle some of it, applications handle some, and occasionally the right answer is that the product should have been a separate SKU all along.
Where price lists drive a genuine trade catalogue, the destination is a B2B configuration rather than a discount code. Where they are a loyalty tier, the answer is much cheaper. Establishing which one it is comes first.
Businesses running several BigCommerce storefronts have to decide between Shopify markets, expansion stores or consolidation. It is a commercial decision about catalogues, pricing and operations, and it changes the whole shape of the project.
Reviews, loyalty balances and subscription contracts live in applications, not in the platform. Reviews usually import. Loyalty balances and stored payment methods for subscriptions typically do not, and customers have to be told.
Classify the modifiers first. Most of the estimate variance is there.
BigCommerce routes translate more directly than most, which makes the exceptions matter more.
Because product and category routes usually map cleanly, the value of the work sits in the families that do not.
Where a slug can be preserved without harming clarity, it is preserved. Renaming routes during a replatform adds risk for a benefit that can usually be taken later.
Four parts that are not about the export at all.
Swipe the parts
Design
BigCommerce stores are often on a competent stock theme already, which makes a restrained Shopify implementation an easy recommendation and keeps the budget on the option and pricing work.
Systems
Every application and integration is inventoried, then replaced, rebuilt or retired. Cost is compared honestly, because application subscriptions differ between the platforms.
Proof
A sample migration weighted towards products with modifiers and group pricing, because those are where errors hide, followed by a reconciled full run.
Switch
A delta run, a planned switch, and the BigCommerce store kept live and reachable until the new store has traded successfully.
Almost all of it is options, pricing and applications.
A BigCommerce migration is priced from product configuration rather than from catalogue size.
Stores with genuine B2B price lists or multiple storefronts route to manual scoping. The estimator would return a band too wide to be worth quoting.
Published starting figures in GBP and USD, excluding VAT.
From-price or scoped after source review
Data only
From £1,000From $1,300
Products, customers, orders and content mapped into a Shopify store that already exists or is priced separately. Fixed once source access and a sample migration are reviewed.
Starting price · scoped after discovery
Migration and build
From £5,000From $6,500
Moving to Shopify and building the store in one project, so the data and the storefront land together rather than in two disconnected pieces of work.
Starting price
Plus, B2B, multi-market
From £8,000From $10,500
Shopify Plus, B2B, multi-market, multi-language, custom integrations or headless work. These configurations are sized after discovery, not instant-priced.
Starting price · scoped after discovery
Application subscriptions on the destination store are yours and are listed in the scope rather than absorbed. Estimator output is indicative and non-contractual.
Each one is classified before the import. Some become variants, some become line-item properties, some need an application, and occasionally the honest answer is a separate product. It is the decision that most affects both the price and the storefront afterwards.
Not in the same way as BigCommerce on a standard plan. Where the requirement is a genuine trade catalogue, the destination is a B2B configuration. Where it is a discount tier, there are simpler answers. Which one it is gets established in discovery.
The list can be exported and it is worth having, but it is rebuilt rather than copied. Migrating an old redirect list unchanged and adding a new layer on top produces multi-hop chains that lose value at every step.
Usually not. Most review applications support an import, so historical reviews can be preserved. Loyalty balances and subscription payment methods are a different matter and generally cannot transfer, which needs a customer communication plan.
One realistic example of your option and modifier setup tells us more about the project than the catalogue size.
