Adobe Commerce preparation starts with the relationships that make enterprise buying work: which company a buyer represents, which assortment and price that company receives, and which website and stock serve the purchase. Capture those relationships in the Source Store before deciding how they will be represented in the prospective Target Store.
Adobe Commerce preparation should turn an enterprise operating model into a controlled evidence package before any migration run begins. The team needs to know how B2C Customers, B2B companies, company users, shared catalogs, websites, stores, store views, Product types, inventory sources, historical Orders, content, and external systems should be represented in the Target Store.
A useful preparation package answers four questions for every important area: what action is required, who owns it, what evidence supports the decision, and what condition makes the area ready. This prevents company relationships, buyer-specific pricing, regional storefronts, or ERP-owned identifiers from being discovered only after sample records have already been migrated.
Establish the Adobe Commerce Operating Decisions
Begin with a concise operating-model record. It should define which commerce structures must exist in Adobe Commerce and which systems remain authoritative outside the Platform.
| Preparation area | Decision to record | Owner | Ready evidence |
|---|---|---|---|
| Buyer model | B2C Customers, B2B companies, company locations, company users, roles, approvers, and sales representatives | B2B and Customer operations | Approved account-relationship diagram with representative source records |
| Catalog model | Product types, attribute sets, Categories, shared catalogs, buyer visibility, and regional assortment | Catalog and merchandising owners | Product-family and catalog-scope matrix |
| Storefront scope | Websites, stores, store views, languages, currencies, brands, regions, and domains | Commerce architecture owner | Website/store/store-view map |
| Pricing ownership | Base prices, tier prices, negotiated prices, shared-catalog prices, and external contract prices | Commercial and integration owners | Price-source register and sample buyer scenarios |
| Inventory ownership | Sources, stocks, websites, warehouses, drop shippers, pickup points, and external inventory systems | Inventory and fulfillment owners | Source/stock ownership map |
| Integration model | ERP, PIM, CRM, WMS, procurement, accounting, tax, shipping, search, and reporting dependencies | Technical owner | Dependency register with durable identifiers |
Record the intended Adobe Commerce build, enabled B2B components and website settings alongside these decisions. A feature available in the Platform does not establish that it is enabled in the destination or included in the migration scope. Keep the operating-model record focused on business relationships and accountable owners; the technical owner separately confirms the implementation prerequisites.
Prepare Access, Source Evidence, and Recoverable Backups
Collect access and evidence from the actual Source Store, then confirm the permissions needed to inspect the Adobe Commerce destination. If the Source uses another Platform, capture equivalent company, catalog, storefront and inventory relationships in its own model; do not require Adobe Commerce-specific exports from it.
Prepare:
- administrator access to the Source Store and the Adobe Commerce environment at the required permission level;
- dated exports or reports for Products, Categories, Customers, companies, company users, Orders, content, reviews, promotions, and other in-scope records;
- database and media backups where available;
- Product attribute, attribute-set, and Product-type references;
- website, store, store-view, language, currency, and domain inventories;
- B2B company, role, shared-catalog, pricing, and credit examples;
- inventory source, stock, warehouse, and fulfillment reports;
- extension, custom-module, API, and external-system inventories;
- high-value URL, redirect, CMS Page, block, and campaign lists;
- screenshots or reports that explain important source behavior.
| Evidence item | Why it is needed | Ready condition |
|---|---|---|
| Access record | Confirms that the required source and target areas can be inspected | Required accounts work and permission owners are identified |
| Export archive | Preserves a dated reference state | Files open correctly and contain the expected record families |
| Database/media backup | Protects available source records beyond ordinary exports | Available backup or export coverage, date, recovery owner and limits are documented |
| Field dictionary | Explains custom labels, flags, and identifiers | Every important field has a purpose, owner, and sample value |
| Scope map | Prevents website, store-view, B2B, and inventory relationships from being flattened | Every in-scope business unit and storefront has an assigned destination |
When an export omits extension or B2B records, document the gap and obtain another evidence source or explicitly exclude the affected scope before execution. For hosted Sources, preserve available exports and media with a provider-confirmed recovery note; do not promise a database restore that the account cannot perform. Missing evidence is a readiness issue, not proof that the records do not exist.
Prepare B2B Companies, Users, Roles, and Purchasing Context
Adobe Commerce B2B preparation extends beyond individual Customer profiles. In an enabled B2B environment, company records can connect users, internal teams, roles, shared catalogs, credit and purchasing rules. Record the actual enabled features and their permission owners. Parent and child companies remain separate company records; they are different from teams inside one company.
Prepare representative evidence for:
- company legal identity, status, tax identifiers, reseller identifiers, and legal address;
- company administrator and company-location relationships;
- buyers, approvers, branch users, purchasing teams, and users associated with more than one company;
- roles and permissions for orders, quotes, purchase orders, users, teams, and company credit;
- credit limit, available balance, currency, payment-on-account context, and credit history where relevant;
- purchase-order approval expectations and purchasing references;
- allowed payment and shipping methods;
- sales representative, ERP account, dealer, procurement, and CRM identifiers.
| Preparation item | Owner | Required evidence | Ready condition |
|---|---|---|---|
| Company identity | B2B operations | Company master list and source IDs | Every company has one intended Adobe Commerce company record |
| User membership | Customer operations | User-to-company and user-to-team matrix, default company and per-company roles | Every company assignment has a defined status, role and purchasing context |
| Permission model | B2B process owner | Role and permission examples | The required purchasing responsibilities are documented |
| Credit and PO context | Finance and procurement | Representative company credit and purchase-order records | Financial and approval relationships have an assigned destination owner |
| External account keys | Integration owner | ERP, CRM, procurement, and dealer IDs | Each key is linked to the correct company or user level |
A buyer may be assigned to more than one company. Preserve a stable user identity, every intended company assignment, the default company and the role or purchasing context for each association. Several company rows for the same email are not sufficient reason to merge or duplicate the person. If the Source expresses B2B meaning through Customer groups, tags, custom fields or external records, prepare a translation ledger that explains those relationships.
Prepare Shared Catalogs, Pricing, and Product Visibility
When shared catalogs are enabled, their company assignments, Product membership and prices determine the intended buyer assortment. Prepare public and custom catalog membership explicitly. The default public shared catalog needs Product assignments; enabling B2B does not establish a complete public assortment. Ordinary Category-permission assumptions should not replace the enabled shared-catalog rules.
| Catalog or pricing record | Preparation action | Evidence |
|---|---|---|
| Public catalog | Define the Products and Categories available to ordinary Customers | Product and Category membership sample |
| Custom shared catalog | Define company assignment, Product membership, and custom pricing | Company-to-catalog and Product-to-catalog matrix |
| Customer-group price | Identify the Customer group and Product relationship | Representative Product and Customer-group example |
| Tier or quantity price | Record Product, threshold, buyer scope, and amount | Price-tier sample with source owner |
| Contract or negotiated price | Identify the external or internal price authority | Buyer/Product price example and external-system key |
| Restricted assortment | Define which companies or groups can view or buy the Product | Visibility sample and exception list |
Normalize duplicate catalog names, obsolete price lists, expired exceptions, and inconsistent Product identifiers before they become Adobe Commerce structures. The ready condition is that each priority company can be associated with an intended catalog and price source without relying on a staff member's memory.
Prepare Product Types, Attributes, and Catalog Governance
Select representative Products by structure, not by popularity alone. Adobe Commerce supports several Product types, and the source records must be classified according to how they are sold and managed.
Include examples of:
- simple Products;
- configurable Products with independently stocked child SKUs;
- grouped and bundle Products;
- virtual and downloadable Products;
- gift-card or custom Product types where relevant;
- Products with custom options;
- Products with localized or website-specific values;
- Products with custom attributes, external IDs, or integration-owned data;
- Products assigned to several Categories or restricted catalogs.
Prepare an attribute-governance sheet:
| Source behavior | Adobe Commerce preparation decision | Ready evidence |
|---|---|---|
| Value defines a sellable variation | Define the configurable parent, sellable child Products and compatible variation attributes in the attribute set | Parent/child IDs, SKUs, global-scope selectable attribute values, stock, price and images |
| Value describes the Product | Define Product attribute, data type, scope, and attribute set | Field definition and representative values |
| Buyer enters a one-time value | Define custom option, extension, or Order-line owner | Storefront and historical Order example |
| Value differs by website or store view | Define attribute scope and localized ownership | Website/store-view value matrix |
| Product is a bundle or group | Define component Products and commercial relationship | Component list, quantities, pricing, and inventory owner |
| Value is external-system metadata | Preserve it at the Product or child SKU level used by the external system | External key and lookup example |
Identify unused attributes for retirement without deleting evidence still needed by historical Orders or integrations. For configurable families, confirm that the variation attributes belong to the chosen attribute set, have global scope and use compatible selectable inputs, such as dropdown or supported swatches. Keep descriptive values and one-time buyer inputs outside the variation identity. The catalog is ready when each major family has an intended type, attribute set, child relationship, Category owner and external-key plan.
Prepare Websites, Store Views, Content, URLs, and Campaign Records
Map the source storefront structure to Adobe Commerce websites, stores, and store views. Record which values differ by brand, region, language, currency, domain, or legal entity.
Prepare:
- website/store/store-view hierarchy;
- language and currency assignments;
- Product and Category content by scope;
- CMS Pages, CMS blocks, Page Builder content, forms, banners, and media;
- scheduled or staged campaign records that still matter;
- Product, Category, CMS, campaign, and localized URLs;
- redirect history and high-value source paths;
- internal links embedded in Product descriptions and CMS content.
| Source route or content | Preparation question | Ready evidence |
|---|---|---|
| Product or Category URL | Which website and store view own the destination route? | Source/destination route ledger |
| Localized content | Which values are translated or region-specific? | Store-view content matrix |
| CMS Page or block | Is it reusable content, page content, campaign content, or presentation-only data? | Content inventory with destination owner |
| Scheduled campaign | Is the content still required, historical only, or intentionally retired? | Campaign decision and content owner |
| Internal link | Which target route should replace the source path? | Link-rewrite list for priority content |
The ready condition is that every priority public route and content asset has an intended destination, scope, or retirement decision.
Prepare Inventory, Customers, and Historical Orders
Inventory evidence should distinguish physical quantity at each source from salable quantity at the stock level. Map intended sources to stocks and stocks to Adobe Commerce websites, including the external inventory authority where used. Record whether other channel behavior depends on an extension. Prepare single-source and multi-source examples, child SKUs, backorders, pickup locations and drop shippers without treating one aggregate quantity as evidence of every location or website.
For Customers and Orders, prepare samples that expose the historical relationships staff must understand:
- B2C registered Customers, guest buyers, multiple addresses, Customer groups, tax treatment, and external IDs;
- company Customers and company users;
- Orders with configurable, bundle, virtual, downloadable, or custom-option Products;
- discounts, taxes, shipping, payment labels, invoices, shipments, credit memos, returns, comments, and external references;
- Orders from each important website, currency, region, company, or fulfillment path.
| Area | Owner | Evidence | Ready condition |
|---|---|---|---|
| Inventory sources and stocks | Inventory operations | Source/stock/location map and SKU samples | Every priority SKU has a declared stock owner and website relationship |
| Customer identity | Customer operations | Duplicate, guest, address, group, and external-ID examples | Identity and merge rules are documented |
| Historical Order meaning | Support and finance | Representative Order packet | Product lines, totals, statuses, fulfillment, refunds, and references are explained |
| Sensitive data | Legal and data owner | Approved field list | Unnecessary personal or financial data is excluded |
Prepare Customer identity separately from account access. The exact Source-to-Target path determines whether usable password-verification continuity can be preserved or whether reset, activation or first-login handling is needed; assign that decision and the customer communication to an owner. Historical Orders remain evidence of past commerce. They do not transfer live payment authorizations, inventory reservations, fulfillment tasks or notification behavior; those require separate destination implementation and controlled execution decisions.
Inventory Extensions, Custom Modules, and External Systems
Create one dependency register for every extension, custom module, integration, scheduled job, custom table, API, and external system that creates or modifies in-scope records.
For each dependency, record:
- business purpose;
- core records extended;
- tables, attributes, statuses, or identifiers created;
- data owner and technical owner;
- export or API availability;
- target owner or replacement system;
- stable keys needed for reconnection;
- records that can be retired or archived.
Priority dependencies commonly include ERP, PIM, CRM, WMS, procurement, search, subscriptions, loyalty, reviews, tax, payment, shipping, marketplaces, analytics, reporting, and custom B2B workflows.
The register is ready when every important dependency has a named continuing owner and no critical field is described only as “the extension handled it.”
Select Representative Migration Test Samples
Choose a sample set that exposes the enterprise decisions prepared above. Do not use random Products or only straightforward Orders.
| Sample | Preparation purpose |
|---|---|
| Simple and configurable Product family | Establish Product type, child SKU, attribute, media, and inventory patterns |
| Bundle or grouped Product | Expose component and pricing relationships |
| B2B company with several users | Expose company, team, role, and external-ID relationships |
| Shared-catalog Product | Expose company assignment, visibility, and pricing evidence |
| Multi-source inventory SKU | Expose source, stock, website, and external inventory ownership |
| Localized Product or CMS Page | Expose store-view scope and route ownership |
| Complex historical Order | Expose Product lines, totals, fulfillment, credit memos, and external references |
| Extension-owned record | Expose custom fields, tables, and target ownership decisions |
For each sample, provide the source ID, source URL where relevant, business reason, expected Adobe Commerce owner, related external identifiers, known exclusions, and responsible reviewer. This gives every selected sample a traceable source expectation and named reviewer.
Complete the Adobe Commerce Readiness Gate
| Readiness question | Required evidence | Ready condition |
|---|---|---|
| Are access and backups available? | Access record and dated archive | Required systems and source evidence are recoverable |
| Is the operating model documented? | Buyer, storefront, catalog, pricing, and inventory maps | Every major relationship has an owner |
| Are B2B structures prepared? | Company, user, role, catalog, credit, and PO evidence | Representative company relationships are complete |
| Are Product families classified? | Product and attribute matrix | Each major Product pattern has an intended Adobe Commerce structure |
| Are content and URLs assigned? | Route and content ledger | Priority routes have destinations or retirement decisions |
| Are integrations inventoried? | Dependency register | Every critical dependency has a continuing owner and key |
| Are representative migration samples selected? | Sample ledger | Ordinary and exceptional records are covered |
| Are unresolved items controlled? | Decision log with impact, owner and approved scope decision | Critical gaps are resolved, excluded or held before execution; accepted exceptions have a clear boundary |
The preparation gate is complete when the evidence can be understood by someone outside the team that configured the Source Store and no critical B2B, Product, inventory, Order, URL, or integration decision depends on undocumented assumptions.
Conclusion
Adobe Commerce preparation should produce an enterprise evidence package, not a generic export checklist. Companies, users, roles, shared catalogs, Product types, attributes, store views, inventory sources, historical Orders, content, and integrations all require explicit owners and representative records.
When those decisions are documented before the representative migration test, the team can assess the intended Adobe Commerce representation from controlled evidence rather than discovering the operating model from isolated migrated records.
Common Questions
Which Adobe Commerce preparation record should be created first?
Start with the operating-model map for buyers, websites, store views, catalogs, prices, inventory, and external systems. It determines which detailed evidence and owners are required.
How should Adobe Commerce B2B companies be prepared?
Prepare the company identity, administrator, users, teams, roles, permissions, credit, purchase-order context, catalog assignments, and external IDs as connected records. Do not reduce the company to an ordinary Customer group.
What evidence is needed for shared catalogs?
Provide catalog membership, company assignment, Product visibility, price source, exceptions, and representative Product/buyer examples. Each catalog should have a clear commercial owner.
How should configurable Products be prepared?
Document the parent, sellable children, variation attributes, SKUs, stock, prices, images and external keys. Confirm the attributes have global scope, compatible selectable inputs and membership in the chosen attribute set. Keep descriptive values and one-time custom inputs distinct from variation identity.
Which inventory records need special preparation?
Prioritize multi-source SKUs, configurable child SKUs, pickup or drop-ship locations, backorders, and externally synchronized inventory. Every quantity needs a declared source, stock, website, and system-of-record relationship.
When is Adobe Commerce preparation complete?
It is complete when available source evidence is recoverable, B2B and catalog structures have owners, routes and integrations are assigned, and representative samples are selected. A critical unresolved decision must be resolved, explicitly excluded or held before the affected work proceeds; an owner and due date alone are insufficient.
How should a buyer who belongs to several companies be prepared?
Keep one traceable user identity with the intended company assignments, default company and per-company role or purchasing context. Prepare an example showing which catalog, price and permission apply when the buyer acts for each company. Repeated email rows alone do not prove duplicate people.
Is a public shared catalog ready as soon as B2B is enabled?
No. Confirm that shared catalogs are enabled for the intended destination and that the public catalog contains the intended Products. Prepare the membership and price evidence, including what ordinary buyers should see. An enabled feature is not proof of a complete assortment.