BigCommerce Store Creation: Technical Setup, Stencil Themes & API Architecture

1. The BigCommerce Architecture Paradigm

Before diving into execution, developers must comprehend what BigCommerce fundamentally is. It is a multi-tenant SaaS platform constructed with a highly modular B2B-first feature set. Unlike platforms that charge penalties for using third-party payment gateways, BigCommerce imposes no transaction fees on any plan.

The system is bifurcated: a robust backend catalogue/order management engine exposed via high-throughput REST APIs, and a frontend presentation layer powered either by their native Stencil framework or a headless decoupled application. For merchants running high-SKU catalogues or complex multi-channel operations, this separation of concerns provides a scalable technical foundation.

This architectural split means that BigCommerce's catalogue API (the Management REST API v2/v3) operates independently of the visual presentation layer. In practical terms, when you query the management API for product inventory, you are hitting the core microservices layer. The storefront, whether Stencil-based or entirely custom headless, relies on separate view controllers and the GraphQL Storefront API to retrieve that data. By strictly enforcing this boundary, BigCommerce guarantees that an overloaded frontend cache or poorly optimised Handlebars template will never destabilise the merchant's ability to process orders via external API integrations.

Such segregation ensures that you can comfortably scale a headless frontend application without requiring massive database locks or risking a complete outage of the administration panel during high-traffic Black Friday sales. The API handles catalogue synchronization directly with third-party Enterprise Resource Planning (ERP) systems, allowing for asynchronous, eventual-consistency state management.

Platform Tiers and Constraints

Choosing a BigCommerce plan is less about feature-gating and more about gross merchandise value (GMV) and API throughput thresholds. The Standard, Plus, Pro, and Enterprise tiers scale these constraints accordingly. While most basic storefront functionality remains consistent, features like persistent cart, stored credit cards, and customer group price lists become crucial demarcators at scale.

I frequently observe engineering teams miscalculating the impact of these rate limits during initial migration. An integration that worked perfectly on staging with 50 products will spectacularly crash when executing a full bulk update across 20,000 SKUs on a Standard plan. While Enterprise plans allow negotiation of limits (often starting at 400 requests per 30 seconds), developers must still implement exponential backoff mechanisms in their integration middleware. The API communicates rate limit status via standard HTTP headers (X-Rate-Limit-Time-Reset-Ms, X-Rate-Limit-Requests-Left), allowing middleware to dynamically throttle itself before triggering a 429 Too Many Requests error.

2. Stencil CLI Deep-Dive and Local Development

The native frontend engine for BigCommerce is Stencil. If you are migrating from Shopify, prepare for a significant operational shift. Stencil relies on Handlebars.js rather than Liquid. It enforces a strict separation of logic and presentation, requiring developers to request specific contextual data via YAML frontmatter at the top of template files.

Local development relies heavily on the Stencil CLI, which creates a proxy server that connects your local filesystem templates directly to the live store's data. This means that running stencil start creates a live tunnel using tools like ngrok to stream your actual store data (not a mocked database) to your local environment. You view the live catalogue exactly as it appears in the database.

Understanding Stencil Configuration Files

A typical BigCommerce theme directory contains three critical configuration files that orchestrate the build process and merchant UI. The most complex of these is the stencil.conf.js, which acts as the core Webpack configuration file. It dictates how SCSS is compiled, how JavaScript modules are bundled, and sets up the local development proxy.

Below is a heavily annotated example of a complete stencil.conf.js file to illustrate the pipeline configuration:

/**
 * stencil.conf.js - The core Webpack and CLI config for BigCommerce Stencil
 */
const webpack = require('webpack');
const path = require('path');

