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 |
The document should be specific enough to guide preparation without becoming an Adobe Commerce configuration specification. Its purpose is to establish the destination owner for each business relationship.
Prepare Access, Source Evidence, and Recoverable Backups
Collect the access and source evidence required to interpret the Source Store independently of undocumented staff knowledge.
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 records not exposed through ordinary exports | Backup location, date, and restore owner 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 assign an owner. Missing evidence is a readiness issue, not proof that the data does not exist.
Prepare B2B Companies, Users, Roles, and Purchasing Context
Adobe Commerce B2B relationships require preparation beyond individual Customer profiles. A company can contain users, teams, roles, permissions, shared-catalog assignments, credit, purchase-order behavior, payment restrictions, shipping restrictions, and external account identifiers.
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 | Every company user has a defined company, status, and role |
| 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 |
If B2B meaning is hidden in Customer groups, tags, custom fields, spreadsheets, or external systems, prepare a translation ledger rather than forcing those values into ordinary Customer fields.
Prepare Shared Catalogs, Pricing, and Product Visibility
Shared catalogs can control Product availability and custom pricing for company accounts. Preparation should identify which catalogs matter, which companies receive them, which Products belong to them, and which pricing system is authoritative.
| 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 Product, child simple Products, and variation attributes | Parent/child IDs, SKUs, option 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 |
Remove unused attributes, normalize controlled values, identify required attribute sets, and document fields that should be excluded. The catalog is ready when every major Product family has a clear type, attribute set, child relationship, Category ownership, and external identifier 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 define the relationship among source locations, Adobe Commerce sources, stocks, websites, salable quantity, and any external inventory authority. Prepare examples for single-source and multi-source Products, configurable child SKUs, backorders, pickup locations, drop shippers, and ERP- or WMS-controlled stock.
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 |
Historical Orders should be prepared as evidence of past commerce. Current Adobe Commerce payment, shipping, tax, inventory, and fulfillment configuration remains a separate implementation responsibility.
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 | Every open item has an owner and due date |
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 Product, child simple Products, variation attributes, SKUs, stock, prices, images, and external identifiers. Also identify source values that are descriptions or custom inputs rather than real variations.
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 access and backups are recoverable, B2B and catalog structures have owners, priority routes and integrations are documented, representative samples are selected, and every unresolved decision has an accountable owner.