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.
Confirm the exact deployment before choosing a service. The documented Adobe Commerce connection uses KitConnect; a supported platform name does not establish coverage for every Adobe deployment.
For Adobe Commerce as a Cloud Service, obtain explicit path confirmation before treating migration or Add-on support as available. Use platform and connection support to qualify the actual Source and Target setup.
Then separate the service decisions:
- Standard Migration: customer-led execution of supported scope.
- Managed Migration: expert execution of agreed Migration Actions within that same capability.
- Add-ons: bounded supported data changes.
- Custom Migration: tailored scope with Self-Execute or Expert Handle.
Company access, extension behavior and integrations need explicit scope. The migration services overview introduces the available services; agree the actual work and acceptance responsibilities for this project.
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
Document the target operating model before classifying the work. One B2C website with conventional Products differs from a regional, multi-store B2B implementation with company pricing and ERP/PIM dependencies. Complexity identifies questions to resolve; it does not select the service automatically.
For a compatible classic deployment, separate:
- Website scope: domains, commercial configuration and checkout.
- Store scope: root Categories and catalog organization.
- Store-view scope: language and presentation.
- Enabled B2B: company access, shared-catalog assortment and buyer-specific prices.
These relationships require an agreed target representation, not just matching labels.
Where classic Shared Catalog is enabled, it controls Category permissions. Confirm catalog assignment, company roles and buyer prices separately; a Customer group label is not equivalent to company access. Classify each requirement as supported data, target configuration or tailored work only after checking the actual enabled solution.
| 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 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:
- Records: clear Product, Customer, Order and content scope, with ordinary Customer/address records.
- Catalog: supported Product/variant relationships, consistent SKUs and IDs, and understood Categories, attributes and values.
- History: Orders whose required context is accessible and supported.
- Destination: agreed website/store/store-view allocation where applicable; extension, B2B and integration implementation assigned separately.
- Execution: a team able to configure, run and review both Demo and paid results.
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.
Pause the Standard Migration decision when custom Product types, externally held company pricing or fulfillment IDs leave the required result unclear. Check supported mapping and Add-ons first. Escalate only the unsupported handling; assign target configuration and module implementation separately.
When Managed Migration Fits
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.
Expert execution can be useful when:
- Execution capacity: the merchant needs help with supported configuration and agreed Migration Actions, including a defined launch window and migration-issue handling.
- Coordination: business teams agree the schedule while experts perform the actions.
- Acceptance workload: large catalogs, inconsistent source data, regional store scope, B2B or channel stakeholders require careful review by named business owners.
Expert execution does not transfer those owners’ acceptance decisions.
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
Use Standard Add-ons when a requirement stays within supported behavior but needs record selection, a value change or a different compatible destination. For the exact Adobe Commerce setup, qualify both migration sides and the requested fields.
Adobe Commerce examples may include:
- Data Filter: use supported Product, Customer or Order field conditions to exclude obsolete Products, test Customers or irrelevant Order history.
- Data Transformation: use supported expressions to change values.
- Advanced Data Mapping: route supported Product, Category, Customer or Order values unchanged to compatible supported fields. Eligible content or SEO values need the same compatibility check.
Select the control for the required operation rather than the complexity of its field name.
The supported Adobe Commerce Target is listed for Advanced Database Mapping. That listing does not extend it to an unconfirmed deployment. Check eligible Source setup, Target, data type, table/field/column, schema and Value Type compatibility for the actual requirement.
Preserving an eligible value does not recreate a module, B2B workflow, extension behavior or external-system logic.
The processing order is Data Filter → Data Transformation → Advanced Data Mapping → Advanced Database Mapping. Mapping routes the source value or the value already transformed; it does not change that value. Several supported Add-ons can remain standard scope. Tax is excluded from both mapping Add-ons.
For example, remapping a supported field differs from extracting unsupported custom B2B records. Filtering Order history differs from rebuilding approvals. Resolve the first through supported controls where eligible; review the second for Custom Migration or separate target implementation.
Custom Migration review begins where required extraction, transformation or logic falls outside supported behavior. Clarify ownership before agreeing that work.
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:
- Unsupported structures: custom Product types/relationships, module-owned checkout or Order records, extension tables, database columns or custom APIs.
- Unsupported business relationships: company users, catalogs or negotiated prices stored outside supported structures; marketplace, subscription, loyalty, quoting, approval or returns records.
- Bespoke handling: unsupported attribute transformations or website/store/store-view allocation rules; changed standard logic.
- Cross-system requirements: ERP, PIM, OMS, WMS, CRM, tax or fulfillment IDs whose required extraction or destination cannot be handled by supported mapping.
- Platform scope: a Custom Platform or a Target outside the supported list requires agreed Custom handling.
A custom field, external key or module label alone is not a Custom Migration trigger. Check the supported compatible route before escalating.
Agree target implementation separately, including:
- Module development and extension installation.
- B2B configuration, shared catalogs and website/store-view construction.
- Themes, payments, shipping and integration deployment.
Custom Migration includes those responsibilities or a full Target Store rebuild only where expressly agreed.
Selecting CSV, XLS or XML as the Source Platform requires Custom Migration. Its included file workflow covers Products only; Customers, Orders, company records and other data require separate agreement.
This differs from a supported platform’s File Upload connection method. For Adobe Commerce, a Product export does not establish company-access or shared-catalog scope.
Entity Points and Enterprise Scope Planning
Entity Points size eligible Products, Customers, Orders and Blog Posts. Records already counted remain counted once within the same purchased migration and fixed actual Source-to-Target path; newly eligible records count when successfully migrated for the first time.
Categories, attributes, companies, shared catalogs, websites, store views, custom fields, modules and external IDs can add complexity without becoming separate Entity Points types.
Equal capacity can hide different requirements. A large supported catalog may fit Standard Migration, while a smaller one may need tailored handling for unsupported company pricing, attribute logic or integration IDs. Assess compatibility before treating those fields as custom scope.
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 tests a limited standard sample on the supported path. It can reveal gaps, but Add-ons and Customization are unavailable, and Reviews and Coupons are excluded.
Use agreed paid-scope evidence for enhanced or tailored output. Verify live target implementation separately.
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:
- Catalog: simple, configurable, bundle, grouped, virtual or downloadable Products; complex attributes; store-view values; Categories from relevant stores/root catalogs.
- Buyers and transactions: important Customer groups/company contexts; Orders with discounts, tax, refunds, unusual statuses or external IDs.
- Content and routes: priority CMS Pages, Blog Posts and URL-sensitive records.
- Dependencies and coverage: extension/integration-linked records and each relevant website/store/store view.
Each example still needs a supported standard sample or a separately agreed proof route.
Demo Migration should answer four questions:
- Are standard records represented correctly?
- Which store-scope relationships are supported, and which B2B requirements still need separate proof?
- Which gaps can be resolved through supported configuration or Add-ons?
- Which gaps require Custom Migration or separate target implementation?
Record what the Demo did not test. Resolve essential company, scope and integration gaps before Full Migration through the agreed paid scope or separate implementation evidence.
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.
| Current action | Appropriate situation | Adobe Commerce revalidation focus |
|---|---|---|
| Continue the Migration with Last Saved Configuration | The earlier paid configuration remains valid; select the applicable source-data window independently. | 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 first paid run, or a fresh migration cycle rather than continuation of the earlier result. | Entire target scope, B2B and store hierarchy, Product model, integration ownership, SEO, and acceptance criteria. |
Migration Actions do not rebuild modules, shared catalogs, company permissions, integrations, themes or target configuration. They operate within the agreed service scope and fixed purchased path. The actual Source and Target Store identities remain binding; changing the platform path requires a separate purchased migration.
Resolve three questions independently:
- Configuration: can the earlier settings still be used, or must supported settings change?
- Source-data window: which newly added records or changes to existing Products, prices and Customers need handling? New-only selection does not include edits.
- Combined result: how will earlier and later outputs, company relationships and protected target data coexist?
An action name does not answer those questions or automatically erase target data. Interruption recovery is also a separate execution concern.
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 Migration |
| Supported scope with agreed Migration Actions requiring expert execution | Managed Migration |
| Standard migration with bounded supported record filtering, field-value transformation, or field remapping needs | Standard or Managed Migration with Add-ons |
| Unsupported records, custom modules, bespoke transformation, B2B or integration complexity outside standard behavior | Custom Migration, potentially with Expert Handle and agreed Add-ons |
Before Full Migration, record the chosen service, standard Demo evidence, agreed enhancement/tailored scope and target-implementation owners. Use paid proof for output Demo cannot test. The service-selection guide explains the shared decision model.
Conclusion
Choose the least complex approach that can deliver the agreed Adobe Commerce result on the confirmed path. Separate supported or tailored scope from customer or expert execution, and assign company access, storefront behavior and integration implementation explicitly.
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
Can a large Adobe Commerce catalog use Standard Migration?
Yes. Record volume alone does not determine the service path. A large catalog can use Standard Migration when the migration path is supported, the required Product structures are supported, and the customer can execute and validate the service. Entity Points address eligible record capacity, while structural complexity is assessed separately.
When is Managed Migration more appropriate for Adobe Commerce?
Managed Migration is appropriate when the Adobe Commerce scope is supported but experts should perform the agreed Migration Actions. The merchant still defines company and storefront expectations, assigns acceptance owners and verifies the result. B2B setup, module implementation and general launch coordination are included only if expressly agreed.
Do Add-ons cover custom Adobe Commerce modules?
Not generally. Add-ons support bounded needs within supported migration behavior. First check whether the required fields and compatible destinations are supported by the applicable Add-ons, including eligible Advanced Database Mapping. Unsupported extraction, relationships or bespoke logic needs Custom Migration review; a module or external-system label alone does not decide it.
What should Demo Migration prove for Adobe Commerce?
It should show how the limited supported sample appears in Adobe Commerce and reveal gaps in store scope, company context or integration-linked fields. It cannot prove Add-on or Customization output because those features are unavailable in Demo, and it excludes Reviews and Coupons. Test tailored B2B requirements through the agreed paid scope and verify target configuration separately.
Which Migration Action should be selected?
- Continue the Migration with Last Saved Configuration: an earlier paid setup remains valid.
- Continue the Migration with a New Configuration: supported settings must change.
- Perform a New Migration: the first paid run or a new result on the purchased path.
Define the source-data window independently, including new records and edits. New-only selection does not include edits to existing records. Revalidate affected store scope, company relationships and the combined target result.
Does Expert Handle include rebuilding Adobe Commerce company access?
Expert Handle covers agreed Migration Actions within Custom Migration; Managed Migration provides expert execution within supported scope. Neither automatically rebuilds company roles, shared catalogs or Category permissions. Define the required access behavior, implementation owner and acceptance evidence in the scope.
Can a Product file export cover an Adobe Commerce B2B migration?
Selecting CSV, XLS or XML as Source Platform requires Custom Migration, whose standard included file workflow covers Products only. Company accounts, company users, shared-catalog relationships, Customers and Orders need separately agreed handling. Confirm the expected company access result rather than treating a Product export as complete B2B scope.