Buyer resource / Migration
Adobe Commerce to BigCommerce: plan the move.
The products are usually the most visible part of a migration. The harder part is preserving what the account, price, order and operating team expect those products to do.
Follow the buying promise.
- 01Map the current behaviorAccounts, catalog, pricing and operations
- 02Choose the target modelBigCommerce configuration and extension
- 03Resolve the gapsRetain, replace, integrate or retire
- 04Prove a representative purchaseInclude a denied account and an exception
- 05Protect the cutoverDelta data, redirects and recovery
The catalog can move while the buying experience breaks.
A distributor moves a familiar product range to a new platform. The product pages look right. Then a returning buyer signs in, sees a different price, cannot use the usual account, and sends the order to customer service by email.
The migration missed a relationship: which buyer may purchase through which company, at which price, with which approval and fulfillment rules. That relationship is part of the implementation even when it does not appear in the product export.
I would begin an Adobe Commerce-to-BigCommerce evaluation with a handful of representative purchases. Use them to compare the current behavior with the target operating model before committing to a feature list or a launch date.
Compare business behavior, then choose the target implementation.
Adobe Commerce B2B and BigCommerce B2B Edition both offer business-buying capabilities. Their data models, extension surfaces and configuration are different. A similarly named feature needs a workflow demonstration in the proposed target store.
Record the exact Adobe offering and B2B extension, the BigCommerce plan and B2B Edition configuration, and the proposed storefront. Decide whether the hosted Buyer Portal, a custom Buyer Portal, or a different supported storefront approach fits the required experience.
The comparison below is a planning map. Each row ends with evidence your team can inspect.
| Area | Adobe Commerce source | BigCommerce target | Acceptance evidence |
|---|---|---|---|
| Company and buyer relationships | Company structures, roles and purchasing permissions within the configured B2B environment. | B2B Edition company accounts, role permissions and account-hierarchy configuration. | Demonstrate eligible and denied account access, the required hierarchy, and account context through checkout. |
| Assortment and contract pricing | Shared catalogs connect company-specific assortment and pricing. | Map company context to the appropriate customer-group, channel, catalog access and variant price-list design. | Compare representative account/SKU prices and visibility, including a missing price record and the target fallback behavior. |
| Product types and options | Inventory the source simple, configurable, grouped, bundle and custom-option behavior actually used. | Choose variants for separately fulfilled items and modifiers for supported customization or add-on choices. Decide how complex source products will be represented. | A buyer selects the right item, and operations receives the intended SKU, quantity, price and inventory effect. |
| Quotes and approvals | Negotiable quotes and purchase-order approvals are distinct configured B2B workflows. | Evaluate Buyer Portal quote behavior and the target account's purchasing permissions; resolve the exact approval requirement. | Walk request, change, approval, acceptance and order conversion with the required actors. Do not equate workflows by feature name. |
| Content and storefront extensions | Inventory theme changes, modules, custom pages and content editing responsibilities. | Choose the storefront and hosted or custom Buyer Portal model, then map each necessary behavior to supported configuration, APIs or extensions. | Marketing can publish required content, buyers can finish core tasks, and the release owner understands ongoing portal maintenance. |
| Data transfer and identifiers | Exports and supported interfaces provide entity-specific data; inventory the relationships and historical scope separately. | Transform to the target schema and retain a source-to-target identifier map. | Read back representative records and reconcile important fields, permissions and relationships. |
| ERP and operating workflows | Capture current account, price, availability, order and fulfillment contracts. | Design the target integration with new platform identifiers, supported APIs and explicit exception ownership. | Trace the sample order to a downstream reference; exercise a rejection and an uncertain acknowledgement. |
| URLs and search continuity | Inventory existing indexed URLs, canonical destinations and valuable campaign links. | Preserve suitable URLs and map changed destinations to redirects in the target. | Verify destination content, status codes, canonicals, internal links and the new sitemap. |
Use one account-specific purchase as the proof.
Create fictional Company A and Company B. A buyer may purchase for both, but each company has its own assortment and agreed pricing. Give the two companies one shared SKU and one restricted SKU. The buyer begins under Company A, builds an order, then changes account.
Ask the target implementation to show which account is active, which items and prices change, what happens to the cart, and how the final order carries the correct downstream company reference. Include one person who must be denied access.
Then add a product variation that is stocked separately and an optional customization that is not. In BigCommerce those are different modeling decisions: a variant identifies a fulfilled item, while a modifier changes a customization or add-on without becoming a separately inventoried variant.
A successful product import is useful evidence. This complete purchase shows whether the imported model serves the business.
Inventory what needs to move, change or retire.
Start with a row for each important behavior, data set and integration. Record the current source, the proposed target, the accountable owner and the acceptance check. Use Configure, Rebuild, Replace, Retire or Decide as the decision.
Keep the source-of-truth map separate from the current storage location. An ERP-owned price does not become commerce-owned because the old storefront stores a copy. Decide whether the target receives a scheduled price list, performs an approved live calculation, or uses another supported design.
Choose intentionally awkward sample data: a restricted product, a missing target price, a buyer with multiple relationships, a complex product, an old URL and an uncertain order handoff. A small representative migration exposes these decisions while the scope is still manageable.
| Behavior | Current model | Target decision | Acceptance evidence |
|---|---|---|---|
| Accounts | Company memberships, shared catalogs and custom selection behavior. | B2B Edition company and role model; document any additional account selection behavior. | Denied user cannot select an account; eligible buyer's assortment and price follow the intended company. |
| Pricing | Shared catalogs, special/tier prices or ERP-owned price feeds. | Target variant prices, price lists and channel/customer-group assignments, with explicit refresh ownership. | Compare a shared SKU under two account contexts plus a missing target price. |
| Products | Simple/configurable products, bundles, grouped products and custom options. | Target variant/modifier design or a defined supported replacement for complex behavior. | Correct fulfillment SKU, stock effect and price for every representative product type. |
| Access | Website/store visibility, customer groups and company catalogs. | Target catalog/channel and customer access model. | Authorized buyer can find the product; denied buyer cannot purchase it. |
Interactive planning checklist
Check a task after you have reviewed its completion evidence. Download your progress to assign owners, dates and notes in Excel.
- MB-01 / Accounts: Map buyer eligibility and company relationships.Complete when: Denied user cannot select an account; eligible buyer's assortment and price follow the intended company.Suggested owner: Sales operations / IT
- MB-02 / Pricing: Prove the target account price and fallback behavior.Complete when: Compare a shared SKU under two account contexts plus a missing target price.Suggested owner: Sales / finance / integration
- MB-03 / Products: Separate stock variants from product customization.Complete when: Correct fulfillment SKU, stock effect and price for every representative product type.Suggested owner: Product data / operations
- MB-04 / Access: Preserve restricted assortment and channel visibility.Complete when: Authorized buyer can find the product; denied buyer cannot purchase it.Suggested owner: Ecommerce / IT
- MB-05 / Purchasing: Resolve quote and approval behavior.Complete when: Request, revise, approve and convert a sample quote or purchase with correct status and ownership.Suggested owner: Sales / ecommerce
- MB-06 / Authentication: Define sign-in and account activation during transition.Complete when: Representative customer signs in and lands in the intended authorized account.Suggested owner: IT / customer service
- MB-07 / Integration: Rebuild the order contract and uncertain-outcome recovery.Complete when: One valid order reaches the intended ERP account; a timeout is resolved without another order.Suggested owner: Integration / operations
- MB-08 / Operations: Decide where historical and in-flight records remain available.Complete when: Customer service can find required history; open work has an owner and next action.Suggested owner: Customer service / finance
- MB-09 / Experience: Map storefront, Buyer Portal and content responsibilities.Complete when: Core mobile buying task and a representative marketing publish can be completed.Suggested owner: UX / marketing / engineering
- MB-10 / Search: Map valuable URLs and incoming links.Complete when: Correct status, useful destination, canonical and internal links for each sampled URL.Suggested owner: Marketing / SEO / engineering
- MB-11 / Data: Reconcile a representative sample before the full migration.Complete when: Counts and important fields agree; invalid rows have explainable results and owners.Suggested owner: Data owners / integration
- MB-12 / Release: Approve cutover, final changes and recovery treatment.Complete when: Named go/no-go owner; no unowned order/payment gap at the transition boundary.Suggested owner: Release owner / operations
A cutover needs a plan for the orders that arrive during it.
Decide which historical records must be available in the new storefront and which can remain in an accessible archive. Record how open quotes, incomplete carts, credit balances and in-flight orders are handled. Do not assume every record can be imported unchanged.
Plan the initial snapshot, subsequent changes, final reconciliation and the moment new purchases begin using the target. The recovery plan must explain what happens to orders and payments created after that moment. Restoring the old application alone does not resolve those transactions.
Include important product and category URLs, inbound campaign links, redirects, canonical URLs and sitemap checks. A redirect map keeps changed URLs useful to buyers and crawlers. It is one part of search continuity, alongside content and technical validation.
Common planning mistakes.
- Calling every product option a variant. Ask what the warehouse fulfills and what carries inventory. Then choose the target model. Product options that look alike on screen may represent very different business data.
- Rebuilding every custom module. Record why the behavior exists. Use supported configuration where it fits, rebuild only what remains necessary, and retire obsolete work with the owner's agreement.
- Comparing subscription fees before defining the operating model. Evaluate implementation, connected services, content work, custom portal maintenance, integrations, support and internal responsibilities alongside the platform proposal.
- Declaring success from record counts. Reconcile the important fields and relationships, then demonstrate the buyer and operations workflow. Matching counts can still hide incorrect account or pricing context.
Make a platform decision with evidence.
The useful output is a fit-and-gap inventory, a demonstrated purchase, a migration sequence and a defined commercial scope. Keep important gaps visible so the platform choice reflects the business you are running.
GCG works across Adobe Commerce and BigCommerce. We can help your IT, marketing, ecommerce and operations teams evaluate the target model and turn the chosen direction into a practical implementation.
Check the platform documentation.
Use these official references alongside the configuration and releases in your environment. The workflow and checklist above are GCG implementation guidance.
Put the next decision in context.
Bring the workflow that needs to work.
We can turn a concrete buying or integration problem into a defined implementation scope, with the decisions and acceptance evidence visible.
Discuss your commerce priorities