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 Service.
A large Adobe Commerce project does not automatically require the most complex service. Standard Service can remain appropriate when the migration path is supported, source records use recognizable structures, and the customer can operate and validate the service independently. Managed Service becomes valuable when coordination and validation burden are high. Add-ons address specific supported record filtering, field-value transformation, or field remapping needs. Custom Service is the correct escalation path when the required result depends on unsupported records, custom modules, bespoke transformation, non-standard B2B structures, external-system identifiers, or custom migration logic.
Within Next-Cart Migration Services, this evidence distinguishes supported scope, execution responsibility, bounded Add-on needs, and tailored Adobe Commerce requirements.
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.
| Operating-model question | Lower-complexity signal | Higher-complexity signal |
|---|---|---|
| Website and store scope | One website, one store, limited store views | Multiple websites, regional stores, different root Categories, separate domains, or scope-specific configuration |
| Catalog structure | Simple and configurable Products using recognizable attributes | Bundles, grouped Products, custom Product types, complex attribute sets, staged content, or extension-created relationships |
| Customer model | Ordinary Customers and Customer groups | Companies, company users, shared catalogs, negotiated pricing, permissions, credit or approval workflows |
| Integration ownership | Limited external references | ERP, PIM, OMS, WMS, CRM, marketplace, tax, payment, or fulfilment systems controlling business-critical values |
| Customization | Standard platform fields and supported records | Custom modules, database columns, extension tables, custom APIs, bespoke workflows, or outside-system identifiers |
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 Service Can Be the Right Choice
Standard Service 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 Service 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 Service 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 Service Is Safer
Managed Service is appropriate when the migration remains largely within supported behavior but the customer needs Next-Cart specialists to handle execution and provide structured coordination. This can reduce operational pressure in projects with large catalogs, multiple business teams, strict launch windows, or substantial validation responsibility.
Managed Service 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 need a coordinated migration schedule;
- 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 launch window requires controlled issue tracking and escalation.
Managed Service does not expand standard platform support automatically. It changes who handles the migration execution and coordination. If the required output includes unsupported company structures, custom module data, bespoke transformations, or non-standard external relationships, Custom Service may still be necessary for those requirements.
A useful decision rule is to separate execution burden from customization burden. Managed Service addresses the first. Custom Service addresses the second. Some enterprise projects need both managed execution and separately scoped customization.
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;
- preserving selected content or SEO-related information where the migration path supports it;
- using Data Filter, Advanced Data Mapping, or Data Transformation for a defined supported need.
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 Service 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 Service review.
When Custom Service Should Be Considered
Custom Service 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 Service 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.
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 on the same migration path; website, store-view, B2B, and extension complexity is assessed separately. 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 Service. A smaller catalog may require Custom Service because every Product depends on custom attributes, company-specific pricing, or integration-controlled identifiers.
For later Adobe Commerce activity, previously counted eligible records remain counted once on the same migration path; website, store-view, B2B, and extension complexity is assessed separately. Newly eligible Products, Customers, Orders, or Blog Posts may consume Entity Points when migrated for the first time.
Entity Points planning should answer:
| Planning question | Why it matters |
|---|---|
| Which eligible records are in the approved scope? | Establishes the appropriate Entity Points Plan. |
| Which records are obsolete, duplicated, or outside launch needs? | Supports filtering decisions and avoids unnecessary capacity use. |
| Which records were already counted within the purchased migration and fixed path? | Prevents incorrect duplicate-consumption assumptions. |
| Which new eligible records may be created before launch? | Supports follow-up capacity planning. |
| Which complex structures are not separate Entity Points types? | Keeps complexity assessment separate from volume assessment. |
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 should test the service-path decision with representative and difficult records. Selecting only simple Products can create false confidence in an Adobe Commerce project.
The sample should include, where relevant:
- 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:
- Are standard records represented correctly?
- Do store-scope and B2B relationships remain meaningful?
- Which gaps can be resolved through supported configuration or Add-ons?
- Which gaps require Custom Service or separate target implementation?
A successful Demo Migration is not only a record-count comparison. It provides evidence that the selected service path is strong enough before Full Migration. If the sample reveals unsupported structures or hidden ownership, the approach should change before the full scope is executed.
Additional Migration Options for Adobe Commerce
Additional Migration Options 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.
| Current action | Appropriate situation | Adobe Commerce revalidation focus |
|---|---|---|
| Continue the Migration with the Last Used Configuration | The accepted mapping and scope remain valid, and later source activity must be processed using the same configuration. | New Products, Customers, Orders, Blog Posts, store-scope values, URLs, and integration-linked identifiers. |
| Continue the Migration with a New Configuration | The migration path remains the same, but filtering, mapping, store assignment, or other supported configuration needs to change. | Changed Product structures, website/store/store-view allocation, attribute mapping, B2B scope, content, and URL behavior. |
| Perform a New Migration | The merchant needs a distinct migration result rather than continuing the earlier configuration. | Entire target scope, B2B and store hierarchy, Product model, integration ownership, SEO, and acceptance criteria. |
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.
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.
| Evidence | Likely approach |
|---|---|
| Supported records, ordinary structures, clear scope, customer-led execution and validation | Standard Service |
| Supported scope but demanding coordination, validation, or launch scheduling | Managed Service |
| Standard migration with bounded supported record filtering, field-value transformation, or field remapping needs | Standard or Managed Service with Add-ons |
| Unsupported records, custom modules, bespoke transformation, B2B or integration complexity outside standard behavior | Custom Service, potentially with Expert Handle and agreed Add-ons |
The decision should be documented before Full Migration and confirmed through Demo Migration evidence. A project should not be upgraded merely because Adobe Commerce is an enterprise platform, and it should not remain on a light service path when the accepted target result depends on unsupported enterprise structures.
Conclusion
Adobe Commerce migration approach selection depends on the relationship among record scope, enterprise operating structure, execution responsibility, and customization. Standard Service can support clean and supported migration paths. Managed Service helps when coordination and validation burden are high. Add-ons address bounded supported needs. Custom Service handles tailored and non-standard requirements.
The final decision should account for website, store and store-view hierarchy, Product types, B2B company and shared-catalog context, external systems, Entity Points, and the evidence produced by Demo Migration. Additional Migration Options should then be selected according to whether the accepted configuration remains valid, needs adjustment, or should be replaced with a new migration result.
Common Questions
Can a large Adobe Commerce catalog use Standard Service?
Yes. Record volume alone does not determine the service path. A large catalog can use Standard Service when the migration path is supported, Product structures are recognizable, and the customer can execute and validate the service. Entity Points address eligible record capacity, while structural complexity is assessed separately.
When is Managed Service more appropriate for Adobe Commerce?
Managed Service is useful when the migration remains within supported behavior but execution, coordination, or validation is demanding. It is especially relevant for multi-team projects, multiple storefront scopes, large review workloads, and strict launch schedules.
Do Add-ons cover custom Adobe Commerce modules?
Not generally. Add-ons support bounded needs within supported migration behavior. Data stored in custom modules, extension tables, bespoke B2B structures, or external systems usually requires Custom Service review.
What should Demo Migration prove for Adobe Commerce?
It should prove that representative Products, Customers, Orders, content, store scopes, B2B relationships, URLs, and integration-linked fields remain meaningful. It should also reveal whether gaps belong to configuration, Add-ons, Custom Service, or separate target implementation.
Which Additional Migration Option should be selected?
Continue with the Last Used Configuration when the accepted setup remains valid, continue with a New Configuration when supported settings must change, and perform a New Migration when the merchant needs a distinct migration result and full revalidation.