An Adobe Commerce migration starts with the enterprise operating model the destination must support. Choose the deployment before interpreting catalog, buyer, storefront and integration requirements.
Adobe Commerce offers distinct deployment models:
- Adobe Commerce as a Cloud Service: managed SaaS with Adobe-managed core updates and supported out-of-process extensibility.
- Adobe Commerce on Cloud: PaaS with application, extension and configuration responsibilities to assign.
- On-premises Adobe Commerce: infrastructure and application responsibility remain with the merchant or its providers.
Existing PHP modules, storefronts and content workflows need separate compatibility decisions when moving to SaaS. The shared product name does not make the implementations interchangeable.
Separate three outcomes: the records the selected migration path supports, target configuration, and any separately agreed implementation. Native capability does not establish migration coverage. The useful question is whether those outcomes together support the required buyer relationships, pricing, content operations and storefront scope.
Adobe Commerce as an Enterprise Target Platform
Adobe Commerce can be relevant when the business needs governed commerce across several functions:
- Buyer relationships: company accounts, buyer-specific catalog visibility, purchasing rules and approvals.
- Storefront operations: brands, regions, languages and localized content.
- Merchandising: governed catalogs and campaign decisions.
- Connected systems: ERP, PIM, CRM, tax, warehouse, marketplace, analytics and marketing.
Scale and complexity still need a defined operating owner. Qualify every required capability against the selected deployment and enabled solution.
Products, Customers, Order history and content need to fit the business structure that will use them. Define that structure before using record counts as evidence of readiness.
| Adobe Commerce area | Migration significance | Early planning decision |
|---|---|---|
| Website, store, and store-view scope | Storefronts may represent regions, brands, languages, business models, or catalog contexts. | Decide which values are global, website-level, store-level, or store-view specific. |
| Product types and attributes | Product structure can affect variation behavior, filtering, search, merchandising, and integrations. | Classify product types, attributes, and attribute sets before migration. |
| B2B company accounts | Qualify company accounts and quoting against the selected model. Roles, permissions, credit and purchasing controls need the appropriate enabled B2B solution. | Decide whether source customer data is individual-account data, company data, or custom relationship data. |
| Shared catalogs and pricing | Where the selected B2B solution supports shared catalogs, visibility and prices can vary by buyer context. | Define whether source price lists, customer groups, or contract pricing need compatible mapping, configuration, or project-specific implementation review. |
| Content Staging | In supported Adobe Commerce PaaS/on-premises deployments, merchandising and content changes can be scheduled. | Separate migrated content from target-side campaign scheduling and governance. |
| Extensions and integrations | Enterprise stores often depend on modules and external systems. | Identify unsupported extension records, external IDs, and custom workflows early. |
Without defined target structures, records can arrive yet fail the intended commercial model. Resolve the required representation before full-scale migration.
The Magento-Family Foundation Still Matters
Adobe Commerce PaaS/on-premises shares Magento-family concepts with Magento Open Source: Product types, attributes and sets, Categories, store hierarchy, URL rewrites, Customer groups, Order history, inventory, modules and custom fields.
That familiarity helps interpretation. It does not prove that a PHP extension, theme or deployment approach works unchanged in Adobe Commerce as a Cloud Service.
The same record can acquire a different enterprise role:
- A Product may also need buyer-specific visibility or shared-catalog pricing.
- A Customer may need company membership, roles, permissions or sales-representative context.
- A CMS Page may need campaign timing or staged updates where supported.
Interpret the source meaning in the selected target implementation instead of copying the Magento Open Source plan unchanged.
The comparison below uses classic PaaS/on-premises examples. Confirm the corresponding capability before applying it to SaaS.
| Shared Magento-family concern | Adobe Commerce enterprise extension |
|---|---|
| Configurable products and associated simple products | Buyer-specific visibility, B2B pricing, account-based ordering, and enterprise validation samples. |
| Attributes and attribute sets | Catalog governance across departments, integrations, and PIM or ERP ownership. |
| Website/store/store-view scope | Multi-brand, multi-region, multi-language, and B2B/B2C storefront separation. |
| Customer groups | Shared catalog assignment, company account behavior, pricing, tax, and commercial rules. |
| URL rewrites and CMS content | SEO continuity plus campaign timing, staged content, and enterprise content approval. |
| Extensions and custom data | Project-specific implementation review when modules or outside systems own business-critical records. |
Shared ancestry helps explain the data model; the selected Adobe Commerce deployment determines how the enterprise behavior is implemented.
Storefront Scope and Business Structure
In the classic hierarchy, scope separates several operating decisions:
- Websites: brands, countries, business units, B2B/B2C contexts, base currencies, tax settings or Customer-account separation.
- Stores: catalog navigation through root Categories.
- Store views: language and localized presentation.
Use the hierarchy and configuration available in the chosen deployment; do not let a familiar source label determine the target level.
A Source Platform may distribute the same meaning differently:
- Language values in a translation plugin.
- Brands in Categories and regional prices in custom fields.
- Customer visibility in an app and B2B permissions in another system.
Copying those labels without interpretation can produce complete-looking but commercially wrong scope. Record the intended migration-scope decisions before mapping.
Scope planning should answer practical questions:
| Scope question | Why it matters |
|---|---|
| Which websites will exist at launch? | Website structure can affect account separation, commercial context, currency, and configuration. |
| Which stores and root categories support each storefront? | Navigation and catalog organization may differ by business line or region. |
| Which store views require localized values? | Product names, descriptions, URLs, metadata, CMS Pages, and Blog Posts may need language-specific handling. |
| Which values are global and which are scoped? | Incorrect inheritance can overwrite localized or business-specific data. |
| Which Source Platform structures are not true Adobe Commerce scope? | Categories, tags, customer groups, or custom fields may be misread as websites or store views. |
A migration plan should not let all records fall into a default scope unless the business has intentionally chosen that structure.
Catalog Governance and Product Meaning
In classic PaaS/on-premises catalogs, simple, configurable, grouped, bundle, virtual, downloadable and gift-card Products carry different relationships. Confirm the supported representation in the selected deployment.
A configurable parent and its associated simple Products need coherent SKU, option, price, image and inventory meaning for buyers and administrators. Their visual similarity to source options is insufficient.
Attributes and attribute sets can serve several functions:
- Buyer discovery: Product pages, search, layered navigation and comparison.
- Commerce operations: promotions, reporting and merchandising.
- Connected systems: PIM alignment, ERP references, quote accuracy, marketplace exports and maintenance.
Preserve each field’s business role rather than carrying every attribute forward as undifferentiated display data.
Catalog planning should distinguish display data from operational data:
| Source field type | Adobe Commerce planning question |
|---|---|
| Product specifications | Should the value be customer-facing, searchable, filterable, comparable, or internal only? |
| Variant-driving options | Should the value support configurable products or another product structure? |
| B2B price or availability flags | Do they belong to shared catalogs, customer groups, custom logic, or external systems? |
| ERP/PIM/marketplace IDs | Should they map into supported fields, be preserved through bounded mapping or configuration changes, or require project-specific handling? |
| Old or duplicate attributes | Should they be cleaned, merged, excluded, or retained for historical reference? |
Preserve the fields required by the target catalog model. Reconcile cleanup, merges and exclusions with their discovery, history and integration uses.
B2B Company Accounts and Buyer Relationships
B2B changes the meaning of Customer migration when the business needs company buying. Qualify the selected solution:
- SaaS includes core company management and quoting; that does not establish every required catalog, credit or approval workflow.
- Detailed PaaS/on-premises B2B behavior depends on the appropriate installed and enabled solution.
Review company administrators and buyers, roles and permissions, credit, purchase orders, quotes, payment/shipping restrictions and shared-catalog relationships where required.
Do not infer equivalent ownership from similar source labels:
- A Customer is not automatically a company account.
- A wholesale group is not automatically a buyer hierarchy.
- A dealer price list is not automatically a shared catalog.
- A sales-representative field is not automatically a native company assignment.
For Adobe Commerce B2B migration planning, prepare representative examples:
| B2B example | Migration value |
|---|---|
| Company with one administrator and multiple buyers | Tests account hierarchy and user relationship expectations. |
| Company assigned to buyer-specific pricing or product visibility | Tests shared catalog or customer-group implications. |
| Customer with quote or purchase-order workflow | Exposes target-side configuration and validation needs. |
| Company with credit or restricted payment/shipping methods | Separates historical data from live commercial setup. |
| Source B2B record controlled by custom fields or external CRM/ERP | Identifies project-specific implementation or integration review needs. |
For required B2B outcomes, prove sign-in, catalog visibility, pricing, permissions and the purchasing process together. Customer counts alone leave those relationships untested.
Content Staging, Merchandising, and Launch Timing
Content Staging belongs to the PaaS/on-premises model. It can schedule changes to Products, Categories, catalog/cart price rules, CMS Pages and CMS Blocks. Widgets may depend on the content they render; qualify their behavior separately.
SaaS uses its own content and storefront approach. Content transfer does not recreate either model’s campaign governance.
Classify source promotions, seasonal pages, future Product launches, banners and app/editorial revisions by their intended target treatment:
- Supported content records to migrate.
- Content or scheduling to rebuild in the selected implementation.
- Work needing manual review because no direct equivalent exists.
Use the URL and redirect planning guide when campaign or content routes change; reachability and equivalent page intent need separate proof.
Launch planning should therefore distinguish:
| Content or merchandising item | Planning treatment |
|---|---|
| Ordinary CMS Pages and Blog Posts | Migrate where the exact path and selected content model support it; otherwise agree separate content implementation. Validate content, URLs and metadata. |
| Scheduled promotions | Decide whether rules migrate, need target-side setup, or require manual campaign rebuild. |
| Seasonal landing pages | Validate URL continuity, content blocks, media, and launch timing. |
| Page-builder or app-owned content | Review for documented migration scope, manual rebuild, or project-specific handling. |
| Campaign governance | Treat as target-side workflow planning, not just data transfer. |
A present content record does not prove that source scheduling logic continues. Assign and test the target campaign workflow separately.
Integrations and Enterprise Ownership
Identify ownership across the connected commerce environment:
- ERP: Product IDs, Customer accounts, invoices and inventory.
- PIM: attributes and Product content.
- CRM: company relationships and sales assignments.
- Tax and shipping: live checkout decisions.
- Marketplace, analytics, loyalty, subscription and marketing tools: their own records and continuing behavior.
Those records do not become native commerce data merely because the storefront displays them.
Find the authoritative owner before selecting data handling:
- A displayed field may be owned by another system; copying it may not preserve that process.
- Module records may be absent from an ordinary export.
- Private integration fields may need qualified mapping or separate implementation.
Judge the required value, relationship and consumer, not just the field’s location.
The planning distinction is simple:
| Requirement | Better classification |
|---|---|
| Supported record requires filtering or mapping adjustment | Plan the required filtering or mapping explicitly. |
| Supported record requires configuration-aware treatment | Separate migration treatment from target-side configuration. |
| Extension-owned or app-owned records must be preserved | Qualify supported extraction and destination meaning first; review separately any unsupported records or relationships. |
| Outside-system identifiers must remain operational | Check compatible supported identifier handling first; qualify separately the continuing integration and any unsupported relationships. |
| Live integration must be connected after migration | Target-side implementation, not migrated data alone. |
Explicit data ownership and integration responsibility connect the migrated records with the operation expected after launch.
Conclusion
Plan Adobe Commerce around the chosen deployment and commercial model. Catalog relationships, scoped storefronts, buyer access, content operations and continuing systems must agree; record presence is only one part of that outcome.
Continue with Adobe Commerce fit profiles to assess the business case.
When the destination is established, use the Adobe Commerce preparation checklist for applicable evidence and prerequisites. Apply the checks that match the selected deployment and enabled features.
Common Questions
How is Adobe Commerce different from Magento Open Source for migration planning?
Classic PaaS/on-premises shares Magento-family concepts, but Adobe Commerce planning can add B2B company relationships, shared catalogs, quotes, purchase orders, Content Staging, governance and integrations where supported and required. Adobe Commerce as a Cloud Service has different content, storefront and extension boundaries. Shared ancestry does not prove unchanged PHP-module or theme compatibility.
Does every Adobe Commerce migration require B2B planning?
No. Some Adobe Commerce stores are primarily B2C or content-led. B2B planning becomes important when the source business uses company accounts, wholesale buyers, dealer pricing, sales-assisted purchasing, quote workflows, or account-specific catalog access.
Why is storefront scope important in Adobe Commerce migration?
Website, store, and store-view scope can affect catalog assignment, localized content, URLs, currency, configuration, and buyer context. Migrating data into the wrong scope can make the target store look complete but behave incorrectly.
How should Adobe Commerce custom data be handled?
Identify the required value, relationship and continuing owner, then qualify supported filtering, mapping or configuration. Custom fields and outside-system IDs do not automatically require bespoke handling. Unsupported extraction, extension relationships, bespoke transformations or B2B/integration logic need project-specific review; live behavior and target setup remain separate from storing a value.
What should be validated first after an Adobe Commerce representative test?
Start with representative catalog, scope, Customer, URL and integration-sensitive examples. Include company and shared-catalog relationships where required and supported by the selected solution. The goal is to prove that records support Adobe Commerce behavior, not only that record counts match.