Selecting the Right Migration Approach for Adobe Commerce

For a move into Adobe Commerce, the deciding question is whether migrated records will support the required company access and storefront scope. A Customer record can arrive correctly while company roles, shared-catalog visibility or buyer-specific prices still need target setup or tailored handling. Choose the Next-Cart service from that distinction, then decide who will execute it.

Selecting the right migration approach for Adobe Commerce requires an operating-model decision, not only a record count. Adobe Commerce can combine configurable Products, multiple websites, stores and store views, B2B company accounts, shared catalogs, company-specific pricing, customer groups, staged content, custom attributes, integrations, and extension-owned records. The service path must reflect which of these structures are ordinary supported data, which require target-side configuration, which can be handled through bounded Add-ons, and which need tailored review through Custom Migration.

A large Adobe Commerce project can use Standard Migration when the path and records are supported and the customer can operate and verify the migration. Managed Migration adds expert execution of the agreed Migration Actions within the same supported capability. Add-ons address bounded supported data changes. Custom Migration addresses tailored scope and can use either Self-Execute or Expert Handle; company access, extension behavior and integration work must be included explicitly rather than inferred from the service name.

Treat scope and execution as two decisions: first identify the supported, enhanced or tailored result, then assign execution and final acceptance. The merchant supplies the business meaning and retains responsibility for verifying the outcome, including when experts perform the agreed actions.

Start With the Adobe Commerce Operating Model

Adobe Commerce projects should be classified by the operating model the Target Platform must support. A single-brand B2C store with one website and conventional Products creates a different migration decision from an enterprise implementation with multiple websites, regional store views, company accounts, shared catalogs, buyer-specific pricing, and tightly connected ERP or PIM systems.

Adobe Commerce uses a website, store, and store-view hierarchy. Websites can have distinct domains and checkout scope. Stores can use separate root Categories and catalogs. Store views often support language or presentation differences. B2B shared catalogs can control which Products and prices are visible to assigned companies. These structures are target architecture, not merely labels attached to migrated records.

When B2B shared catalogs are enabled, they control Category permissions and catalog visibility; an ordinary Customer group label is not equivalent to company access. Review shared-catalog assignment, company user roles and the price a buyer should see as separate requirements. Confirm which B2B features are enabled in the actual target installation before classifying each requirement as supported data, target configuration or custom work.

The migration approach should be selected after this model is documented. Otherwise, a project may be scoped as a standard catalog transfer while the business actually expects enterprise B2B and multi-site behavior to become operational automatically.

When Standard Migration Can Be the Right Choice

Standard Migration is suitable when the Source Platform and Adobe Commerce migration path are supported, the data is accessible through the supported connection setup, and the required output fits standard migration behavior. Under this Next-Cart service, the customer remains responsible for preparation, connection details, configuration choices, execution decisions, and validation.

A strong Standard Migration candidate usually has:

• a clear Product, Customer, Order, and content scope;
• recognizable Product types and variant relationships;
• consistent SKUs and Product identifiers;
• understandable Categories, attributes, and attribute values;
• ordinary Customer and address records;
• historical Orders that do not depend on hidden external-system context;
• a defined website, store, and store-view destination;
• no expectation that extensions, B2B modules, or integrations will be rebuilt through standard record migration;
• a team able to review Demo Migration and Full Migration results in detail.

Standard Migration should not be rejected merely because the catalog is large. Record volume is handled through the selected Entity Points Plan. The more important question is whether the records remain within supported structures and whether the customer can validate the result independently.

The service becomes a weak fit when Products depend on custom types, company pricing is stored outside recognizable B2B structures, external identifiers control fulfilment, or the merchant expects target configuration and module implementation to follow automatically from the data transfer.

When Managed Migration Is Safer

Managed Migration is appropriate when the agreed Adobe Commerce scope is supported but the merchant needs Next-Cart experts to perform its Migration Actions. Multiple storefronts, large catalogs and B2B stakeholders can increase the execution burden. They also increase the customer’s acceptance workload, which should have named owners even when execution is expert-led.

Managed Migration is often safer when:

