For a move into Shopware, distinguish Product presence from visibility in the intended sales channel. Then define variant, property, translated-value and extension ownership before choosing the Next-Cart scope and who will execute its agreed Migration Actions. A record can exist without being discoverable or usable in the required storefront context.
Choosing the right Shopware migration approach depends on more than the number of Products, Customers, Orders, Categories, Coupons, Reviews, CMS content, and related records to move. Shopware adds structural decisions around sales channels, catalog properties, variants, rules, Shopping Experiences, extensions, custom fields, translations, storefront behavior, and integration ownership. Those decisions determine whether the migration can stay within ordinary supported behavior or needs more guided handling.
Choose supported scope from the required channel, variant and property meaning, then select execution. Standard Migration is customer-led; Managed Migration provides expert execution of agreed actions within the same capability. Eligible Add-ons refine supported data. Unsupported extension records or bespoke representation require tailored Custom Migration scope with Self-Execute or Expert Handle; customer acceptance and target implementation remain explicit.
For Shopware, 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.
Start With Shopware Complexity, Not Package Labels
Service choice should begin with the migration pattern, not with a preferred service name. Shopware can receive simple commerce records, but it can also become a structured commerce environment where products, content, sales channels, rules, APIs, and integrations interact. The migration approach should reflect that reality.
Confirm the actual Shopware generation, hosting configuration and extensions. In Shopware 6, sales-channel assignment, active status and extended visibility are distinct decisions. Properties can supply filter information or variant-generation values; those uses need not be identical. Variants can inherit parent values, while typed custom fields have their own definitions and consumers. Native capability does not establish migration coverage or identical handling across Shopware generations.
| Shopware migration pattern | Better starting approach | Why |
|---|---|---|
| Ordinary supported records and simple target setup | Standard Migration | The migration mainly needs record transfer and customer-led review. |
| Clear data scope but high coordination burden | Managed Migration | Experts perform agreed supported Migration Actions; the customer owns review and any broader coordination must be agreed. |
| Supported data with specific record filtering, field-value transformation, or field-remapping requests | Add-ons | The request adjusts supported migration behavior without becoming bespoke work. |
| Unsupported plugins, custom fields whose required handling exceeds supported mapping scope, custom logic, or external-system dependencies | Custom Migration | The work goes beyond ordinary supported transfer and needs tailored assessment. |
| Unclear target operating model | Limited standard Demo evidence, plus paid or target-side proof where required | Samples can reveal whether the assumed approach is realistic. |
This approach protects the project from both overbuying and under-scoping. A simple Shopware migration should not be forced into custom work, but a complex Shopware implementation should not be treated as ordinary just because the entity list looks familiar.
When Standard Migration Can Be Realistic
Standard Migration can be realistic when the source data is ordinary, the target Shopware setup is clear, and the merchant can lead the preparation and validation work. In this path, the migration expectation should remain close to supported commerce records and supported mapping behavior.
A Standard Migration candidate usually has a manageable product catalog, understandable categories, limited custom fields, no critical unsupported plugin data, clear customer and order expectations, and a target store that does not rely on unresolved sales-channel or rule complexity. The merchant should also be able to review Demo Migration results and final migration results with internal stakeholders.
| Standard Migration signal | What should still be verified |
|---|---|
| Products, customers, orders, categories, coupons, reviews, and CMS content are mostly ordinary. | Representative samples should prove that core fields, relationships, and content are usable. |
| Sales-channel model is simple or already configured. | Products and categories should appear in the intended storefront context. |
| Variants and properties are understandable. | Buying choices and filters should remain clear after migration. |
| Custom fields are limited or non-critical. | Important values should still be checked for supported mapping. |
| Extension dependencies are not part of expected migration scope. | The merchant should confirm that excluded behavior is acceptable. |
Standard Migration fits when the customer can execute supported actions and verify the defined data outcome. Keep preparation, channel setup and acceptance ownership clear. Limited standard Demo samples can expose gaps; enhanced or custom output requires agreed paid proof and live storefront behavior needs separately owned checks.
When Managed Migration Is the Safer Choice
Managed Migration fits supported Shopware scope when experts should perform the agreed Migration Actions. Many sales-channel or translated-value samples can increase execution work without expanding capability. Customer stakeholders still define catalog, content, history and integration meaning and approve the final result.
Agree expert-executed actions and timing against a defined data outcome. The customer retains manual access and final verification. Business interpretation, validation services, project management, extension setup and launch coordination do not follow automatically from Managed Migration; include any additional tasks expressly.
| Managed Migration signal | Why guidance helps |
|---|---|
| Several teams must review different outcomes. | Experts execute agreed actions; customer owners coordinate acceptance of catalog, SEO, content, Orders and integrations. |
| Sales-channel, language, or content context is important. | The review process needs more than record-count comparison. |
| Demo Migration will drive major scope decisions. | The customer supplies business meaning for findings; additional analysis requires explicit scope. |
| The merchant has limited migration experience. | Expert execution reduces hands-on action workload; the customer still verifies completeness. |
| Launch timing is sensitive. | Agree action timing and customer acceptance owners; broader launch work needs explicit scope. |
Supported scope must be defined before selecting expert execution. Managed Migration does not resolve undefined channel or extension meaning by itself. Unsupported extraction, bespoke relationships or migration logic needs Custom Migration review, and implementation work remains separately owned.
When Add-ons Help
Add-ons help when the requested adjustment stays within supported migration behavior. In a Shopware migration, they may apply record filtering with field-based conditions for each data type, expression-based field-value transformation, or source-field remapping without turning the project into bespoke custom work.
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.
Identify the exact supported operation before assigning custom scope. A compatible field or eligible database-level destination may fit a Standard Add-on. Unsupported extraction, bespoke interpretation or relationships beyond those controls needs Custom Migration review; an extension or table name alone does not decide eligibility.
| Add-ons candidate | Why it may fit Add-ons | When it becomes Custom Migration instead |
|---|---|---|
| Data Filter | Supported records must satisfy defined record-field conditions to migrate. | The filter depends on unsupported custom logic or inaccessible plugin data. |
| Data Transformation | Supported field values must be transformed through defined expressions. | The transformation depends on unsupported modules, external systems, or bespoke logic. |
| Advanced Data Mapping | Supported source fields need compatible Shopware target fields. | The destination requires unsupported target behavior or structure. |
Shopware supports Advanced Database Mapping as Target. The exact Source setup must also support it, then the eligible data type, table, field, column, semantic meaning and Value Type must qualify and be compatible. Visible extension tables or typed custom fields are not automatically eligible. Database storage does not establish channel visibility or recreate extension behavior.
Add-ons are valuable when they improve precision. They should not be used to hide custom complexity inside a standard migration path.
When Custom Migration Is Required
Custom Migration is the right path when the migration requires work beyond supported standard behavior. Shopware’s extensibility makes this especially important. A source store may contain plugin-owned records, custom fields whose required handling exceeds supported mapping scope, custom storefront behavior, old module data, ERP/PIM/CRM identifiers, marketplace references, bespoke pricing rules, or content-commerce structures that do not map cleanly through ordinary migration scope.
Custom Migration should be considered when the merchant can explain why the unsupported data matters and how it should behave in Shopware. The goal is not to migrate everything simply because it exists. The goal is to preserve business-critical meaning that ordinary migration scope cannot handle.
| Custom Migration trigger | What must be clarified |
|---|---|
| Unsupported app, plugin, module, or extension data | Where the data lives, what business process uses it, and what target outcome is expected. |
| Custom fields that drive operations or integrations and exceed supported mapping scope | After supported field and eligible database-level mapping are tested, clarify whether the values belong in Shopware custom fields, external systems, or another target structure. |
| Bespoke transformation logic | What source meaning should become in Shopware and why ordinary mapping is insufficient. |
| External-system identifiers | Which IDs must remain usable for ERP, PIM, CRM, search, marketplace, fulfillment, or reporting workflows. |
| Custom Platform handling | Whether the source or target environment requires tailored extraction, transformation, or connection logic. |
Custom Migration should be scoped with evidence. Sample records, screenshots, export examples, database notes where available, and expected target behavior help determine whether the custom requirement is feasible and valuable.
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 Shopware scope.
Use Demo Migration to Confirm the Approach
Demo Migration can examine a limited representative sample available in the active supported path and reveal gaps in the proposed Shopware 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.
| Demo Migration finding | Approach implication |
|---|---|
| Core records migrate cleanly and samples are usable. | Standard Migration may remain appropriate. |
| Available standard records expose customer review or execution workload. | Managed Migration can supply agreed expert execution; broader review coordination needs explicit scope. |
| Supported records need record filtering, field-value transformation, or field-remapping adjustment. | Eligible Add-ons may fit; their output needs agreed paid proof. |
| Important data is missing because it is unsupported or custom-owned. | Custom Migration review is needed before full scope is accepted. |
| Target configuration is incomplete. | The issue may be target readiness, not migration failure. |
Use the limited standard result to identify supported gaps, paid enhancement/custom proof needs and target setup issues. Keep channel visibility, live pricing, extensions and public storefront behavior under their acceptance owners. A clean standard Demo does not establish complete Shopware launch readiness.
Entity Points and Shopware Scope Control
Entity Points size counted capacity for eligible Products, Customers, Orders and Blog Posts on their first successful migration, once within the same purchased migration and fixed Source-to-Target path. Channel relationships, variant/property meaning, translations and extensions still affect scope without becoming additional independently counted Data Types.
A new migration action does not automatically mean the same previously counted records consume additional Entity Points again. The important distinction is whether the action migrates newly eligible records for the first time or repeats records already counted within the same purchased migration.
| Scope situation | Entity Points implication |
|---|---|
| Existing counted products are migrated again through a later action. | They should not be treated as newly consuming Entity Points simply because the action repeats them. |
| New products, customers, orders, or Blog Posts are added after the earlier migration. | New eligible counted records consume Entity Points on first successful migration within the purchased path. |
| Custom fields or plugin-owned data need special handling. | Test supported mapping for the custom fields first; when plugin ownership or required handling exceeds Standard Add-on scope, service scope and Custom Migration review may matter more than Entity Points. |
| A distinct migration result has an explicitly agreed target effect. | A distinct result does not recount eligible records already counted within the same purchased migration and fixed path; protected target data is not automatically erased. |
| The merchant changes configuration before continuing. | Service path and validation scope should be reviewed, not only point consumption. |
Use Entity Points only where they help the merchant plan counted capacity. They should not replace service-path reasoning.
Migration Actions for Shopware
After a paid migration has produced an earlier result, Shopware launch planning may require further activity as the Source Store receives Products, Customers, Orders, Blog Posts, translations, media, or commercial updates. The selected action depends on whether the recorded configuration remains valid, supported rules need revision, or the target result needs a fresh basis. Demo findings should inform the first paid configuration rather than be treated as a paid result to continue.
| Migration Action | When it fits Shopware | What must be revalidated |
|---|---|---|
| Continue the Migration with Last Saved Configuration | An earlier paid configuration remains valid, including accepted channel and field handling; select the source-data window separately. | New Products and variants, properties, media, Customers, Orders, translations, content, and a regression sample across affected sales channels. |
| Continue the Migration with a New Configuration | Review of the earlier paid result or revised target requirements shows that filters, mapping, custom-field placement, translation handling, content scope, or supported data configuration must change. | Every affected Product family, variant relationship, property group, sales-channel assignment, custom field, translated value, Order sample, and content structure influenced by the change. |
| Perform a New Migration | Use for the first paid run or a distinct result on the same purchased path; define target effects without assuming a reset or protected-data erasure. | The accepted data scope, protected target data, channel-context values, Product relationships, Customers, Orders, media, content, URLs and agreed extension-sensitive outputs. |
Check selected records and regression samples under a saved configuration, or prove a changed rule against the combined earlier and later output. A distinct result requires acceptance of its defined target effect. Rules, payment, shipping, tax, Shopping Experiences, themes, extension configuration and integrations retain separate implementation owners unless expressly included.
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.
Shopware Service-Path Decision Gates
A Shopware service decision should pass four platform-specific gates before Full Migration. The catalog gate should prove that parent-child Product relationships, variants, properties, media, translations, and sales-channel visibility have a supported target meaning. The commercial gate should distinguish migrated records from Shopware Rules, pricing, tax, payment, shipping, and promotion configuration. The ecosystem gate should identify custom fields, extensions, Shopping Experiences, APIs, and external-system identifiers that sit outside ordinary record migration. The governance gate should confirm who owns target configuration, regression testing, and launch approval.
| Decision gate | Evidence for a supported path | Escalation signal |
|---|---|---|
| Catalog and sales channels | Representative Products and channel assignments remain usable. | Important relationships require unsupported transformation or custom extraction. |
| Commercial behavior | Historical data is readable and live rules are separately configured. | Source logic must be reconstructed from custom rules, plugins, or external systems. |
| Content and extensions | CMS content and supported fields have defined destinations. | Shopping Experiences, extension tables, or custom fields carry business-critical data with no standard destination. |
| Validation and ownership | The merchant can approve samples across affected channels. | Acceptance needs customer business decisions or separately agreed analysis; Expert Handle executes agreed actions. |
Use the catalog, commercial, ecosystem and governance gates to define supported scope and target responsibilities. Managed Migration supplies expert execution of agreed supported actions. Tailored extraction or representation needs Custom Migration review, with Self-Execute or Expert Handle. Additional coordination or validation services must be explicitly agreed.
Choosing the Right Path
The right Shopware migration approach is the one that matches the merchant’s data evidence, target readiness, internal review capacity, and unsupported-scope risk. The decision should be made after reviewing the catalog, sales channels, content, commercial logic, custom fields, extensions, integrations, and Demo Migration results.
| If the migration has... | Prefer... | Watch for... |
|---|---|---|
| Ordinary supported records and clear target setup | Standard Migration | Underestimating validation responsibility. |
| Supported scope but high coordination burden | Managed Migration for agreed expert actions | Broader coordination requires explicit scope and clear customer acceptance. |
| Specific supported record filtering, field-value transformation, or field remapping needs | Add-ons | Treating unsupported custom data as an Add-on. |
| Plugin-owned, custom, or external-system data | Custom Migration | Migrating obsolete data without business value. |
| Unclear complexity | Limited standard Demo, with paid or target-side proof where required | Drawing conclusions from too few samples. |
A strong service decision should make the project easier to validate. If the chosen path leaves the team unsure what should happen to important products, rules, content, custom fields, or integrations, the approach is not ready.
Conclusion
Choose the Shopware scope from channel visibility, variant/property meaning, translated values and extension ownership, then choose execution. Standard Migration is customer-led; Managed Migration supplies expert execution of agreed supported actions. Eligible Add-ons refine supported output, while Custom Migration handles tailored requirements with Self-Execute or Expert Handle.
Shopware rewards clarity. When catalog samples, sales-channel decisions, commercial rules, content priorities, custom fields, integrations, Demo Migration findings, Entity Points implications, and later migration actions are understood before launch, the migration approach becomes easier to choose and easier to defend.
Common Questions
When is Standard Migration enough for Shopware?
Standard Migration may be enough when supported records are ordinary, the target setup is clear, custom fields are limited, extension data is not part of expected scope, and the merchant can handle preparation and validation.
When should a Shopware migration use Managed Migration?
Use Managed Migration when experts should execute the agreed Migration Actions within supported Shopware capability. The customer retains manual access, defines channel and record meaning and verifies the result. Broader coordination, validation services, extension setup or launch work requires explicit scope.
What is the difference between Add-ons and Custom Migration for Shopware?
Standard Add-ons provide supported filtering, expression-based transformation and compatible mapping in their fixed sequence. Advanced Database Mapping requires exact Source support and Shopware Target support, then eligible compatible schema; Tax is excluded from both mapping Add-ons. Tailored requirements outside those controls use Custom Migration with Self-Execute or Expert Handle.
Why should Demo Migration influence the service path?
Limited standard Demo samples can expose supported data gaps and help identify an enhancement, tailored requirement or setup issue. Add-ons and Customization are unavailable, and Reviews and Coupons are excluded. Enhanced or custom output needs paid proof; channel visibility, Rules, extensions and live storefront behavior need target-side acceptance.
Do Shopware Rules, sales-channel settings, and extensions become operational through data migration?
No. Migrated records can preserve supported data, but Rules, sales-channel configuration, payment, shipping, tax, storefront behavior, and extension implementation must be configured and validated separately unless they are expressly included in an agreed custom scope.
Does a migrated Product’s presence prove that it is visible in the right Shopware channel?
No. In Shopware 6, channel assignment, active status and extended visibility have distinct meanings. Confirm the actual target generation and configuration, define which values the migration must preserve and separately verify storefront discovery and purchase behavior. A row in the database alone does not establish that outcome.