An Adobe Commerce destination can contain every expected record and still expose the wrong catalog, price a company buyer incorrectly, or lose the campaign and fulfillment rules behind a sale. The prevention task is to preserve the relationships that make those records commercially usable.
The examples below use Adobe Commerce on Cloud (PaaS) and on-premises structures. Adobe Commerce as a Cloud Service (SaaS) has a different content and extension model; assess its implementation owners and supported workflows separately.
B2B examples require the relevant enabled capabilities. Native availability does not establish what a particular migration will transfer or rebuild.
Relationship loss can leave a Product commercially wrong despite its presence in Admin:
- It belongs to the wrong website.
- Its configurable children are missing.
- It is excluded from the intended company’s shared catalog.
- Its inventory lacks the required source/stock relationship.
These failures affect who can buy, what they see, which price applies, where fulfillment occurs and when content becomes active.
A superficial record check can miss these failures. Give each critical enterprise rule a named 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 without relationship identifiers. | 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, with no proposed destination owner. | Critical B2B behavior has no target owner. |
Prevention
Model each company as the business entity that governs its buyers. Preserve:
- Identity: company ID, addresses and the CRM/ERP account key.
- Organization: administrator, users, teams and role assignments.
- Commercial context: the Customer-group relationship and each intended company membership.
Where multiple-company membership is enabled, keep each association’s role and purchasing context. Email domains or similar addresses cannot establish membership.
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
- Connect company, shared catalog, Product selection, custom price, website scope and Customer group explicitly.
- Keep the public catalog separate from company-specific assortments.
- Preserve external contract IDs that identify the price authority.
- Where Shared Catalog is enabled, check its assignments and resulting Category permissions; older group permissions are not an independent safeguard.
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 as ordinary Orders without their own identifiers, statuses or workflow relationships. | 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 quotes, purchase orders, approvals and requisition lists separately. For each required workflow, preserve:
- Identity: company, creator, approver and external references.
- State and history: status, line items, quantities, negotiated adjustments, comments and dates.
Decide whether an open record must remain active or become reference history. Reference records still need understandable context. Active continuity also requires the target capability, authorized users and a valid approval or negotiation state; imported text cannot prove those conditions.
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. Where active continuity is agreed, authorized users must also be able to perform the next valid workflow action.
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 source scope to website, store and store-view owners before assigning values.
- Respect each attribute’s configured scope, the selected global/website price scope and store-view content ownership.
- Retain source scope codes used by imports or integrations.
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 the relevant relationships:
- Configurable: parent/child associations and variation attributes.
- Bundle/grouped: bundle options and grouped links.
- Delivery: downloadable files and virtual-shipping meaning.
- History: the correct Order-line interpretation.
Descriptive attributes do not create independently sellable variants.
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/Blocks 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. | Preserve links among the affected campaign entities; isolated current values do not prove coordinated activation. |
| Active content differs from the stored baseline version. | The migration may capture the wrong temporal state. |
Prevention
- Version evidence: baseline values, scheduled updates, campaign membership and affected store views.
- Schedule: start/end times and time-zone assumptions, with overlapping source campaigns resolved.
- Destination treatment: decide which campaigns remain relevant and which require rebuilding as current staging records.
A scheduled update applies across store views in its time window. One entity cannot have different simultaneous schedules by view; preserve localized values within the supported campaign structure rather than flattening the timeline into 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, non-overlapping schedule, store-view values, time-zone interpretation, 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/code, source quantity, stock assignment, website relationship, status and the external warehouse key.
- Distinguish on-hand quantity from what the sales channel can sell.
- Reconcile commitments and the target salable-quantity calculation so reserved stock is neither released nor deducted twice.
- Reconstruct the agreed business state; do not copy live reservations without a valid target lifecycle.
- Name the continuing inventory authority.
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 on Cloud and on-premises installations can maintain native 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
- Record each old path, destination entity, scope, redirect type and intended canonical path.
- Rewrite embedded links and media references for the destination owner.
- Keep CMS content, Page Builder layout and URL history distinct.
Use URL and redirect planning to preserve the purpose of each priority route.
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 exported separately without reliable Order links.
- ERP or payment references are present only in extension tables.
Prevention
Preserve the connected Order evidence:
- Identity: header, company/buyer, addresses and external IDs.
- Items and terms: line snapshots, selected options, prices, discounts and taxes.
- Commercial lineage: shared-catalog or quote reference.
- After-sale history: invoices, shipments, refunds and comments.
Keep these snapshots independent from current Product and company settings. Historical continuity does not recreate live payments, reservations, fulfillment or notifications.
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
Integration dependencies can appear in several forms:
- Commerce code/data: modules, custom attributes/tables, APIs, event observers and bespoke checkout fields.
- Catalog and accounts: ERP/PIM identifiers and marketplace records.
- Operations: tax integrations and fulfillment data.
Generic fields cannot reproduce the workflow that creates, updates or consumes a value.
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. | Check the field’s owner, parent entity and consuming logic; a prefix or custom table alone does not establish its meaning or portability. |
| External systems identify Products, companies, Customers, or Orders by nonstandard keys. | The external key must remain linked to the correct destination entity, whether stored in a standard or custom field. |
| 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
For each retained extension or integration record, identify:
- Parent entity and source table/API.
- External key and authoritative system.
- Update direction and destination owner.
Agree what obsolete technical residue can be excluded, preserving the source evidence before retirement.
For SaaS, reassess legacy PHP-module and custom-table behavior against a supported out-of-process implementation. Retaining the value does not make the original module portable.
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
Keep the controls below connected. Product composition and inventory link company buying rules to scoped availability, campaign timing and external-system ownership; fixing one relationship must not break another.
For example, rebuilding a shared catalog can affect company assignment, Category permissions, price indexing and storefront access. Use the preparation evidence to record the owners and dependencies before changing them.
| 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
Prevent Adobe Commerce migration pitfalls by keeping company buying, Product structure, scoped content, campaigns, inventory, Order history, URLs and connected systems under explicit ownership.
Carry each representative scenario and pass condition into Adobe Commerce validation. Check the required records and their relationships together, including separately implemented behavior. That evidence determines whether the intended workflow is ready.
Common Questions
Why are Adobe Commerce company users not equivalent to ordinary Customers?
In the enabled classic B2B solution, 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 if company-specific pricing must be preserved. 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?
In the classic model, 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?
In Adobe Commerce on Cloud and on-premises implementations, Content Staging preserves baseline values, scheduled updates, campaign grouping, timing, and reversion behavior. The currently visible value represents only one point on that timeline. Separate simultaneous schedules for the same entity by store view cannot be assumed.
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.
Can the same prevention plan be applied unchanged to Adobe Commerce SaaS?
No. Preserve the business relationships and acceptance outcomes, but reassess the target content, storefront, B2B, and extension owners. Native PaaS/on-premises staging, URL, PHP-module, or storage assumptions do not establish SaaS parity or migration coverage.
Does preserving an open B2B record mean its workflow can continue?
No. An understandable quote or purchase-order history is different from a record that authorized users can continue negotiating, approving, or purchasing. Agree which outcome is required, then prove the target capability, company membership, permissions, status, and supporting relationships for that outcome.