module.exports = {
    // The storeUrl points to the live store. Stencil uses this to proxy API requests.
    storeUrl: 'https://store-xyz123.mybigcommerce.com',
    // The port for the local development server (defaults to 3000)
    port: 3000,
    // Configuration for ngrok, allowing external testing on mobile devices
    tunnel: true,
    
    // Webpack configuration block
    webpack: {
        mode: 'development',
        entry: {
            theme: './assets/js/theme.js',
            checkout: './assets/js/checkout.js'
        },
        output: {
            path: path.resolve(__dirname, 'assets/dist'),
            filename: '[name].bundle.js'
        },
        module: {
            rules: [
                {
                    test: /\.js$/,
                    exclude: /node_modules/,
                    use: {
                        loader: 'babel-loader',
                        options: {
                            presets: ['@babel/preset-env']
                        }
                    }
                },
                {
                    test: /\.scss$/,
                    use: [
                        'style-loader', // Injects CSS into DOM
                        'css-loader',   // Resolves CSS imports
                        'sass-loader'   // Compiles Sass to CSS
                    ]
                }
            ]
        },
        plugins: [
            new webpack.ProvidePlugin({
                $: 'jquery',
                jQuery: 'jquery'
            })
        ]
    }
};

The second critical file is config.json. This file defines the theme's feature flags, typography variables, layout settings, and colour palettes. Crucially, it manages theme versioning. When a merchant uses the BigCommerce control panel to edit the theme, their changes are saved as a custom configuration layer. If you, as the developer, update the local codebase, you must bump the version string inside config.json (e.g., from "1.0.5" to "1.0.6"). When you upload the new bundle, the version bump triggers the platform to safely merge your code changes with the merchant's saved configurations, downloading the latest schema successfully.

The schema.json file controls the admin UI for the Page Builder interface, defining the specific colour pickers and toggle switches available to non-technical users.

The Stencil Development Workflow

To begin building, install the Stencil CLI via Node.js. (Use nvm to lock to the supported LTS version to avoid Webpack compilation errors).

npm install -g @bigcommerce/stencil-cli
cd my-cornerstone-theme
stencil init

The CLI will prompt you for your Store URL and a Stencil CLI Access Token. Once authenticated, boot the local proxy with stencil start. The CLI intercepts API calls, forwards them to your SaaS backend, and serves the markup locally with hot module replacement (HMR).

When you complete a feature sprint, deployment is managed via the CLI. The command stencil bundle parses the theme, lints the config files, validates Handlebars syntax, and generates a deployable .zip archive. This zip file contains the fully compiled SCSS, minified JS, and optimized Handlebars templates. You can then upload it manually or push it directly:

stencil push --activate

This uploads the bundled theme to the store and instantly sets it as the active theme. I always advise configuring this within a GitHub Actions pipeline rather than relying on manual developer uploads to guarantee version parity across environments.

3. Handlebars Templating and Context Injection

Unlike Liquid, which evaluates on the server and allows developers to freely traverse the entire database through associative loops, Stencil injects a predefined JSON context into Handlebars templates based on the current page type and specific YAML frontmatter requests. This strict scoping guarantees that a developer cannot accidentally execute an unindexed database query that destroys server performance.

Registering Custom Handlebars Helpers

BigCommerce includes dozens of built-in helpers (e.g., {{cdn}}, {{getImage}}). However, developers often need bespoke string manipulation or logic. You register these within the JavaScript layer, typically inside assets/js/theme/global.js, allowing you to manipulate the DOM or run client-side formatting when the product options are modified by the user.

A Complete Product Page Template