• catalog, Customer, and Order volume creates a demanding review workload;
• multiple websites, stores, or store views must be validated by different owners;
• business teams can agree a migration schedule but need experts to execute the agreed actions;
• B2B, regional, or channel stakeholders must approve representative samples;
• source data is understandable but inconsistent enough to require careful operational review;
• the merchant cannot confidently manage migration configuration and execution alone;
• the merchant needs expert execution within an agreed launch window and a clear route for migration issues.

Managed Migration uses the same supported migration capability as Standard Migration. Its included expert handling covers agreed Migration Actions; it does not automatically supply B2B implementation, launch project management or approval on the merchant’s behalf. Unsupported company structures, custom module records or bespoke relationships still need Custom Migration review.

For a supported catalog with demanding execution, select Managed Migration. For a tailored company-pricing or module-data requirement, agree Custom Migration scope and then choose Self-Execute or Expert Handle. The customer retains manual access and final verification in either execution model.

Where Add-ons Fit

Add-ons are appropriate when the main migration remains standard but a bounded supported requirement changes the desired output. For Adobe Commerce, the relevant controls are record filtering with field-based conditions for each data type, expression-based field-value transformation, and source-field remapping.

Adobe Commerce examples may include:

• applying Product-field conditions to exclude inactive or obsolete Products;
• applying Customer or Order field conditions to exclude test Customers or irrelevant historical Orders;
• using expressions to transform supported field values during migration;
• remapping supported standard Product, Category, Customer, or Order source fields to compatible supported target fields with the value unchanged;
• mapping an eligible content or SEO-related field to a compatible supported destination when the required operation is field remapping;
• using Data Filter, Data Transformation, or Advanced Data Mapping for a defined supported need.

Adobe Commerce is also eligible for Advanced Database Mapping as a Target. It can be considered when the selected Source setup supports Advanced Database Mapping and the required Adobe Commerce data type, table, field, column, and Value Type are supported and compatible. This can preserve an eligible database-level value, but it does not recreate a custom module, B2B workflow, extension behavior, or external-system logic.

When multiple Standard Add-ons are selected, processing follows Data Filter, Data Transformation, Advanced Data Mapping, then Advanced Database Mapping. Mapping routes the source value, or a value already changed by Data Transformation, without changing it during mapping. Several supported Add-ons can remain a standard scope; Tax is not an eligible data type for either mapping Add-on.

Add-ons should not be used as a general label for every complex Adobe Commerce requirement. Remapping a supported field is different from extracting records from a custom B2B module. Filtering old Orders through an Order-field condition is different from reconstructing a company approval workflow. The first may fit an Add-on; the second requires Custom Migration review or separate target implementation.

The correct boundary is whether the requirement remains inside supported migration behavior. When it does, an Add-on may be sufficient. When it requires non-standard extraction, transformation, logic, or ownership interpretation, it belongs in Custom Migration review.

When Custom Migration Should Be Considered

Custom Migration should be considered when the required result cannot be achieved through standard supported records and bounded Add-ons alone. Adobe Commerce commonly creates this pressure through its extension ecosystem, B2B structures, multi-site scope, and external-system dependencies.

Typical escalation signals include:

• custom Product types or relationships created by modules;
• custom attributes that require bespoke target transformation;
• company accounts, company users, shared catalogs, or negotiated pricing stored in non-standard structures;
• custom checkout fields or Order data stored in extension tables;
• ERP, PIM, OMS, WMS, CRM, tax, or fulfilment identifiers that must be preserved in a specific target field;
• bespoke website/store/store-view allocation rules;
• unsupported records from marketplace, subscription, loyalty, quoting, approval, or returns modules;
• custom database columns, APIs, or integration tables;
• a Custom Platform on either side of the migration path;
• requirements that change standard migration logic.

Custom Migration does not automatically include Adobe Commerce module development, extension installation, B2B configuration, shared-catalog setup, website or store-view construction, theme implementation, payment or shipping configuration, integration deployment, or a complete Target Store rebuild. Those responsibilities are included only when explicitly agreed as part of the service scope.

Selecting CSV, XLS or XML as the Source Platform requires Custom Migration. The standard included file workflow covers Products only; Customers, Orders, company records and other required data must be agreed separately. This differs from a supported platform’s File Upload connection method. For an Adobe Commerce project, a Product export is therefore not evidence that company access or shared-catalog relationships are included.

Entity Points and Enterprise Scope Planning

