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.
Confirm the Adobe Commerce deployment model before using the checklist. Website/store/store-view, shared-catalog, PHP-module and Content Staging examples below describe classic PaaS/on-premises implementations where supported and enabled.
Adobe Commerce as a Cloud Service uses different content and extensibility approaches. Core B2B availability does not establish identical company, credit or approval workflows. Confirm each required feature and migration path for the actual deployment.
For each important area, record four things:
- The action required.
- Its accountable owner.
- The evidence supporting the decision.
- The condition that makes the area ready.
This keeps company access, buyer pricing, regional scope and ERP identifiers from becoming discoveries after the first migration test.
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 deployment, intended build, enabled B2B solution and applicable storefront settings. Native availability does not establish that a feature is enabled or included in migration scope.
Business owners define relationships and acceptance needs; the technical owner confirms implementation prerequisites. Use the Adobe Commerce migration approach to resolve supported, enhanced or tailored handling before execution.
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:
- Access: administrator permissions for the actual Source Store and destination.
- Dated records: Products, Categories, Customers, companies, company users, Orders, content, reviews, promotions and other agreed records.
- Recovery: available database/media backups, with coverage and recovery limits.
- Catalog and scope: attributes, attribute sets, Product types, websites, stores, store views, languages, currencies and domains.
- Buyers and stock: B2B roles, catalogs, pricing and credit examples; inventory sources, stocks, warehouses and fulfillment reports.
- Dependencies and content: extensions, modules, APIs and external systems; priority URLs, redirects, CMS Pages/blocks and campaigns.
- Behavior: screenshots or reports explaining source rules that the records alone cannot show.
| 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 |
If an export omits B2B or extension records, obtain another evidence source or explicitly exclude the affected scope before execution. Missing evidence is not proof that the records do not exist.
For hosted Sources, retain available exports/media and a provider-confirmed recovery note. Record the limits; do not promise a database restore the account cannot perform.
Prepare B2B Companies, Users, Roles, and Purchasing Context
For the enabled classic B2B solution, prepare company relationships separately from individual Customer profiles. Users, teams, roles, shared catalogs, credit and purchasing rules need their actual feature and permission owners.
Parent and child companies remain distinct company records. Teams describe structure inside a company; they are not interchangeable with company hierarchy.
Prepare representative evidence for:
- Identity: legal name, status, tax/reseller IDs and legal address.
- Membership: administrator, company locations, buyers, approvers, branch users, purchasing teams and multiple-company associations where supported.
- Permissions: responsibilities for Orders, quotes, purchase orders, users, teams and company credit.
- Finance: credit limit, available balance, currency, payment-on-account context and relevant credit history.
- Purchasing: purchase-order approvals/references and allowed payment/shipping methods.
- External accounts: sales representative, ERP, dealer, procurement and CRM IDs.
| Preparation item | Owner | Required evidence | Ready condition |
|---|---|---|---|
| Company identity | B2B operations | Company master list and source IDs | Every in-scope company has one agreed destination company representation and owner |
| 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 |
Where multiple-company membership is supported, keep a stable user identity, each intended assignment, the default company and the role/purchasing context for each association. Repeated company rows with the same email do not by themselves justify merging or duplicating a person.
If the Source uses groups, tags, custom fields or external records for B2B meaning, prepare a translation ledger explaining those relationships.
Prepare Shared Catalogs, Pricing, and Product Visibility
For enabled classic shared catalogs, prepare company assignment, Product membership and price evidence separately. Include public and custom assortments.
The default public catalog needs Product assignments; enabling B2B does not populate it. Where Shared Catalog is enabled, its rules control Category permissions rather than ordinary Category group-permission settings.
| 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 |
Resolve duplicate catalog names, obsolete prices, expired exceptions and inconsistent Product IDs before creating destination structures. Preserve the original evidence and document approved normalization or retirement in the migration scope record.
Each priority company must have an intended catalog and price source that another reviewer can identify without relying on staff 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:
- Sellable families: simple Products; configurable families with independently stocked child SKUs where applicable; grouped and bundle Products.
- Delivery and special types: virtual, downloadable, gift-card or custom types where relevant.
- Buyer choice: Products with custom options.
- Scope and ownership: localized/website-specific values, custom attributes, external IDs and integration-owned data.
- Placement: Products in 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 |
Before retiring attributes, preserve evidence still needed by historical Orders or integrations.
For classic configurable families, confirm that variation attributes:
- Belong to the chosen attribute set.
- Have global scope.
- Use compatible selectable inputs, such as dropdowns or supported swatches.
Keep descriptive values and one-time buyer inputs outside variation identity. Each major family needs an intended type, set, child relationship, Category owner and external-key plan.
Prepare Websites, Store Views, Content, URLs, and Campaign Records
For a classic deployment, map source scope to websites, stores and store views. For Cloud Service, agree the corresponding supported storefront/content representation rather than assuming that hierarchy transfers unchanged.
In either case, record the business differences: brand, region, language, currency, domain and legal entity.
Prepare:
- Scope: applicable website/store/store-view hierarchy, language/currency assignments, and Product/Category content.
- Content assets: CMS Pages/blocks, Page Builder content, forms, banners and media, with a destination treatment for the selected model.
- Campaigns: staged or scheduled records that still matter.
- Routes: Product, Category, CMS, campaign and localized URLs; redirect history and priority paths; internal links 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 |
Every priority public route and content asset needs an intended destination, scope or approved retirement decision. Use URL and redirect planning to preserve the reason a buyer or search visitor used the original page.
Prepare Inventory, Customers, and Historical Orders
Where Inventory Management uses sources and stocks, distinguish physical source quantity from stock-level salable quantity. Map sources to stocks and stocks to websites, including the continuing external inventory authority.
Prepare examples for:
- Single-source and multi-source operations.
- Child SKUs and backorders.
- Pickup locations and drop shippers.
- Other channel behavior supplied by extensions.
An aggregate quantity cannot prove every location or website relationship.
For Customers and Orders, prepare samples that expose the historical relationships staff must understand:
- People: registered B2C Customers, guests, multiple addresses, groups, tax treatment, external IDs, company Customers and company users.
- Product lines: configurable, bundle, virtual, downloadable and custom-option Orders.
- Transaction evidence: discounts, tax, shipping/payment labels, invoices, shipments, credit memos, returns, comments and external references.
- Coverage: Orders from each important website, currency, region, company and 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 usable password-verification continuity or the need for reset, activation or first-login handling. Assign that decision and customer communication to an owner.
Historical Orders preserve evidence of past commerce. Live payment authorizations, inventory reservations, fulfillment tasks and notifications need 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.
Prioritize dependencies by function:
- Business systems: ERP, PIM, CRM, WMS, procurement and reporting.
- Buyer relationships: subscriptions, loyalty and custom B2B workflows.
- Discovery and channels: search, reviews, marketplaces and analytics.
- Commerce services: tax, payment and shipping.
Use the register above for each dependency’s owner, data and reconnection keys.
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 evidence that another reviewer can use: the intended relationships, applicable target representation, accountable owners and representative source records. Critical gaps must be resolved, excluded through an approved scope decision or held before the affected work proceeds.
Once ready, carry those expectations into Adobe Commerce validation. The test should compare an agreed operating model with actual results, rather than discover that model from isolated migrated records.
Common Questions
Which Adobe Commerce preparation record should be created first?
Confirm the deployment, then create 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?
For the enabled classic B2B solution, 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?
Where multiple-company membership is supported, 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. For the classic shared-catalog model, 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.