For a move into Magento Open Source, start with the selling unit: a configurable child Product, a simple Product with custom options or another required Product type. Then resolve attribute, store-view and inventory meaning. Those choices define the Next-Cart data scope before customer-led or expert-led execution is selected.
The right Magento Open Source migration approach depends on how much of the source store’s structure must remain usable inside Magento after launch. A small store can still need careful handling if it relies on configurable products, custom attributes, store-view content, extension-owned fields, external IDs, or custom inventory workflows. A larger store can still follow a straightforward path when its data is supported, its structure is clean, and the merchant can validate the output responsibly.
Approach selection should start from Magento-specific evidence: product types, attributes, attribute sets, websites, stores, store views, URL requirements, inventory assumptions, customer groups, order history, extension dependencies, and launch-window timing. Record count matters, but it should not be the only factor. The better question is whether the selected service path can preserve enough structure and business meaning for Magento Open Source to operate as the target store.
A configurable variation is a child Product with its own SKU and inventory, unlike a simple Product’s custom options. Attribute-set and store-view context must remain deliberate. With Inventory Management, source quantity and stock-level salable quantity are different because reservations affect availability. Define the intended snapshot and separately own live inventory configuration.
For Magento Open Source, decide scope before execution: identify the supported records, eligible enhancements or tailored requirements, then choose who performs the agreed Migration Actions. The customer supplies business meaning, retains manual access and verifies the final result even when execution is expert-led.
What Migration Approach Means for Magento Open Source
A Magento Open Source migration approach is a decision about scope, responsibility, customization, and validation. The merchant should know which records are expected to migrate, which target settings must be configured in Magento, which requirements can be handled through Add-ons, which requirements need Custom Migration review, and which Demo Migration samples must pass before Full Migration.
| Work type | Magento example | Service-path implication |
|---|---|---|
| Supported migrated records | Products, categories, customers, orders, coupons, reviews, images, CMS Pages, Blog Posts, and supported related fields. | 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-owned records, custom modules, custom fields requiring non-standard interpretation beyond supported mapping, external IDs, bespoke product logic, or 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. |
This separation keeps the approach realistic. Standard Migration should not be overloaded with unsupported custom requirements. Managed Migration should not be treated as a substitute for scope clarity. Add-ons should not be used as a synonym for Custom Migration. Custom Migration should not be invoked for every complex-feeling case if the real need is supported record filtering, field-value transformation, or field remapping.
Magento Open Source is a distinct destination from Adobe Commerce. Adobe Commerce B2B company accounts and shared catalogs depend on its extension and configuration; their availability must not be assumed from shared Magento lineage. Record handling, required extensions and commercial permissions need separate decisions for the actual target edition.
When Standard Migration May Be Enough
Standard Migration may be suitable when the Magento Open Source migration scope is supported, the target structure is clear, and the merchant can prepare and validate the result without heavy coordination. It works best when products, categories, customers, orders, and content follow recognizable patterns; attribute and attribute-set needs are manageable; and custom module data is not central to the migration expectation.
| 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. |
Standard Migration still requires serious validation. Magento’s flexibility can hide errors that do not appear in record counts. The merchant should be able to review Demo Migration samples, confirm product type behavior, inspect attributes, check URLs, review customers and orders, and decide whether Full Migration output is acceptable.
When Managed Migration May Be Safer
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 expert-executed actions, migration timing and the customer’s acceptance owners. Magento deployment, indexers, theme work, extension configuration, live inventory and wider launch management remain separately owned unless included expressly. Unsupported module data or bespoke interpretation requires Custom Migration review rather than a broader Managed 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.
When several Standard Add-ons are selected, processing follows Data Filter, Data Transformation, Advanced Data Mapping, then Advanced Database Mapping. Filtering selects records; transformation changes supported values; mapping routes the source value, or an already transformed value, without changing it during mapping. Combining supported Add-ons does not by itself require Custom Migration. Tax is excluded from both mapping Add-ons.
| 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; Tax and extension behavior remain outside mapping. |
| 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. |
The Add-on decision should be practical. If the merchant asks to migrate supported products but exclude discontinued SKUs, an Add-on may fit. If the merchant asks to preserve data created by a custom pricing module, Custom Migration review is more appropriate.
When Custom Migration Should Be Considered
Custom Migration should be considered when the Magento Open Source migration requires custom evaluation or custom migration logic beyond supported behavior. Magento stores frequently contain extension-owned records, custom modules, custom attributes with special handling, external IDs, direct database customizations, ERP or PIM dependencies, search customizations, loyalty systems, subscriptions, marketplace references, and bespoke workflows.
The trigger is not size alone. The trigger is whether the data or behavior has a supported Magento destination under the chosen migration scope. A small custom catalog can need Custom Migration if core selling behavior depends on unsupported fields. A large but clean catalog may not.
| 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 | The data may require bespoke extraction, transformation, or target placement. |
| External identifiers used by ERP, PIM, CRM, accounting, marketplace, or shipping systems | Losing IDs can break reporting, reconciliation, fulfillment, or support continuity. |
| 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. |
Custom Migration should be scoped through examples. The merchant should provide representative products, attributes, orders, customers, custom fields whose required handling exceeds supported mapping scope, extension records, external IDs, and expected target outcomes. Without examples, the discussion becomes abstract and the risk of under-scoping increases.
Custom Migration can use Self-Execute or Expert Handle for its agreed Migration Actions. Selecting CSV, XLS or XML as the Source Platform requires Custom Migration; the standard included file workflow covers Products only. Other required data types must be agreed explicitly. This differs from a supported platform’s File Upload connection method, and a Product export alone does not establish the complete Magento Open Source scope.
What Demo Migration Should Decide
Demo Migration can examine a limited representative sample available in the active supported path and reveal gaps in the proposed Magento Open Source approach. Add-ons and Customization are unavailable in Demo, and Reviews and Coupons are excluded. Use the contexts below to identify standard sample checks and requirements needing separate proof. Validate enhanced or tailored output through the agreed paid scope, and assign storefront, extension and live-operation checks to target implementation.
A useful Demo Migration should include:
| 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 help plan eligible migration volume, but they do not measure Magento complexity by themselves. For later Magento activity, previously counted eligible records remain counted once within the same purchased migration and fixed Source-to-Target path; Product-type, store-view, attribute, and extension complexity is assessed separately. Records already counted within the purchased migration do not consume Entity Points again simply because another migration action occurs on the same migration path, even if a later action replaces the previous target result.
Eligible Products, Customers, Orders and Blog Posts consume Entity Points on their first successful migration, once within the same purchased migration and fixed path. Child relationships and record identity need scope review, but attribute sets, store views and extensions do not create additional counted Data Types.
For Magento Open Source, Entity Points should be considered together with data structure and service needs. A product count does not show whether the catalog includes configurable products, bundle logic, many child SKUs, custom attributes, store-view values, extension fields, or external IDs. An order count does not show whether historical records include complex options, refunds, invoices, shipments, custom statuses, or integration references.
| 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 migration has produced a result, Magento Open Source launch planning may require further activity as the Source Store receives Products, Customers, Orders, Reviews, Coupons, CMS Pages, Blog Posts, inventory updates, or URL changes. The correct action depends on whether the recorded configuration remains valid, supported rules must change, or the target result needs a fresh basis. Demo findings inform the first paid configuration; they do not supply 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. |
Under Standard Migration and Custom Migration with Self-Execute, the customer performs the agreed Migration Actions. Managed Migration and Custom Migration with Expert Handle provide expert execution of agreed actions. The customer retains manual access and final verification of child relationships, attribute and store-view meaning, inventory, URLs and historical records. Wider launch or extension responsibilities require 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 the source-data window separately from the action. “Migrate only newly added entities” selects records added after the last successful run, not edits to existing records. “Continue the previous migration” applies to the appropriate previous migration state. Neither option is implied by an action name. When configuration changes, check the combined earlier and later output; a new action does not automatically erase protected target data.
Signals That the Selected Approach Is Too Light
A Magento Open Source approach is too light when it treats structural complexity as ordinary record transfer. The warning signs usually appear before Full Migration if the sample set is chosen carefully.
| 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. |
The approach should be adjusted when these signals appear. Continuing with a weak path usually creates more work during launch review because the team must separate migration defects from unsupported expectations and target-side setup gaps.
Choosing the Practical Path
Select supported scope from child identity, attributes, store-view context and inventory meaning. Standard Migration is customer-led execution; Managed Migration supplies expert execution of agreed actions within that capability. Add-ons address defined supported operations, while Custom Migration handles tailored requirements with Self-Execute or Expert Handle.
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.
If those statements are unclear, the service path is not ready. Magento Open Source migration rewards careful scope discipline because the platform can represent complex commerce structures, but only when the migration plan understands which structures must be preserved, reinterpreted, configured, customized, or left out.
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 right approach is the one that preserves supported Magento meaning without overpromising unsupported behavior. When the merchant separates migrated records from target-side setup, Add-ons, Custom Migration, external systems, and validation responsibility, the migration becomes easier to execute and safer to approve.
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 adjust supported record filtering, field-value transformation, or field remapping. Custom Migration handles unsupported extension data, custom fields requiring non-standard interpretation beyond supported mapping, external identifiers, bespoke transformations, Custom Platform behavior, or custom migration logic adjustment.
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.