Define the Next-Cart migration scope for Magento Open Source before selecting customer or expert execution. Confirm the selling unit, attribute/store-view context and inventory basis for the agreed Migration Actions.
Size does not decide the approach:
- A small Store may need special treatment for configurable Products, custom attributes, store-view content, extension fields, external IDs or custom inventory workflows.
- A larger Store can follow a straightforward path when its data is supported, the structure is clear and the merchant can validate the result.
Organize evidence by responsibility:
- Catalog and scope: Product types, attributes, attribute sets, websites, stores and store views.
- Continuity: URLs, inventory assumptions, Customer groups and Order history.
- Delivery: extensions, integrations and launch-window timing.
Record volume helps size the work; the selected path must also preserve the required business meaning.
Keep customer business input, manual access and final verification explicit, including when experts execute the migration.
What Migration Approach Means for Magento Open Source
Choose scope, responsibility, customization and proof together. Confirm migrated records, separate Magento setup, eligible Add-ons, Custom requirements and the available standard Demo checks before Full Migration.
Use the Migration Service overview to view the options; qualify the chosen scope and responsibilities separately.
A configurable choice has child Product identity, SKU and inventory; simple Product custom options use a different model. Keep attribute-set and store-view context deliberate.
Physical source quantity also differs from stock-level salable quantity because reservations affect availability. Define the snapshot and separately own live inventory configuration.
| Work type | Magento example | Service-path implication |
|---|---|---|
| Supported migrated records | Products, Categories, Customers, Orders, Coupons, Reviews, images, CMS Pages, Blog Posts and related fields where the actual path and target representation support them. | May fit Standard Migration or Managed Migration depending on complexity and execution needs. |
| Supported record filtering, field-value transformation, or field remapping | Excluding obsolete products, aligning supported fields, or adjusting supported data output. | May fit Add-ons when the requirement stays within supported behavior. |
| Custom or unsupported requirements | Extension records, modules, fields, external IDs or bespoke Product logic whose required handling exceeds supported mapping; also Custom Platform source data. | Requires Custom Migration review. |
| Magento-side setup | Theme, checkout, payment, shipping, tax rules, store configuration, extensions, indexers, cache, integrations, and deployment settings. | Must be prepared and validated outside ordinary data migration output. |
Keep the service decisions distinct:
- Standard Migration: customer execution of supported scope.
- Managed Migration: expert execution of agreed supported work; scope still needs definition.
- Add-ons: bounded supported operations.
- Custom Migration: agreed requirements beyond supported behavior.
Use service-selection guidance to compare responsibility; do not label a supported operation custom merely because it feels complex.
Magento Open Source is a distinct destination from Adobe Commerce. Adobe Commerce B2B setup depends on the offering: cloud-infrastructure and on-premises deployments use a separately licensed, installed and enabled extension, while Adobe Commerce as a Cloud Service includes core B2B capabilities. Qualify company-account and shared-catalog requirements for the actual offering; shared Magento lineage does not establish those capabilities in Open Source. Record handling, required extensions and commercial permissions need separate decisions for the actual target edition.
When Standard Migration May Be Enough
Standard Migration can fit supported, well-defined scope when the merchant can prepare and validate the result. Product and content patterns, attributes and store hierarchy must be manageable; essential custom-module behavior cannot be assumed included.
| Standard Migration readiness signal | Magento-specific reason |
|---|---|
| Product types are ordinary and documented. | Simple, configurable, virtual, downloadable, grouped, or bundle expectations can be reviewed within supported scope when examples are clear. |
| Attributes are controlled. | Source fields are classified, normalized, and not treated as unlimited target clutter. |
| Website/store/store-view structure is simple. | The target hierarchy does not require extensive localized mapping or multi-store governance. |
| URLs and content needs are manageable. | Priority product, category, CMS Page, and Blog Post routes can be prepared and reviewed without custom handling. |
| Inventory is straightforward. | Stock expectations are clear enough for customer-led review. |
| Customer groups and order statuses are informational or simple. | Historical records remain useful without complex business-rule preservation. |
| Extension and integration dependencies are limited. | Standard records are enough for the accepted migration outcome. |
Customer-led execution still needs evidence:
- Review available Demo samples and Product-type behavior.
- Inspect attributes, URLs, Customers and Orders.
- Decide whether the full agreed result is acceptable.
Counts alone cannot show that Magento relationships remain usable.
When Managed Migration Fits the Execution Work
Managed Migration fits supported Magento Open Source scope when experts should perform the agreed Migration Actions. Many child SKUs, localized values or a large Order history can increase execution workload without making the scope custom. The customer supplies acceptance criteria and verifies the final result.
Agree the expert-executed actions, timing and customer acceptance owners. Keep wider Magento work separately assigned:
- Deployment, indexers and theme work.
- Extension configuration and live inventory.
- Wider launch management, unless expressly included.
Unsupported module data or bespoke interpretation needs Custom Migration review; Managed execution does not expand capability.
| Managed Migration fit | Magento scenario |
|---|---|
| Supported scope with many review points | The accepted supported data needs expert execution; the customer defines review points and verifies output. |
| Complex but supported catalog | Configurable products, attribute sets, product images, category assignments, and URL keys require structured review. |
| Multi-store or localized content | Store-view-specific names, descriptions, metadata, and pages need careful validation. |
| Launch timing is sensitive | New source orders, customers, or inventory changes may need close-to-launch action planning. |
| Internal migration bandwidth is limited | The merchant needs more execution support while still validating the result. |
Managed Migration does not make unsupported data supported. If the requirement involves custom module tables, extension-owned entities, bespoke transformations, external-system logic, or Custom Platform behavior, Custom Migration should be evaluated even if Managed Migration is also useful for execution support.
When Add-ons Are the Right Fit
Add-ons are appropriate when the requirement is specific, bounded, and still within supported migration behavior. They are useful when the merchant needs data-type-specific record filtering, expression-based field-value transformation, or source-field remapping without unsupported custom data handling.
For Magento Open Source, Add-ons can help when the source store includes outdated records, supported field values that need a defined transformation, or supported standard source fields that need different supported target fields with the values unchanged. The requirement should be stated as a concrete acceptance rule.
Standard Add-ons run in this fixed order:
- Data Filter: select eligible records.
- Data Transformation: change supported values.
- Advanced Data Mapping: route supported source or transformed values.
- Advanced Database Mapping: route eligible database-level values.
Mapping itself leaves values unchanged. A supported combination does not by itself require Custom Migration. The standalone Tax Data Type is excluded from both Standard mapping Add-ons. Tax-related fields within another supported record, such as Order tax amounts, require exact data-type, field and active-path compatibility. Mapping does not configure current tax calculation rules. See Add-on responsibilities for the boundaries.
| Add-on need | Magento example | Boundary check |
|---|---|---|
| Data Filter | Apply field-based conditions to supported Products, Customers, Orders, Blog Posts, or CMS Pages so only matching records migrate. | Filtering should not remove records needed for support, SEO, or reporting. |
| Data Transformation | Apply expressions to transform supported field values during migration. | The expression and output must remain within supported migration capability. |
| Advanced Data Mapping | Remap supported standard Product, Customer, Order, or content source fields to compatible supported target fields while keeping the values unchanged. | Mapping cannot recreate unsupported module behavior. |
| Advanced Database Mapping | Map a supported source database column to a compatible Magento Open Source database column while keeping the value unchanged. | Magento supports this Add-on as Target. The exact Source setup and eligible data type, table, field, column and Value Type must also be supported and compatible; the standalone Tax Data Type is excluded, and mapping does not configure tax rules or recreate extension behavior. |
| Bounded special need | Identify a concrete supported filtering, transformation or mapping operation. | Unsupported extension data, custom fields that do not fit supported mapping, or external IDs may require Custom Migration instead. |
Illustrative choices:
- Exclude discontinued SKUs with Data Filter when supported conditions express the rule.
- For custom pricing-module data, qualify supported fields and their consumer; refer handling beyond that scope to Custom Migration.
A module label alone does not decide the service.
When Custom Migration Should Be Considered
Consider Custom Migration when the required handling exceeds supported behavior. Review the actual need behind:
- Module records, custom attributes or database customizations.
- External IDs, ERP/PIM dependencies and search customizations.
- Loyalty, subscriptions, marketplaces and bespoke workflows.
A custom-labelled field or column can still fit supported mapping when the exact roles, locations, Value Type and behavior qualify. Use Custom Migration scope for the remaining requirements.
Judge support for the required data and behavior before catalog size. A small catalog can need Custom Migration when core selling behavior depends on unsupported fields; a large, clean catalog may fit supported migration scope.
| Custom Migration trigger | Why it changes the approach |
|---|---|
| Extension-owned product, customer, order, pricing, loyalty, subscription, or review data | Standard records may not contain the data that drives the business process. |
| Custom module tables or custom database columns | Custom review is needed when extraction, transformation or placement exceeds eligible supported routing; the column label alone does not decide. |
| External identifiers used by ERP, PIM, CRM, accounting, marketplace, or shipping systems | Preserve IDs for reporting, reconciliation, fulfillment and support. Custom review is needed when that requirement exceeds supported field or database mapping. |
| Custom product builders, bundles, or configurable logic | Standard product mapping may not preserve the selling behavior. |
| Nonstandard order statuses, approval stages, or fulfillment workflows | Historical order interpretation may need custom preservation. |
| Custom Platform source behavior | Source structures may need custom analysis before Magento mapping can be trusted. |
Scope tailored work through examples:
- Products, attributes, Customers and Orders.
- Fields whose required handling exceeds supported mapping.
- Extension records and external identifiers.
Attach the expected target outcome to each example; otherwise important scope can remain hidden.
Custom Migration can use Self-Execute or Expert Handle for its agreed Migration Actions. For file-based Source selections:
- CSV, XLS or XML requires Custom Migration.
- The standard included workflow covers Products only; other data types need explicit agreement.
This is distinct from a supported platform’s File Upload connection method. A Product export alone does not establish the complete Magento scope.
What Demo Migration Should Decide
Demo inspects a limited sample available on the active supported path. Add-ons and Customization are unavailable; Reviews and Coupons are excluded.
Use Demo Migration guidance to understand the standard sample boundary. Enhanced or tailored output needs agreed paid proof; storefront, extension and live-operation behavior must pass separate target acceptance rather than being inferred from transferred records.
Use the following contexts to review available Demo records. A row outside the actual sample remains a separate proof requirement:
| Sample area | Decision it should support |
|---|---|
| Simple product | Confirms baseline product, category, image, price, tax, URL, and stock mapping. |
| Configurable product | Confirms parent/child SKU structure, variation attributes, images, prices, and inventory meaning. |
| Bundle or grouped product | Reveals whether product relationships require supported mapping, target setup, or Custom Migration. |
| Product with custom options | Tests whether option behavior remains readable and useful. |
| Attribute-heavy product | Checks available standard attribute values and context; filtering and storefront/admin behavior need separately owned acceptance. |
| Store-view-specific product or page | Tests localization, metadata, URL keys, and content assignment. |
| Customer group example | Confirms whether source segmentation maps cleanly or needs another path. |
| Refunded or discounted order | Tests order history, selected options, totals, tax, payment labels, and support value. |
| Extension-owned field or external ID | Identifies a supported destination or gap; Add-on/custom output needs agreed paid proof and extension setup remains separate. |
A limited standard sample can reveal lost child relationships, incorrect attribute meaning, wrong store-view context, unclear URLs or unreadable history. Use each gap to identify supported configuration, an eligible Add-on, tailored scope or target implementation. Demo cannot prove enhanced output, bespoke module handling or Magento launch readiness.
Entity Points and Magento Scope Planning
Entity Points size eligible volume rather than Magento complexity. Within the same purchased migration and fixed Source-to-Target path, an eligible record is counted once; later actions do not count it again merely because they replace a previous target result.
Eligible Products, Customers, Orders and Blog Posts consume Entity Points on their first successful migration. Child relationships and record identity still need scope review; attribute sets, store views and extensions do not add counted Data Types.
Use Entity Points alongside structural evidence:
- A Product count does not explain configurable children, bundles, attributes, store-view values, extension fields, images, stock or external IDs.
- An Order count does not explain selected options, refunds, invoices, shipments, statuses or integration references.
Capacity and service requirements answer different questions.
| Scope signal | What it helps estimate | What it does not prove |
|---|---|---|
| Product count | Catalog volume and possible Entity Points usage. | Product-type complexity, attribute governance, image behavior, inventory meaning, or URL readiness. |
| Customer count | Buyer-record volume. | Customer-group meaning, duplicate quality, loyalty references, B2B-like assumptions, or external IDs. |
| Order count | Historical order volume. | Payment labels, refunds, shipments, invoices, selected options, status interpretation, or ERP references. |
| Blog Posts count | Content volume when relevant. | Whether content routes, metadata, internal links, media, and redirects are launch-ready. |
Entity Points should support planning, not replace service-path judgment. The selected approach should still be based on supported behavior, customization needs, execution responsibility, and validation evidence.
Migration Actions for Magento Open Source
After a paid result, Source changes may need another action:
- Products, Customers and Orders.
- Reviews, Coupons, CMS Pages and Blog Posts.
- Inventory or URL changes.
Choose whether configuration remains valid, needs revision or requires a fresh result basis. Demo informs the first paid setup; it is not a paid result to continue.
| Migration Action | When it fits Magento Open Source | What must be revalidated |
|---|---|---|
| Continue the Migration with Last Saved Configuration | An earlier paid configuration remains valid; select the required source-data window independently. | New Products and child SKUs, changed stock context, new Customers and Orders, updated content, and a regression sample from earlier migrated records. |
| Continue the Migration with a New Configuration | Review of the earlier paid result or revised target requirements shows that filters, field mapping, store-view handling, content scope, or supported data configuration must change. | Every affected Product type, attribute destination, website/store/store-view assignment, URL field, Customer group, Order sample, and content type influenced by the new configuration. |
| Perform a New Migration | The first paid migration or a distinct result is required on the same purchased path; define the target effect explicitly. | The accepted data scope, protected target data, extension-sensitive samples, URLs and historical records; live launch checks retain their own owner. |
Execution follows the agreed service mode:
- Customer: Standard Migration or Custom Migration with Self-Execute.
- Experts: Managed Migration or Custom Migration with Expert Handle.
The customer retains manual access and final verification of child relationships, attributes, store views, stock, URLs and history. Wider launch or extension work requires explicit agreement.
The first paid run uses Perform a New Migration. Either continuation action requires an earlier paid migration; Demo alone does not establish a paid configuration. These actions keep the purchased Source-to-Target path fixed. A different Source Platform or Target Platform requires a separate purchased Migration Service.
Choose later-run data handling separately from the action. The Additional Option Continue the previous migration carries the most recent migration state into the next pass. For selected supported data types, records not transferred in that state form the new-data delta, and supported relationships can use the carried context. Creation time alone does not define that delta.
Edited source records need explicitly supported handling; the option is not general synchronization of updates. Keep carried state separate from interruption recovery. The Additional Options reference explains this dependency; an action name does not select those rules automatically.
When configuration changes, check earlier and later output together. Confirm the target effect and protect existing data rather than assuming it will be erased.
Signals That the Selected Approach Is Too Light
An approach is too light when it treats unresolved structural requirements as ordinary record transfer. Use representative samples to expose the warning signs before broader execution.
| Warning signal | Likely response |
|---|---|
| Product relationships cannot be classified clearly. | Rework product-type scope or consider Custom Migration. |
| Attribute values are inconsistent, duplicated, or poorly governed. | Clean source values, apply a defined Data Transformation expression where supported, or move bespoke interpretation into Custom Migration. |
| Store-view content appears in the wrong context. | Revisit target structure and store-view mapping. |
| URL keys, redirects, or content routes are launch-critical but unplanned. | Strengthen preparation and validation before Full Migration. |
| Customer groups or historical order statuses drive business rules. | Review whether supported mapping is enough or Custom Migration is needed. |
| Inventory depends on external systems or multi-source assumptions. | Separate migration snapshot, target setup, and integration responsibility. |
| Extension or custom module data is business-critical. | Do not rely on Add-ons unless the requirement remains supported; review Custom Migration. |
Adjust the approach when these signals appear. Separate a migration defect from unsupported expectations and target-side setup gaps before agreeing the correction.
Choosing the Practical Path
A service-path decision is ready when the merchant can state:
- which records are expected to migrate into Magento;
- which Magento settings, extensions, or workflows must be configured directly in the target environment;
- which Add-ons or Custom Migration requirements are in scope;
- which Demo Migration samples must pass before Full Migration;
- which later migration actions may be needed before launch;
- who performs the migration actions and who verifies the final result.
Resolve required uncertainties before execution. The plan must distinguish what will be preserved, reinterpreted, configured, customized or excluded, and who will verify the resulting Magento meaning.
Conclusion
Choose the Magento Open Source approach from child Product identity, attribute and store-view context, inventory meaning and the actual edition’s capabilities. Standard Migration is customer-led supported execution; Managed Migration provides expert execution of agreed actions. Eligible Add-ons refine supported output, while tailored requirements use Custom Migration with Self-Execute or Expert Handle.
The selected approach should preserve agreed Magento meaning within supported capability. Separate record transfer, target setup, Add-ons, tailored work, external systems and verification; clear responsibilities support execution, and observed results support acceptance. Use Magento validation priorities for the evidence plan.
Common Questions
When is Standard Migration enough for Magento Open Source?
Standard Migration may be enough when records are supported, product types are clear, attributes are controlled, store scope is simple, URLs are prepared, inventory expectations are manageable, and the merchant can validate Demo Migration and Full Migration results responsibly.
When should Managed Migration be considered for a Magento migration?
Managed Migration fits supported scope when experts should perform the agreed Migration Actions. A large catalog or localized content may increase execution workload; the customer defines acceptance and retains final verification. Wider coordination, validation services and launch management require explicit agreement.
How are Add-ons different from Custom Migration for Magento?
Add-ons perform bounded supported filtering, value transformation or field/database routing. Custom Migration is for required handling beyond that support, such as unsupported extension records, bespoke interpretation or Custom Platform behavior. A custom field, column or external ID does not automatically require Custom Migration when the exact supported mapping and consumer requirements qualify.
What should Demo Migration prove for Magento before Full Migration?
Demo should inspect available standard records and reveal gaps around Product types, child relationships, attributes, Customers, Orders, inventory and content. Add-ons and Customization are unavailable, and Reviews and Coupons are excluded. Custom or extension-owned output needs agreed paid proof; live Magento behavior needs separately owned checks.
Does the selected service path include Adobe Commerce configuration and extension deployment?
No. Magento Open Source capabilities must be established separately from Adobe Commerce B2B entitlements. The service covers agreed migrated data and custom migration requirements. Website, store-view, extension, theme, payment, shipping, inventory and integration implementation remain separate unless expressly included.
Should configurable child SKUs and custom options use the same migration treatment?
No. A configurable child has separate Product identity and inventory, while a simple Product’s custom options have a different model. Define the required selling unit, attribute context and accepted inventory meaning. Supported migration coverage must be confirmed for that representation; native Magento capability alone does not establish it.
Does matching Magento stock quantity prove that inventory is ready?
No. In Inventory Management, source quantity and stock-level salable quantity are distinct, and reservations affect availability. Define what the migration snapshot represents and separately verify sources, stocks, reservations, live integrations and purchase behavior. Expert execution or database storage alone does not configure that operation.