Skip to main content
This page combines three closely-related migration topics: BigCommerce B2B Edition migration support, the rules around coupon and promotion migration, and the broader data dependency map you need to read before running any partial migration.

​
B2B Edition support

B2B Edition (formerly Bundle B2B) adds a parallel data model on top of standard BigCommerce: company roles, companies, addresses, users, super admins, and sales staff. StagingPro V2 migrates it from the B2B Edition Migration panel on the Bulk Content Migration page.

​
What migrates

Not included (deliberate scope, planned for a follow-up): B2B orders, invoices, quotes, and shopping lists. Existing destination companies with the same identity are matched rather than duplicated — under the default Add New Only they are left untouched; choose Update Existing to sync their configuration, hierarchy, and users. Destination-only companies are never deleted. One prerequisite for sales staff: sales-rep accounts cannot be created via the API, so an assignment whose account is missing on the destination is skipped with instructions to create the System User first.

​
Prerequisites

1

B2B Edition on both stores

Both the source and destination stores must have the B2B Edition app installed and activated by BigCommerce. The panel only appears when both stores are B2B; if either isn’t, it is hidden entirely.
2

A store API token with the B2B Edition scope

There are no separate B2B credentials — the store’s main API token does everything, provided it was created with the B2B Edition access level. Token scopes are fixed at creation, so an existing token without B2B access must be replaced: create a new store-level API account (BigCommerce control panel → Settings → Store-level API accounts) with the B2B Edition scope.
Tokens created inside the B2B Edition app’s own “API accounts” page do not work for migration — it must be a store-level API account. If a store is B2B but its token lacks B2B access, StagingPro shows a plain-language “B2B entities can’t be migrated yet” card naming the store and the fix.
3

Anonymisation for personal data

Companies — together with their Addresses, Users, Super Admins, and Sales Staff Assignments — stay locked until the shared Anonymise Customer Data switch (the same one that covers orders) is on. Anonymised identity is stable, so repeat runs match earlier copies and never create duplicates. Only Roles & Permissions is always available (it carries no personal data).
Classic app users: the old Settings → B2B Edition tab, where a dedicated B2B user email and password were entered per environment, is obsolete in V2 — any values entered there are ignored, and the tab is slated for removal. V2 authenticates B2B entirely through the store’s main API token.

​
B2B entity dependencies

Selecting Companies auto-includes Roles & Permissions only. Companies link to Customer Groups and Price Lists — select those in the same run, or each company is created without its pricing link (the company itself still migrates; assign the price list manually otherwise). Migrate B2B entities together with, or after, the core catalogue and customer data; the B2B phases run last in a bulk migration for exactly this reason.

​
Coupons and Promotions

Coupon codes in BigCommerce are part of the Promotions system. When you migrate a promotion via StagingPro:
  • Product, category, brand, and customer-group references inside the promotion are re-pointed through the migration’s own id-maps — so the referenced entities must be part of the same run (items that already exist on the destination count: matching them puts them in the map).
  • A promotion whose reference cannot be mapped is skipped with a clear reason rather than migrated with broadened scope — a discount is never silently widened to more products than it covered on the source. A reference list that is only partially mappable is narrowed to the mappable items, with a warning.
  • Coupon codes attached to a promotion travel with the promotion (and are not duplicated as legacy coupons).
  • Storefront-scoped promotions land on the mapped storefronts; if none of the promotion’s storefronts are mapped, it is skipped, naming the unmapped channel ID.

​
Promotions migrate as complete units

Each promotion moves as a complete unit including all conditions, actions, schedule, and notifications — its scope is only ever narrowed (with a warning), never widened.

​
Promotions created via API cannot be edited after creation

This is a BigCommerce constraint. If a promotion was originally created via the API and you discover the rules need adjusting on the destination, the workaround is to delete the promotion in the source, recreate it correctly, and re-migrate. We will surface manual editing once BigCommerce supports it natively.

​
Data dependencies, the full map

Some entities depend on others being present so their references resolve on the destination:

​
Why this matters

On a selective run, dependencies come along automatically (a product pick brings its brands and categories). On a bulk run, you choose the entity groups explicitly — the engine re-points cross-entity references through the run’s own id-maps and drops what it can’t resolve with a warning (301 redirects and related-products additionally fall back to destination lookups by SKU, name, or URL). To move promotion configuration onto an already-populated destination, select the referenced products, categories, and customer groups in the same run — matching them against the existing destination items builds the id-map without duplicating anything.