Adobe Commerce migrations fail most often when transferred records are separated from the enterprise relationships that control who can buy, what they can see, which price applies, where inventory is fulfilled, and when content becomes active. A Product can exist in Admin yet remain commercially wrong because it belongs to the wrong website, lacks its configurable children, is excluded from a shared catalog, or carries no usable source-and-stock relationship.
The most damaging pitfalls are therefore not simple record omissions. They are relationship failures that look complete during a superficial review. Prevention requires each enterprise rule to have a named Adobe Commerce owner, a representative scenario, and a clear pass condition.
Pitfall 1: Converting Company Accounts Into Unrelated Customer Records
What goes wrong
Adobe Commerce B2B company accounts can contain company administrators, teams, users, roles, permissions, addresses, payment expectations, and purchasing relationships. A migration that imports only individual Customers preserves contact data but removes the organization that governs those buyers.
The Store may show all expected email addresses while company administrators cannot manage users, assistant buyers receive excessive access, and Orders are no longer associated with the correct business account.
Early warning signs
| Early warning sign | What it indicates |
|---|---|
| Company, division, team, and user records are exported as one Customer list. | B2B hierarchy is being flattened into unrelated individual accounts. |
| Administrator and buyer roles are represented only by free-text labels. | Permissions and approval ownership cannot be reconstructed reliably. |
| Several buyers share company pricing or addresses, but no durable company identifier exists. | Shared commercial context will fragment across Customers. |
| The source relies on approval, account credit, or restricted payment behavior outside the Customer record. | Critical B2B behavior has no target owner. |
Prevention
Model the company as the parent business entity. Preserve the company identifier, company administrator, subordinate users, teams, role assignments, addresses, Customer-group relationship, and the external account key used by CRM or ERP systems. Do not infer company membership only from email domains or address similarity.
Recommendation example
Use one company with an administrator, a senior buyer, and a restricted buyer as the representative pattern. Translate each user’s company membership and role separately, then preserve the shared account and external company identifier.
Pass condition
The representative company appears once, contains the correct users and teams, assigns the intended permissions to each role, and remains linked to the correct Customer group, addresses, and external account key.
Pitfall 2: Assigning Shared Catalogs Without Preserving Company-Specific Prices
What goes wrong
Shared catalogs can control Product selection and custom pricing for company accounts. Importing Products and companies without the shared-catalog relationship can expose restricted Products publicly, hide contracted items from approved buyers, or replace negotiated prices with general catalog prices.
The error is easy to miss because the primary catalog can still look complete in Admin while storefront visibility differs by company context.
Early warning signs
- The same SKU has different prices for different companies or Customer groups.
- Private Products are included in the general Product export.
- Contracts or ERP records define prices that are not stored on the source Product.
- Company assignment and catalog assignment are maintained in separate source systems.
Prevention
Create an explicit relationship among company, shared catalog, Product selection, custom price, website scope, and Customer group. Keep the public catalog separate from company-specific catalogs, and preserve any external contract identifier that explains the price source.
Recommendation example
Use one public SKU, one restricted SKU, and one contract-priced SKU. Represent how each appears for a guest, a general Customer, and two companies with different shared catalogs.
Pass condition
Each representative buyer sees only the intended Products and prices, while users outside the assigned company cannot access restricted Products or negotiated values through Categories, search, direct URLs, cart, or checkout.
Pitfall 3: Recreating Buyers but Losing Quotes, Purchase Orders, and Approval Relationships
What goes wrong
Adobe Commerce B2B purchasing can include negotiable quotes, purchase orders, approval rules, requisition lists, and role-based access. These records are not ordinary Orders or wish lists. Flattening them into generic notes removes their status, owner, approval path, line history, and relationship to the company account.
A buyer may retain Order history but lose an open quote, a pending purchase order, or the requisition list used for recurring purchases.
Early warning signs
| Early warning sign | What it indicates |
|---|---|
| Quotes and purchase orders are exported with Order records but use different identifiers or statuses. | Distinct purchasing workflows are being collapsed into completed-order history. |
| Approval limits exist in policy documents or an external procurement system. | The control logic is outside the migrated record set. |
| Requisition lists contain recurring SKU sets but are treated as wish lists. | Operational purchasing intent is being misclassified as merchandising preference. |
| Quote comments, revisions, expiration, or negotiated discounts have no proposed owner. | The commercial negotiation trail will be incomplete. |
Prevention
Classify each B2B workflow separately. Preserve company, creator, approver, status, line items, quantities, negotiated adjustments, comments, dates, and external references where the destination workflow requires continuity. Historical records that cannot remain active should still retain enough context for staff and buyers to understand their state.
Recommendation example
Select one open negotiable quote, one approved purchase order, one purchase order awaiting approval, and one requisition list. Define the destination owner and retained history for each record type.
Pass condition
The destination distinguishes quotes, purchase orders, approval relationships, requisition lists, and completed Orders; each representative record remains attached to the correct company and user with an understandable status and line history.
Pitfall 4: Collapsing Adobe Commerce Scope Across Websites, Stores, and Store Views
What goes wrong
Adobe Commerce uses a hierarchy of websites, stores, and store views. Scope can affect Product assignments, root Categories, localized text, URLs, configuration, currencies, and B2B commercial context. A global import can overwrite regional or language-specific values and place Products or content in the wrong storefront.
The default store view may look correct while another language, brand, or region displays fallback text, missing Products, or incorrect routes.
Early warning signs
- Products or Categories differ by website or brand.
- Names, descriptions, metadata, and URL keys vary by store view.
- Each store has a different root Category or menu.
- Customers, shared catalogs, currencies, or content are tied to specific websites.
Prevention
Map the source Store hierarchy to Adobe Commerce website, store, and store-view ownership before assigning entity values. Separate global attributes from website-scoped prices and store-view content. Preserve source scope codes when integrations or imports depend on them.
Recommendation example
Use one configurable Product and one CMS Page that have different text, URL keys, and visibility across two store views and two websites. Document which values are global and which are scoped.
Pass condition
Every representative website, store, and store view displays the intended Product assignment, root Category, localized content, URLs, and commercial context without leaking values from another scope.
Pitfall 5: Reducing Complex Product Types to Flat Products
What goes wrong
Adobe Commerce supports simple, configurable, grouped, virtual, bundle, downloadable, and gift-card Products. These types use different parent-child, inventory, price, weight, file, and cart relationships. Flattening them into ordinary Products can duplicate SKUs, remove selectable combinations, break bundle composition, or disconnect downloadable files.
A Product can appear complete but no longer behave like the offer customers previously purchased.
Early warning signs
- Parent and child SKUs are not separately identified.
- Bundle components or grouped Products are stored as text in descriptions.
- Download links and access limits are maintained outside the Product export.
- Custom options are mixed with configurable attributes.
Prevention
Classify Product type before mapping fields. Preserve configurable parent-child associations, variation attributes, bundle options, grouped links, downloadable files, virtual-shipping meaning, and Order-line interpretation. Do not create variants from descriptive attributes that do not identify independent sellable units.
Recommendation example
Use one configurable Product with mixed child stock, one dynamic-price bundle, one grouped Product, and one downloadable Product. Preserve each Product’s distinct composition and fulfillment meaning.
Pass condition
Each representative Product retains the correct parent-child or component structure, selectable values, SKU identity, price source, stock behavior, media, and Order-line meaning.
Pitfall 6: Importing Campaign Content Without Its Staging Timeline
What goes wrong
Adobe Commerce Content Staging can schedule updates to Products, Categories, catalog and cart price rules, and CMS Pages through campaigns. Importing only the currently visible values can discard future campaigns, baseline content, campaign grouping, time windows, and the automatic reversion that follows an end date.
A future promotion may never appear, or campaign content may remain active permanently because the timeline was reduced to static fields.
Early warning signs
| Early warning sign | What it indicates |
|---|---|
| The source contains scheduled Product, price, Category, rule, or CMS changes. | Current values alone do not represent the campaign plan. |
| Marketing teams rely on a staging calendar or campaign names. | Timing and coordinated activation are part of the business meaning. |
| Several entities change together at the same launch time. | A single-record import cannot preserve the campaign relationship. |
| Active content differs from the stored baseline version. | The migration may capture the wrong temporal state. |
Prevention
Inventory baseline values, scheduled updates, campaign membership, start and end times, time-zone assumptions, and affected store views. Decide which campaigns remain relevant and which should be rebuilt as current Adobe Commerce staging records rather than imported as static content.
Recommendation example
Use one campaign that changes a Product price, Category content, and CMS landing page together. Preserve the baseline values and the campaign window as separate states.
Pass condition
The representative campaign has the correct entities, baseline content, schedule, store-view context, and reversion behavior; no future update is silently converted into permanent live data.
Pitfall 7: Copying Quantities Without Rebuilding Sources, Stocks, and Sales-Channel Relationships
What goes wrong
Adobe Commerce inventory separates physical sources from stocks that aggregate sources for sales channels. A quantity without its source, stock, website, status, and salable context can place inventory in the wrong warehouse or make a Product unavailable despite a positive number.
Multi-source Stores are especially vulnerable when all locations are summed into Default Source.
Early warning signs
- Warehouse, store, drop-shipper, or pickup quantities exist separately.
- The source uses allocation, reservation, or channel-specific availability.
- Imported Products default to one source even though several locations fulfill Orders.
- Configurable children have different location coverage.
Prevention
Preserve source identity, source code, source quantity, stock assignment, website relationship, status, and external warehouse key. Distinguish on-hand quantity from the value that can be sold through a given sales channel. Define which system remains authoritative after migration.
Recommendation example
Use one SKU held in two warehouses and one configurable Product whose children are available from different sources. Map each source to the stock serving the intended website.
Pass condition
The representative Products show the correct source quantities, stock and website assignments, salable availability, and fulfillment ownership without collapsing distinct locations into one unexplained total.
Pitfall 8: Treating URL Rewrites and Scoped Content as Simple Slugs
What goes wrong
Adobe Commerce can maintain URL rewrites for Products, Categories, and CMS Pages. Routes may differ by website or store view, and content can contain internal links, media paths, Page Builder structures, or campaign references. Copying only the current slug can remove redirect history and break high-value journeys.
Early warning signs
- The source contains several historical URLs for one entity.
- Product or Category URL keys vary by store view.
- CMS content includes hard-coded source URLs or media paths.
- Campaign, paid-media, or partner links depend on legacy routes.
Prevention
Treat each source path as a relationship between old route, destination entity, scope, redirect type, and intended canonical path. Rewrite internal links and media references according to the destination owner. Keep CMS content, Page Builder layout, and URL history separate.
Recommendation example
Use a Product with a renamed URL, a Category that moved in the hierarchy, and a localized CMS Page. Preserve the canonical destination and all business-critical source paths.
Pass condition
Each representative legacy path reaches the intended scoped destination, internal links and media resolve correctly, and no restricted or localized content is redirected to the wrong website or store view.
Pitfall 9: Preserving Order Totals but Losing Company and Fulfillment Context
What goes wrong
Historical Orders can retain totals while losing company ownership, purchaser role, shared-catalog context, quote or purchase-order lineage, source items, shipments, invoices, refunds, and external transaction identifiers. Staff then see a financial record without enough evidence to support the buyer or reconcile the transaction.
Early warning signs
- B2B Orders are linked only to individual Customers.
- Order lines cannot identify the original configurable child or bundle component.
- Shipment and refund records are stored separately from the Order export.
- ERP or payment references are present only in extension tables.
Prevention
Preserve the Order header, company and buyer identity, addresses, line snapshots, selected options, prices, discounts, taxes, shared-catalog or quote reference, invoices, shipments, refunds, comments, and external IDs. Keep historical snapshots independent from current Product and company settings.
Recommendation example
Use one company Order created from a quote, one partially shipped Order, and one refunded Order containing a configurable Product. Trace every related record back to the Order.
Pass condition
Each representative Order remains understandable to Customer service, finance, and operations, with company, buyer, Product, payment, shipment, refund, and external-system context intact.
Pitfall 10: Copying Extension and Integration Fields Without Their Owning Logic
What goes wrong
Adobe Commerce installations often contain modules, custom attributes, custom tables, APIs, event observers, ERP and PIM identifiers, marketplace records, tax integrations, fulfillment data, and bespoke checkout fields. Copying values into generic fields does not preserve the workflow that creates, updates, or consumes them.
The destination can contain the data while every connected system treats it as missing or stale.
Early warning signs
| Early warning sign | What it indicates |
|---|---|
| Important values have module prefixes or live in custom tables. | The data is likely owned by extension logic rather than a standard entity. |
| External systems identify Products, companies, Customers, or Orders by nonstandard keys. | Cross-system continuity depends on identifiers outside default fields. |
| A field’s valid values are enforced by code rather than database structure. | Copying the value alone will not preserve its rules. |
| Staff cannot explain which system is authoritative for the field. | Ownership conflict may cause the value to be overwritten or ignored. |
Prevention
Create an ownership register for every extension and integration record. Name the parent entity, source table or API, external key, authoritative system, update direction, and destination owner. Exclude obsolete technical residue instead of promoting it into permanent custom fields.
Recommendation example
Trace one Product from PIM to Adobe Commerce, one company from CRM, and one Order to ERP and fulfillment. Record the identifiers and ownership boundaries required at each step.
Pass condition
Each retained custom or integration value has a defined destination owner, stable parent relationship, authoritative system, and usable cross-system identifier; no essential workflow depends on an orphan field.
Cross-Pitfall Prevention Priorities
Adobe Commerce pitfall prevention should preserve five connected layers: company identity, buyer-specific commercial rules, scoped storefront data, Product and inventory relationships, and external-system ownership. A correction in one layer should not silently break another. For example, rebuilding a shared catalog also affects company assignment, category permissions, price indexing, and storefront access.
| Prevention layer | Required control |
|---|---|
| Company and buyer identity | Keep company, location, role, approval, and Customer relationships connected. |
| Commercial assignment | Preserve shared catalog, company assignment, variant price, and purchasing-rule context together. |
| Scoped storefront data | Maintain website, store, and store-view ownership for Products, content, URLs, and Customers. |
| Temporal content | Separate the active state from scheduled campaign versions and coordinated changes. |
| External ownership | Assign extension fields, custom tables, and external identifiers to an authoritative system. |
Conclusion
Adobe Commerce migrations become unreliable when enterprise relationships are reduced to ordinary commerce fields. Companies, roles, shared catalogs, quotes, purchase orders, scoped values, content campaigns, inventory sources, historical Orders, URL rewrites, and integration identifiers each need a clear owner.
The safest migration model treats every pitfall as a broken relationship rather than a missing row. When the parent entities, commercial rules, scopes, histories, and external keys remain connected, the migrated Store can support the enterprise workflows that the records were meant to serve.
Common Questions
Why are Adobe Commerce company users not equivalent to ordinary Customers?
Company users inherit business context from the company account, including roles, permissions, shared catalogs, and purchasing workflows. An individual Customer record does not preserve those organization-level relationships.
Can shared-catalog prices be migrated as ordinary Product prices?
Not safely. Shared-catalog prices belong to specific catalog and company relationships. Moving them into general Product pricing can expose negotiated values to unintended buyers or remove them from the companies that should receive them.
Why must website, store, and store-view scope be preserved separately?
The hierarchy can control Product assignment, root Categories, localized values, URLs, configuration, and commercial context. A global value can overwrite or leak information that was intentionally scoped.
What makes Content Staging different from normal CMS content?
Content Staging preserves baseline values, scheduled updates, campaign grouping, timing, and reversion behavior. The currently visible value represents only one point on that timeline.
Why is a source quantity insufficient for Adobe Commerce inventory?
Inventory meaning depends on the physical source, the stock that aggregates sources, the sales channel or website, status, and the system that remains authoritative. A quantity alone does not identify where or how the item can be fulfilled.
How should extension-owned Adobe Commerce data be handled?
Identify the module or external system, the core entity it extends, the stable identifier, and the workflow that consumes the value. Retain only records with a defined destination owner and continuing business use.