To truly understand the Handlebars context, consider a full templates/pages/product.html file. Notice how we use {{product.name}}, {{product.description}}, {{product.price.with_tax}}, and loop through options with {{#each product.options}}. The form submits directly to the BigCommerce cart action handler using {{product.cart_url}}, while conditional logic like {{#if product.out_of_stock}} controls the UI.

<!-- templates/pages/product.html -->
---
product:
    videos:
        limit: {{theme_settings.productpage_videos_count}}
    reviews:
        snippet: true
        limit: {{theme_settings.productpage_reviews_count}}
---
{{#partial "page"}}
<div class="productView">
    <section class="productView-images" data-image-gallery>
        <figure class="productView-image">
            <img class="productView-image--default"
                 src="{{getImage product.main_image 'zoom_size' (cdn theme_settings.default_image_product)}}"
                 alt="{{product.main_image.alt}}" title="{{product.main_image.alt}}">
        </figure>
        <ul class="productView-thumbnails">
            {{#each product.images}}
                <li class="productView-thumbnail">
                    <a href="{{getImage this 'product_size' (cdn ../theme_settings.default_image_product)}}">
                        <img src="{{getImage this 'productthumb_size' (cdn ../theme_settings.default_image_product)}}" alt="{{this.alt}}">
                    </a>
                </li>
            {{/each}}
        </ul>
    </section>

    <section class="productView-details">
        <div class="productView-product">
            <h1 class="productView-title">{{product.name}}</h1>
            {{#if product.brand}}
                <h2 class="productView-brand">
                    <a href="{{product.brand.url}}">{{product.brand.name}}</a>
                </h2>
            {{/if}}
            
            <div class="productView-price">
                {{#if product.price.with_tax}}
                    <span class="price">{{product.price.with_tax.formatted}}</span>
                {{else}}
                    <span class="price">{{product.price.without_tax.formatted}}</span>
                {{/if}}
            </div>

            <div class="productView-description">
                {{{product.description}}}
            </div>
        </div>

        <div class="productView-options">
            <form class="form" method="post" action="{{product.cart_url}}" enctype="multipart/form-data" data-cart-item-add>
                <input type="hidden" name="action" value="add">
                <input type="hidden" name="product_id" value="{{product.id}}">

                {{#if product.options}}
                    <div class="form-field">
                        {{#each product.options}}
                            <label class="form-label form-label--alternate" for="attribute_{{id}}">{{display_name}}</label>
                            <select class="form-select" name="attribute[{{id}}]" id="attribute_{{id}}" required>
                                <option value="">Choose an option</option>
                                {{#each values}}
                                    <option value="{{id}}">{{label}}</option>
                                {{/each}}
                            </select>
                        {{/each}}
                    </div>
                {{/if}}

                <div class="form-action">
                    {{#if product.out_of_stock}}
                        <button class="button button--primary button--out-of-stock" disabled>Out of Stock</button>
                    {{else}}
                        <input class="form-input form-input--incrementTotal" id="qty[]" name="qty[]" type="number" value="{{#if product.min_purchase_quantity}}{{product.min_purchase_quantity}}{{else}}1{{/if}}" min="1" pattern="[0-9]*" aria-live="polite">
                        <button class="button button--primary" type="submit">Add to Cart</button>
                    {{/if}}
                </div>
            </form>
        </div>
    </section>
</div>
{{/partial}}
{{> layout/base}}

4. BigCommerce vs Shopify: When Each Platform Wins

A direct, honest architectural comparison between BigCommerce and Shopify is essential for enterprise merchants. While both are multi-tenant SaaS platforms, their core data models and commercial structures serve completely different business strategies.

Transaction Fees and Payment Gateways

Shopify enforces a closed financial ecosystem. If you choose not to use Shopify Payments (which is built on Stripe), Shopify imposes a penalty fee ranging from 0.5% to 2.0% on every transaction. For high-volume merchants with negotiated merchant accounts (e.g., via Authorize.net or Worldpay), this penalty is economically devastating. BigCommerce, conversely, charges absolutely zero transaction fees on all tiers, allowing merchants total freedom to bring their own payment gateways without penalty.

API Rate Limits and Enterprise Sync

Shopify relies on the leaky bucket algorithm. Standard plans offer 2 requests per second (burst to 40), and Shopify Plus offers 4 requests per second. When running deeply nested catalogue integrations (e.g., synchronizing 50,000 SKUs from a legacy ERP system), this heavily limits concurrency. BigCommerce provides vastly more generous API limits, starting at 150 requests per 30 seconds (effectively 5 req/sec consistently) and scaling to 400 requests per 30 seconds on Plus/Enterprise plans, making it significantly more resilient for heavy backend data orchestration.

Ecosystem and B2B Capabilities

Shopify undoubtedly possesses a larger, more mature App Store ecosystem. If your business relies heavily on niche D2C marketing widgets, loyalty programs, and social media integrations, Shopify's plug-and-play capability is unmatched. However, when evaluating B2B functionality, the tables turn. BigCommerce's B2B Edition is purpose-built, natively supporting corporate hierarchies, nested buyer roles, and complex Net-30 quote generation. Shopify's native B2B functionality is newer and significantly less feature-complete for complex wholesale distribution networks.

Checkout Customisation

Shopify Plus historically allowed full Liquid access to the checkout file (checkout.liquid), but they are deprecating this in favour of Checkout Extensibility (UI Extensions built with React). This strictly limits where and how you can inject custom logic. BigCommerce offers the Checkout SDK, a massive JavaScript library that grants developers absolute, unrestricted control over the UI and UX, allowing them to render custom React or Vue components directly over the entire payment sequence.

5. Catalogue Import and Bulk Operations

Managing massive product arrays requires a robust understanding of BigCommerce's bulk tooling. The platform supports native CSV imports directly via the admin interface, but large-scale operations necessitate API-driven batch processing.

CSV Import Structure

The native CSV import tool requires specific column mapping. The mandatory columns are Item Type (Product vs SKU), Product Name, Price, and Category. Optional but highly recommended columns include Brand, Weight, Description, and Product URL. BigCommerce allows updating existing items using the Product ID or SKU as the unique identifier during the import phase.

Using the v3 Batch Endpoint

While the admin CSV import is useful for minor updates, programmatic syncs should leverage the v3 Catalog Management API. The bulk/batch endpoint allows you to update hundreds of products in a single HTTP request. Using a PUT /v3/catalog/products request with an array payload, you can execute massive price updates or inventory alignments instantaneously without exhausting your API rate limit.

6. BigCommerce API Architecture: v2 vs v3 and Node.js Integration

The BigCommerce Management API is expansive. The v3 API is the preferred integration target. It was rebuilt specifically to support bulk operations and complex catalogue hierarchies. Unlike v2, which heavily fragmented product data into sub-resources, the v3 API returns rich, deeply nested variant-level data in a single payload.

A Complete Node.js API Example

Integrating with the v3 API requires strict adherence to REST principles. You must authenticate using the X-Auth-Token header. Below is a complete, production-ready Node.js script using the modern fetch API to create a product with two variants (Size S and Size L). It demonstrates robust error handling, JSON body construction, and logging.

/**
 * create_product_with_variants.js
 * Node.js script to create a product via BigCommerce Management API v3
 */
const STORE_HASH = 'your_store_hash';
const API_TOKEN = 'your_api_token';
const API_URL = `https://api.bigcommerce.com/stores/${STORE_HASH}/v3/catalog/products`;

const productPayload = {
  name: 'Premium Leather Jacket',
  type: 'physical',
  weight: 2.5,
  price: 250.00,
  categories: [23],
  is_visible: true,
  variants: [
    {
      sku: 'LJKT-BRN-S',
      price: 250.00,
      weight: 2.5,
      option_values: [ { id: 101, option_id: 14 } ] // ID 14 is 'Size', 101 is 'Small'
    },
    {
      sku: 'LJKT-BRN-L',
      price: 275.00,
      weight: 3.0,
      option_values: [ { id: 103, option_id: 14 } ] // ID 103 is 'Large'
    }
  ]
};

async function createProduct() {
  try {
    const response = await fetch(API_URL, {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
        'X-Auth-Token': API_TOKEN,
        'Accept': 'application/json'
      },
      body: JSON.stringify(productPayload)
    });

    if (!response.ok) {
      const errorData = await response.json();
      throw new Error(`API Error: ${response.status} - ${JSON.stringify(errorData)}`);
    }

    const data = await response.json();
    console.log(`Success! Product created with ID: ${data.data.id}`);
    console.log(`Variant SKUs created: ${data.data.variants.map(v => v.sku).join(', ')}`);

  } catch (error) {
    console.error('Failed to create product:', error.message);
  }
}

createProduct();

OAuth scopes must be correctly configured in the control panel to allow "Catalog: Modify" permissions for this script to execute successfully.

7. GraphQL Storefront API

While the Management REST API is designed for backend orchestration, the GraphQL Storefront API is explicitly designed to serve customer-facing data to headless storefronts (like Next.js) or embedded custom React components within Stencil. It is a read-heavy, performance-optimised API.

Authentication and Queries

You authenticate requests using a Storefront API Token. You generate this token dynamically via the Management API for secure, customer-scoped access (ensuring they only see their assigned B2B price lists). Below is a complete GraphQL query requesting a product by entity ID, expanding its pricing logic, high-resolution imagery, and available variants.

query ProductQuery {
  site {
    product(entityId: 111) {
      name
      sku
      description
      prices {
        price {
          value
          currencyCode
        }
        salePrice {
          value
          currencyCode
        }
      }
      defaultImage {
        urlOriginal
        altText
      }
      variants(first: 5) {
        edges {
          node {
            sku
            entityId
            inventory {
              aggregated {
                availableToSell
              }
            }
          }
        }
      }
    }
  }
}

Cart Mutations via GraphQL

The Storefront API also supports transactional mutations. If you are building a custom React cart drawer, you execute the addCartLineItems mutation to inject products directly into the BigCommerce checkout session.

mutation AddToCart {
  cart {
    addCartLineItems(
      input: {
        cartEntityId: "bc-cart-uuid-123"
        data: {
          lineItems: [
            {
              productEntityId: 111
              variantEntityId: 456
              quantity: 2
            }
          ]
        }
      }
    ) {
      cart {
        entityId
        lineItems {
          physicalItems {
            name
            quantity
            extendedListPrice {
              value
            }
          }
        }
      }
    }
  }
}

8. Headless BigCommerce: Catalyst and Next.js

Headless commerce decouples the frontend presentation layer from the backend platform, communicating exclusively via APIs. BigCommerce is inherently built to support this model, pushing data via the Storefront GraphQL API to arbitrary frontends.

Catalyst: The Next.js Reference Architecture

BigCommerce's official headless solution is Catalyst. It is a highly opinionated, production-ready reference storefront built on Next.js, leveraging the modern App Router architecture and React Server Components. Catalyst is designed to abstract away the boilerplate of connecting a React application to the BigCommerce backend, providing pre-built components for product cards, faceted search, and cart management.

You can bootstrap a Catalyst project rapidly using their CLI:

npm create @bigcommerce/catalyst@latest
# The CLI will prompt for your store hash and Storefront API token.

When Headless is Actually Worth the Complexity

Headless architecture is currently heavily marketed, but it is not a silver bullet. The operational complexity of managing a separate Node server, configuring Vercel or Netlify deployments, and handling edge caching is significant. Headless is worth the investment when you have a large internal engineering team with deep React expertise, complex design requirements that Stencil cannot handle efficiently, or the need to aggregate content from multiple sources like Contentful alongside BigCommerce data.

9. Checkout Customisation: OOPC and SDK

The checkout phase is the most critical juncture of an ecommerce transaction. BigCommerce provides a highly reliable Optimized One-Page Checkout (OOPC) out of the box. Customising this experience requires careful consideration of security and performance.

The Checkout SDK vs Script Manager

The standard OOPC allows limited structural modification via the Script Manager. Developers can inject header and footer scripts to deploy analytics tags, trust badges, or custom CSS overrides. However, you cannot fundamentally alter the checkout flow (e.g., splitting it into a multi-step wizard) using basic script injection.

For bespoke experiences, the BigCommerce Checkout SDK is a massive JavaScript library that allows developers to build fully custom checkout UIs from scratch using React, Vue, or vanilla JS, while relying on BigCommerce to handle the underlying PCI compliance, payment gateway tokenisation, and shipping rate calculations.

For headless implementations, BigCommerce offers Embedded Checkout. This feature renders the secure OOPC within an iframe on your external domain, maintaining the illusion of a seamless transaction without forcing the developer to rebuild complex payment validation logic.

10. Multi-Storefront (MSF) Architecture

Historically, operating multiple regional storefronts required managing entirely separate platform instances, leading to fragmented analytics and massive operational overhead. BigCommerce's Multi-Storefront (MSF) feature fundamentally solves this.

MSF allows a merchant to provision separate channels within a single control panel. Each channel can map to a distinct top-level domain, utilize an entirely different Stencil theme, and present localised currencies. Crucially, the core product catalogue remains unified. You simply toggle which products are visible on which channel. This supports channel-specific pricing (via assigned price lists) and channel-specific payment gateways, allowing a merchant to present a bespoke B2C lifestyle brand in the UK and a stripped-down B2B wholesale portal in Germany, all powered by the same backend SKU inventory.

11. B2B Edition and Corporate Account Management

While BigCommerce natively supports wholesale pricing via price lists, complex corporate hierarchies require the B2B Edition. This is an advanced application layer integrated seamlessly on top of the standard store, providing enterprise-grade procurement tools.

B2B Edition introduces Company Accounts. A company can have multiple associated users, each assigned specific roles. An Admin manages the address book. A Buyer builds carts and executes purchases. A Junior Buyer builds carts but must route the order for approval by a senior manager before the transaction completes.

The platform facilitates complex negotiations via Quote Management. A buyer builds a cart and submits it as a request for quote (RFQ). The sales representative adjusts pricing, applies line-item discounts, and sends the revised quote back for single-click checkout. Furthermore, it supports purchase orders and net payment terms (e.g., Net 30), entirely bypassing credit card tokenisation for vetted corporate clients.

12. Performance Optimization and Edge Caching

Even the most robust architecture will suffer if the frontend rendering pipeline is poorly configured. BigCommerce provides excellent baseline performance tooling, but developers must optimize their implementation.

BigCommerce leverages Akamai as its built-in Content Delivery Network (CDN), caching static assets globally. The platform includes automatic image optimization via Akamai Image Manager, converting JPEGs to next-generation formats like WebP on the fly. Developers must utilize the getImage Handlebars helper in conjunction with responsive srcset attributes to ensure mobile devices are not downloading massive desktop-resolution assets.

The most common cause of poor Lighthouse scores is third-party script bloat. The Script Manager allows developers to enforce a strict performance budget: Head Synchronous for critical scripts, Footer Asynchronous for analytics, and Footer Deferred for heavy widgets (e.g., live chat). By aggressively managing third-party execution, developers can consistently achieve sub-400ms Time to First Byte (TTFB) metrics.

13. BigCommerce SEO Architecture

BigCommerce fundamentally approaches search engine optimization (SEO) from a deeply integrated, systems-level perspective rather than treating it as an afterthought bolted onto the platform. When I architect large-scale migrations, the SEO parity between the legacy system and the new BigCommerce environment is often the primary risk factor. Understanding how BigCommerce handles URL structures, redirects, and canonicalization is essential to prevent catastrophic traffic drops during launch.

URL Structure and Canonicalization

Out of the box, the URL taxonomy in BigCommerce is deterministic but highly configurable. Product URLs default to a flat structure (e.g., /product-name/), while categories follow their hierarchical nesting (e.g., /category-name/). Unlike some legacy platforms that append messy query strings or session IDs to standard URLs, BigCommerce maintains clean, static-looking paths. The platform automatically generates canonical URLs for every product and category page. This means that if a product is accessed via a faceted search query like /shoes/?color=red, the canonical tag safely points search engine crawlers back to the primary /shoes/ directory, strictly preventing duplicate content penalties.

Each product and category entity in the catalogue database allows granular overrides for SEO metadata. Within the product payload (accessible both via the Control Panel and the v3 Catalog Management API), you can define custom meta titles, meta descriptions, and heavily customized URL paths that deviate from the standard product name slug. This flexibility is vital when optimizing specific high-margin products where the internal database name differs from the exact long-tail search query you want to target.

301 Redirect Management and XML Sitemaps

During a migration, matching legacy URLs to new BigCommerce routes is critical. BigCommerce provides a robust 301 redirect manager directly within the admin interface (located under Marketing > 301 Redirects). For small stores, this is adequate; however, for enterprise deployments, I always utilize the Server-to-Server v3 API to programmatically inject thousands of 301 redirects, ensuring that equity from legacy category trees and product pages transfers instantaneously upon DNS propagation.

Furthermore, XML sitemap generation is entirely automated. The system dynamically builds and updates the sitemap tree as products are added, removed, or hidden from the catalogue. This automated sitemap must be submitted to Google Search Console immediately post-launch. For multi-language setups, BigCommerce intelligently handles hreflang tag generation via custom Handlebars logic injected into the Stencil theme, explicitly telling search engines which regional variant of a page to serve to a specific user based on their locale.

Structured Data and Schema Markup

In modern e-commerce, rich snippets dramatically improve click-through rates. BigCommerce natively injects JSON-LD Structured Data Schema Markup directly into Stencil themes. The core Product schema automatically maps essential variables such as the product name, current price, stock availability, SKU, and brand. This means that without any custom script injection, your product pages immediately qualify for enhanced presentation in Google Shopping and organic search results. For developers, this automatic schema injection reduces the technical debt associated with manually maintaining microdata attributes across complex product variations.

Advanced Configuration: Robots.txt and AMP

Unlike restrictive SaaS platforms, BigCommerce allows absolute control over the robots.txt file directly from the dashboard (Admin > Store Setup > Store Profile > Search Engine Robots). I frequently leverage this to block aggressive AI scraping bots or explicitly disallow crawlers from indexing specific faceted search parameter combinations that drain crawl budget.

Finally, it is worth discussing Accelerated Mobile Pages (AMP). BigCommerce historically offered strong AMP support natively (available on Pro+ plans), allowing product pages to load almost instantaneously from Google's cache. While AMP is largely deprecated as a strict ranking signal for 2025—replaced by Core Web Vitals—it still remains relevant for specific price comparison engines and regional aggregators. Depending on the merchant's acquisition strategy, toggling AMP can provide a tactical advantage, though the heavy lifting for performance should always focus on optimizing the Stencil framework directly.

14. Migrating to BigCommerce: Data Import and the Stencil Rebuild

Executing a platform migration from Shopify, Magento, or WooCommerce to BigCommerce is rarely a simple lift-and-shift operation. The structural differences in how data is modelled require a phased integration strategy. I have seen migrations stall for months because development teams underestimated the complexity of transferring relational order data and rebuilding customized frontend logic within the Stencil ecosystem.

Data Migration: Tooling and API Complexity

BigCommerce provides a native CSV data import tool (Admin > Products > Import) which is highly effective for basic catalogue ingestion. However, a comprehensive migration involves more than just products; it demands the transfer of historical order data, customer accounts (including hashed passwords where supported), and extensive product review datasets. Because these entities are deeply relational, a flat CSV import is insufficient.

To orchestrate complex data transfers, I primarily rely on API-level migration middleware. Third-party services like LitExtension and Cart2Cart dominate this space, offering proven connectors that support Shopify-to-BigCommerce and WooCommerce-to-BigCommerce transitions. These tools programmatically map fields between the disparate databases, reliably handling the transfer of products, active customer accounts, legacy order histories, and complex coupon logic. While these automated tools handle the bulk of the data movement, significant API orchestration is still required to validate the synchronization and ensure that custom field data maps correctly to BigCommerce's v3 product architecture.

The Stencil Rebuild Timeline

The most time-intensive phase of any migration is the frontend rebuild. Legacy themes built in Liquid (Shopify) or PHP (Magento) cannot be automatically ported; they must be entirely rewritten using Stencil and Handlebars.js. Developers must manage merchant expectations regarding this timeline.

If a merchant is satisfied with adopting a pre-built Stencil theme (such as the default Cornerstone foundation) and applying basic CSS customization, the rebuild timeline typically spans 2 to 4 weeks. This involves adjusting colour variables in the config.json, replacing core typography, and injecting custom brand assets into the header and footer layers.

Conversely, a fully custom Stencil theme built from scratch to match a bespoke Figma design requires 6 to 12 weeks of rigorous engineering. This involves developing custom Handlebars helpers, building proprietary React components for the checkout SDK, and orchestrating complex API fetch routines for dynamic, personalized user experiences. The architectural shift to Stencil demands strict adherence to separation of concerns—markup in Handlebars, styling in SCSS, and logic heavily isolated in JavaScript modules.

Multi-Storefront (MSF) Migration Setup

When migrating an enterprise architecture that utilizes multiple regional storefronts, the setup phase changes drastically. Instead of provisioning multiple isolated BigCommerce instances, developers configure a single backend and utilize the Multi-Storefront (MSF) feature. Each regional storefront gets its own dedicated channel within the overarching database.

The migration complexity here lies in the channel API orchestration. Before a multi-storefront environment can go live, developers must systematically assign products to specific channels via the channel API. This ensures that the UK store displays only UK-relevant SKUs and pricing, while the US store operates autonomously. This channel assignment must be thoroughly validated in a staging environment to prevent cross-border pricing errors or catalogue bleed.

15. Conclusion and Next Steps

Deploying BigCommerce requires a systems engineering mindset. It rewards strict data modelling and structured API consumption, particularly when leveraging its powerful multi-storefront and price list capabilities. For high-volume merchants constrained by competitor rate limits, the technical migration overhead pays dividends in operational stability and scale.