Entity Points provide a capacity framework for eligible migrated records. For later Adobe Commerce activity, previously counted eligible records remain counted once within the same purchased migration and fixed Source-to-Target path, while newly eligible Products, Customers, Orders, or Blog Posts may consume Entity Points when migrated for the first time. Categories, attributes, companies, shared catalogs, websites, store views, custom fields, modules, and external identifiers can increase complexity without becoming separate Entity Points record types.

This distinction is essential for Adobe Commerce. Two projects can use the same Entity Points Plan while requiring very different service paths. A large catalog of ordinary Products may fit Standard Migration. A smaller catalog may require Custom Migration because every Product depends on custom attributes, company-specific pricing, or integration-controlled identifiers.

Entity Points planning should answer:

Entity Points help size the migration. They do not prove that B2B, multi-site, extension, or integration requirements are supported.

What Demo Migration Should Prove

Demo Migration can test representative records available in the active supported path and expose gaps in the initial service decision. Add-ons and Customization are unavailable in Demo Migration, and Reviews and Coupons are excluded. A standard sample can reveal a need for tailored B2B handling, but it cannot prove the output of that work. Plan paid-scope validation for Add-ons and Custom Migration, and separate target implementation checks from migrated-record checks.

Use the following record contexts to define evidence needs. Include them in Demo only where the active standard path supports them; otherwise assign separate agreed-scope proof:

• simple, configurable, bundled, grouped, virtual, or downloadable Products;
• Products with complex attributes and store-view-specific values;
• Categories used by different stores or root catalogs;
• Customers from important groups or company contexts;
• Orders with discounts, taxes, refunds, unusual statuses, or external identifiers;
• priority CMS Pages, Blog Posts, and URL-sensitive records;
• records influenced by extensions or integrations;
• examples from each website, store, or store view that matters at launch.

Demo Migration should answer four questions:

1. Are standard records represented correctly?
2. Which store-scope relationships are supported, and which B2B requirements still need separate proof?
3. Which gaps can be resolved through supported configuration or Add-ons?
4. Which gaps require Custom Migration or separate target implementation?

A successful Demo is evidence about its limited standard sample. Compare those records with the proposed Adobe Commerce model, record what was not tested, and resolve essential company, store-scope and integration gaps before Full Migration. Customization and Add-on acceptance must use the agreed paid result rather than a Demo that did not run those features.

Migration Actions for Adobe Commerce

Migration Actions support later migration activity when the source remains active, the target configuration changes, or the merchant needs a different migration result. The selected action should reflect whether the previously accepted configuration is still valid.

These actions do not automatically implement Adobe Commerce modules, shared catalogs, company permissions, external integrations, themes, or target configuration. They operate within the agreed Migration Service scope and keep the purchased Source Platform-to-Target Platform path unchanged. A different Source Platform or Target Platform requires a separate purchased migration.

Choose the Migration Action separately from the source-data window. “Migrate only newly added entities” selects records added after the last successful run; it does not select edits to existing Products, contract prices or Customers. “Continue the previous migration” applies to the appropriate earlier migration state. Neither option follows automatically from an action name. A changed configuration also requires checking how earlier and later Adobe Commerce outputs coexist; a new action does not automatically erase protected target data.

Final Service-Path Decision

The strongest Adobe Commerce approach is the lightest service path that can preserve the required business meaning and produce a result the merchant can validate confidently.

Document the choice before Full Migration using standard Demo evidence, accepted Add-on or Custom Migration scope, and target-implementation responsibilities. Use paid validation where Demo cannot test the required output. Adobe Commerce’s enterprise position does not itself require Custom Migration; an essential unsupported company or integration requirement does.

Conclusion

Adobe Commerce service selection should follow the required company and storefront result. Standard Migration fits supported records with customer-led execution. Managed Migration supplies expert execution of agreed actions within that capability. Supported Add-ons can refine the data, while Custom Migration handles tailored requirements with Self-Execute or Expert Handle. Company roles, shared catalogs, modules and integrations need explicit scope and ownership.

Size eligible records with Entity Points, use Demo to evaluate available standard samples, and validate enhancements or customization through the paid scope. For later runs, select the action and source-data window separately and check the combined store-scope and B2B result.

Common Questions