A Product can retain its name and price in Adobe Commerce while losing the child SKU, storefront scope or buyer assignment that makes it purchasable. The destination relationship determines what that record means.
In an Adobe Commerce implementation using the classic Commerce Admin model, catalog, account and content records participate in product types, attributes, websites, stores and store views. Installed B2B functionality can add Company and shared-catalog relationships; Content Staging can add scheduled versions. These layers are conditional on the selected offering and implementation. A different Adobe Commerce service or extension must be interpreted through its own model rather than assumed to inherit every Magento-family relationship.
A source store can show clean records while still lacking the structure needed for Adobe Commerce. A customer may exist without company authority. A product may exist without the correct attribute set, website assignment, child SKU relationship, or shared catalog visibility. A page may migrate but lose campaign timing, localization, or route meaning. Data model review should therefore focus on business behavior, not only field presence.
Adobe Commerce Data Meaning Depends on Connected Records
The same Product, Customer, Order or page can participate in several relationships at once. Catalog identity is distinct from website availability, a Customer is distinct from Company authority, and current content is distinct from a scheduled change. Enterprise integrations may depend on all three layers without owning the storefront record itself.
| Data area | Adobe Commerce interpretation | Migration planning implication |
|---|---|---|
| Products | Product types, child SKUs, attributes, attribute sets, websites, categories, prices, visibility, and inventory relationships. | Catalog data must support enterprise selling behavior, not only storefront display. |
| Customers | Individual buyers, customer groups, company users, addresses, order history, and account authority. | Customer data may need to preserve both identity and purchasing context. |
| Companies | Company administrators, company users, roles, permissions, credit, quotes, purchase orders, and approval status. | B2B data should be scoped before treating customers as ordinary accounts. |
| Shared catalogs | Buyer-specific catalog visibility and pricing through customer groups or company assignment. | Product existence does not automatically mean product visibility for every buyer. |
| Storefront scope | Websites, stores, store views, language, currency, content, configuration, and catalog assignment. | Multi-brand, regional, or multilingual data must not be flattened. |
| Content and campaigns | CMS Pages, CMS blocks, scheduled updates, promotion timing, landing pages, and campaign assets. | Static content migration may not preserve time-sensitive commercial intent. |
| Inventory | Sources, stocks, salability assumptions, channel assignment, and external stock ownership. | Quantity should be reviewed in relation to fulfillment structure, not only SKU count. |
| URLs | URL keys, rewrites, redirects, localized paths, custom routes, and high-value landing pages. | SEO continuity depends on route meaning and scope, not only page transfer. |
The practical migration question is whether each record has enough structure to keep working inside Adobe Commerce. A supported record can still need a different target relationship, scope assignment, ownership decision, or implementation boundary when it carries enterprise business rules.
Product Data Depends on Type, Attribute, and Governance Logic
Product type determines the commercial unit. Simple, configurable, grouped, virtual, bundle and downloadable structures distinguish an individual item, a selectable family, a group of independently purchased items, or a configured package. A source kit does not become a bundle merely because several components appear on one page: its component choices, quantities and fulfillment meaning must align with the selected target structure.
A configurable parent presents one buying experience while associated child Products retain sellable SKU identity. A blue medium shirt can therefore have different stock and price from a red large shirt. A simple Product with custom options can capture engraving or another selection without creating the same independently inventoried child relationship. Moving a stock-bearing size into a text option preserves a label but removes the record a warehouse recognizes.
Attributes and attribute sets add another governance layer. Attributes may control visible product fields, search, layered navigation, comparison, import/export behavior, promotion conditions, admin maintenance, and integration logic. Attribute sets group product families into structured templates. A source custom field should not automatically become description text if the field drives filtering, pricing, PIM synchronization, search, reporting, or downstream operations.
| Product structure | What must be interpreted | Why it matters in Adobe Commerce |
|---|---|---|
| Product type | Simple, configurable, grouped, bundle, virtual, downloadable, or custom-handled structure. | Product type controls how buyers select and purchase items. |
| Child SKU relationship | Parent-child assignment, option labels, images, price differences, stock, and identifiers. | Broken relationships can make products visible but not commercially usable. |
| Attributes | Display fields, searchable fields, filterable fields, rule inputs, integration IDs, and admin fields. | Attribute decisions affect catalog governance and buyer discovery. |
| Attribute sets | Product-family templates and required fields. | Poor attribute-set planning makes catalog maintenance hard after migration. |
| Category assignment | Navigation, merchandising, scope, visibility, and URL behavior. | Wrong category meaning can affect discovery, SEO, and buyer confidence. |
| Product relationships | Related products, upsells, cross-sells, accessories, replacements, and compatibility references. | Relationship loss can weaken conversion and sales workflows. |
The goal is not to recreate every source field exactly. The goal is to preserve the commercial meaning of the catalog in a form Adobe Commerce can operate and govern without turning the target catalog into an archive of source-system fields.
Storefront Scope Changes Record Meaning
Adobe Commerce storefront scope can change the meaning of nearly every migrated record. A source platform may represent brands, regions, languages, B2B portals, retail channels, wholesale areas, and international storefronts through categories, domains, customer tags, markets, plugins, or custom fields. Adobe Commerce may require those distinctions to become websites, stores, store views, category trees, customer groups, shared catalogs, configuration rules, or content variants.
A scoped attribute value belongs to an entity, an attribute and its applicable website or store-view context. The scope configured for that attribute determines whether one value is shared or different localized values can exist; a Product name should not be assumed globally shared. Website assignment determines where an item participates, store roots organize catalogs, and store views carry presentation differences. Buyer-group or shared-catalog pricing adds another relationship rather than changing what a localized description means.
Scope mistakes are often invisible in record counts. The expected number of products, categories, customers, or pages can migrate while one storefront receives the wrong language, price, category, visibility, or URL context. The target model therefore needs an explicit assignment for every important brand, region, language, website, store, store view, B2B segment, and private-catalog context.
Inventory has its own scope. A source quantity held at a warehouse corresponds to physical stock ownership; a Commerce stock connects assigned sources to selling websites. Salable quantity expresses availability under the configured inventory model, including reservations and other conditions. Copying both a warehouse total and a derived available total as independent physical quantities would count the same units twice. The translation must preserve which value describes location stock and which describes availability.
Customer Data May Include Individual Identity and Company Authority
With the relevant B2B functionality installed and enabled, account data can connect an individual Customer to a Company, organizational users, purchasing permissions and shared-catalog access. Ordinary Customer identity remains a separate layer. Contact details and historical Orders can identify the buyer without authorizing that person to approve purchases, use Company credit or see negotiated prices.
A Company relationship links identifiable buyers to a commercial organization and its purchasing structure. The source email and address identify a person; Company identity, administrator assignment, hierarchy, account status, legal and tax references, credit context and external account IDs explain the capacity in which that person buys. Permissions and payment credentials are separate from those descriptive relationships and require their own qualified target implementation.
| Customer layer | What to review | Migration implication |
|---|---|---|
| Individual account | Email, name, address, status, password strategy, and order association. | Buyers need recognizable customer continuity. |
| Customer group | Discount, tax, catalog, pricing, or storefront treatment. | Group assignment can affect buyer experience and order accuracy. |
| Company account | Company administrator, legal address, company users, hierarchy, and account status. | Company purchasing may fail if company structure is not planned. |
| Purchasing controls | Quotes, purchase orders, credit, payment methods, shipping methods, and permissions. | B2B workflows may need separate target configuration or implementation beyond the migrated Customer records. |
| External identifiers | ERP ID, CRM ID, dealer ID, account manager reference, contract ID, or tax reference. | External systems may depend on identifiers that are not visible in storefront review. |
Adobe Commerce company data should not be treated as a normal customer field list. It is a purchasing structure. The scope should distinguish transferable identities and relationships from company permissions, purchasing controls, credit behavior, and external integrations that need separate target implementation.
Shared Catalogs Turn Product Access Into Buyer-Specific Data
When B2B Shared Catalog is enabled, the primary catalog remains distinct from public or Company-assigned shared catalogs. Product membership, Company assignment and custom prices form buyer-specific access and pricing. Shared Catalog also controls category permissions when enabled, so copying an old category permission independently may not preserve access. A hidden source Category or dealer tag is evidence of buyer intent, not an equivalent target catalog by itself.
Source platforms often represent this logic in different ways: wholesale price lists, customer tags, dealer groups, hidden categories, private product lists, contract pricing, ERP-driven rules, or custom fields. During migration, these structures need translation rather than simple transfer.
Shared catalog translation should answer four questions: which companies should receive access, which products belong to each catalog, which custom prices apply, and which category permissions or visibility rules must be represented in Adobe Commerce. Source price lists, hidden categories, dealer tags, and ERP contract references are evidence of the intended relationship; they are not automatically equivalent to a shared catalog.
Orders Carry Commercial, B2B, and Integration Context
Order migration into Adobe Commerce should preserve useful history, not imply that every source checkout behavior becomes live Adobe Commerce behavior. Historical orders can include line items, products, quantities, discounts, taxes, shipping, billing, customer references, order statuses, payment references, refunds, invoices, shipments, credit memos, purchase orders, quote references, company context, and external IDs.
For B2B and enterprise stores, order history may need additional interpretation. A source order may belong to a company rather than only an individual customer. A historical discount may reflect a contract price or shared catalog price. A payment method may depend on company rules. A purchase order may have approval meaning. An ERP order number may be more important than the storefront order number for support teams.
| Order context | What to preserve or classify | Why it matters |
|---|---|---|
| Customer and company relationship | Buyer account, company account, administrator or user relationship, and group context. | Support teams need to understand who placed the order and under which account. |
| Financial detail | Subtotal, discounts, taxes, shipping, refunds, credit memos, invoices, and payment references. | History must remain readable for service and reconciliation. |
| B2B workflow context | Quote, purchase order, account credit, approval, or contract reference. | Historical B2B meaning may not be ordinary order data. |
| Fulfillment status | Shipment, partial fulfillment, cancellation, return, warehouse reference, or ERP status. | Operations need to interpret what happened after purchase. |
| External identifiers | ERP order ID, accounting ID, marketplace ID, CRM opportunity, or warehouse reference. | Integration continuity may depend on identifiers outside standard order fields. |
The target order model should account for the distinct relationships carried by B2C orders, B2B orders, refunded or credited orders, discounted and tax-sensitive orders, external references, and company or customer-group context. These relationships determine whether historical Orders remain intelligible after migration.
Invoices, shipments and credit memos describe related financial or fulfillment events rather than interchangeable Order totals. A historical refund amount does not itself recreate a payment-provider refund. Source Order numbers and external ERP keys also remain references to the original transaction; they are not automatically the new native entity IDs. Preserving these links keeps history intelligible without turning an imported snapshot into a new checkout event.
Content, Campaigns, and URLs Need Separate Interpretation
Adobe Commerce content migration can include CMS Pages, CMS blocks, category content, product descriptions, landing pages, Blog Posts owned by an installed content extension when relevant, media, metadata, and promotional assets. For enterprise stores, content may also connect to campaign timing, regional storefronts, merchandising calendars, brand governance, legal review, or approval workflows.
Where Content Staging is available and used, a baseline page or catalog record is distinct from its scheduled updates and campaign relationships. Evergreen content, future campaigns, active changes and expired material therefore carry different time meanings. Flattening the current visible page into one static record loses the distinction between a lasting baseline and a temporary campaign version. Timing and approval behavior remain separate from transferring content values.
URLs require similar separation. Product URL keys, category URL keys, CMS paths, URL rewrites, localized paths, redirects, and custom landing-page routes should be reviewed by business value. A page count may pass while high-value product pages, B2B entry paths, dealer portals, regional URLs, or campaign pages lose continuity.
Integration-Owned Data Must Be Identified Before Mapping
Adobe Commerce projects often depend on ERP, PIM, CRM, OMS, WMS, tax, payment, shipping, marketplace, loyalty, subscription, analytics, search, personalization, or marketing systems. These systems may own fields and identifiers that are not obvious in storefront review.
Examples include ERP product IDs, PIM product IDs, company account IDs, dealer IDs, contract IDs, price-list references, warehouse stock codes, tax exemption IDs, CRM account references, marketplace item IDs, subscription IDs, and external order numbers. If these are removed, renamed, or placed in unsupported fields, the migrated store can look correct while downstream workflows fail.
Integration-owned data should be classified before choosing the final source-to-target mapping. A value may belong in a native attribute, an extension-owned field, a cross-system key, a separate integration payload, or an excluded legacy structure. The decision should follow continuing system ownership rather than the location where the value happened to be stored in the source.
Adobe Commerce Relationships Preserve a Chain of Meaning
A complete Adobe Commerce target model assigns ownership and meaning across the whole relationship chain. Product records support catalog governance; customer and company records preserve purchasing authority; Orders retain serviceable history; content carries the correct storefront and campaign context; URLs preserve route intent; and integration fields remain traceable to the systems that continue to use them.
A Product family and attribute set explain how catalog fields are maintained; website and store-view assignments explain where those values apply. Company, shared-catalog and purchasing relationships explain who can see and buy the item. Historical Orders preserve the buyer, price and fulfillment context at purchase time. Content and URLs carry the storefront and campaign intent, while external keys connect each record to its continuing system. These are linked meanings, rather than five independent record counts.
For example, a dealer price from an ERP is incomplete as a Product price alone. Its meaning also depends on the Company or buyer group, catalog membership and applicable selling scope. The ERP reference identifies the continuing source of that commercial relationship. Choosing a target field resolves only one part of this chain.
Conclusion
Adobe Commerce changes migration planning because data often carries enterprise operating logic. Products are not only items; they are product types, attributes, attribute sets, websites, store views, categories, inventory relationships, and integration references. Customers are not only profiles; they may be companies, users, administrators, customer groups, shared catalog buyers, and approval participants. Content, URLs, orders, and inventory may depend on scope, timing, and external systems.
A strong Adobe Commerce migration treats data-model work as business-meaning translation. The goal is to land records in a structure that supports catalog governance, B2B purchasing, storefront scope, content continuity, and integration ownership.
Common Questions
Why does Adobe Commerce data migration require more than field mapping?
Because many Adobe Commerce records carry operational meaning. Products, Customers, Orders, content, URLs, and inventory can affect B2B purchasing, shared catalogs, storefront scope, attribute governance, and integration ownership.
How are Adobe Commerce shared catalogs different from ordinary categories?
Categories organize catalog navigation and merchandising. With B2B Shared Catalog installed and enabled, shared catalogs connect Product membership, Company assignment and buyer-specific prices. Shared Catalog also controls category permissions when enabled. Category placement alone cannot preserve that buyer relationship.
What makes customer data more complex in Adobe Commerce?
In an implementation using the relevant B2B features, Customer identity can connect to Companies, users, administrators, roles, credit context, quotes, purchase Orders and shared catalogs. These relationships identify who buys for whom; copying contact details does not recreate purchasing permissions, credentials or every live workflow.
Should Content Staging data be treated as normal CMS content?
No. Where Content Staging is used, baseline content and scheduled versions have different time meanings. Evergreen material, future campaigns, active updates and expired changes remain distinct. Transferring stable CMS content does not by itself reproduce scheduling or approval behavior.
When does Adobe Commerce data require separate target handling?
Separate migration handling or target implementation is needed when the scope includes unsupported extension data, custom database structures, nonstandard company or catalog relationships, external-system identifiers, or behavior that has no native Adobe Commerce destination.
How should external identifiers be represented in Adobe Commerce?
Preserve an external identifier only when a continuing ERP, CRM, PIM, fulfillment, tax, or reporting process still depends on it. Decide whether the value belongs in a native field, extension-owned field, integration reference, or a documented cross-system key. The intended outcome is that staff and connected systems can trace the migrated record without exposing the identifier as storefront content or confusing it with the Adobe Commerce entity ID.
Are custom options equivalent to configurable variations?
No. A configurable relationship connects separately identified child Products, such as stocked size and color SKUs. A simple Product custom option can capture a selection without the same independent child inventory. The target structure must preserve whether the source choice identifies a sellable item or describes customization.