OXID to Shopware migration: no official tool, but a clear path

And there are good reasons to switch. Since 15 August 2022, the OXID eShop Community Edition is no longer under GPL3; commercial use requires a licence fee. The 6.x versions have reached end of life, and OXID 7 replaces Smarty with Twig — which forces a migration project regardless of destination. Many agencies have scaled back their OXID development since 2022.

This article walks you through the three migration paths, the data mapping that makes OXID shops distinctive, and what the project costs. The general methodology is covered in the Shopware 5 to 6 migration article and the Replatforming Guide.

What this article covers

• Why OXID merchants switch in 2026, and why OXID 7 is not a smaller step

• Three paths without an official profile: SaaS tool, API import, custom migration profile

• The mapping: variants, price groups A/B/C, customer groups, multi-shop

• What gets rebuilt and what it costs

Why OXID merchants switch

OXID eShop was for years the shop system of choice for German mid-market businesses, particularly in B2B. Three developments changed that.

The licence change in 2022. OXID replaced the GPL3 licence of the Community Edition with its own terms; commercial use has required a usage fee since then. For smaller shops that chose OXID specifically because the CE was free, the primary reason to stay disappeared.

End of life for the 6.x line. OXID 6.x is EOL according to the vendor documentation. Anyone still running it is in the same position as a Shopware 5 operator: without patches.

OXID 7 as a fresh start. From 7.0 onwards, Twig is the template engine; from 7.1, Smarty is removed — the current version is 7.5. Themes and modules must be rebuilt for OXID 7. That is a migration project within OXID, and precisely the moment when Shopware deserves a serious look as the alternative. The Guide, section 2.3, describes how to make this decision cleanly.

Three paths without an official profile

Path 1: SaaS migration services. Providers such as Cart2Cart or Next-Cart transfer products, categories, customers, orders, and images from OXID 4.x through 7.x to Shopware 6, priced by data volume. Fast and cost-effective for standard data. Limitations: no mapping of custom fields, no module migration, and sometimes restrictions on ID preservation. Sufficient for a small shop without custom logic; not for a system that has grown over the years.

Path 2: API import. Export from the OXID database, transformation according to your own mapping rules, import via the Shopware Admin API or the sync endpoint. Full control over every field, repeatable for delta runs — but requires development effort. In practice, this is the standard approach for mid-sized and large OXID shops.

Path 3: Custom profile for the Migration Assistant. Shopware built the Assistant so that agencies can write their own source system profiles. The advantage: you use Shopware's migration logic, progress tracking, and re-migration capability. The disadvantage: higher initial investment, which only pays off when the profile is used across multiple projects.

Our recommendation: Path 2 for individual projects, Path 3 only when an agency is planning several OXID migrations.

The mapping specifics that make OXID distinctive

Variants. OXID manages variants as separate articles with a parent reference and a variant label as free text ("Size | Colour"). Shopware needs structured properties with options. The free text must be broken down into discrete values; if the original data was maintained inconsistently, this involves manual work with rules.

Price groups A/B/C. OXID's three price groups per product map to customer groups with advanced prices or to Rule Builder rules in Shopware. If you've also combined volume pricing and customer discounts in OXID, you need a decision framework for where each piece of logic ends up.

Customers and groups. oxuser and oxgroups map cleanly onto customers and customer groups. Passwords are not transferred — plan a password reset flow for go-live.

Orders. Transferable for the history in the customer account. Not generally useful for accounting purposes out of Shopware; the ERP stays the leading system.

SEO URLs. OXID's oxseo table provides the complete URL inventory for the 301 redirect map. That's an advantage over other source systems: the data is already there, you just have to use it.

Multi-shop (Enterprise Edition). Clients and sub-shops become Sales Channels. The assignment of products, prices, and customers per client must be decided before the migration.

What gets rebuilt

Theme. Flow, Wave, or a custom Smarty or Twig theme is not converted. The Shopware frontend is a new build.

Modules. This is where the real effort lies for grown OXID shops. Inventory of all modules, classified into: Store equivalent, core coverage (Rule Builder, Flow Builder, Shopping Experiences), custom development. Custom database extensions in OXID are a warning sign: they mean logic that nobody has documented.

Integrations. ERP, payment, and shipping connections are rebuilt. The integration planning approach in the Guide helps establish the sequence.

Process and costs

The process follows the six phases from the Shopware 5 to 6 migration article. What's distinctive about OXID is phase 3: the trial migration is Path 2's first real test of your mapping rules and should run earlier and more often than with systems that have an official importer.

Costs: budget 20 to 50 percent additional effort compared to a Shopware-internal migration (market estimate), driven mainly by mapping development and module inventory. Four to eight months is realistic for a mid-sized OXID shop; Enterprise multi-shops take longer.

Recommendations

1. Decide first whether OXID 7 or Shopware is the destination — both are a migration project.

2. Choose the migration path based on data complexity: SaaS tool for standard shops, API import for grown systems.

3. Break down variant labels and price groups into rules before the import, not after.

4. Export oxseo early and build the 301 redirect map from it.

5. Plan the password reset as a communication measure for go-live.

Conclusion

The OXID to Shopware migration works without an official tool, but not without a method. API import with custom mapping rules is the reliable path for most OXID shops; SaaS tools cover the standard cases.

For decision-makers, the timing is now, because OXID 7 forces a rebuild regardless. Anyone who has to migrate should decide where to go.

Shopware offers Rule Builder, B2B Components, and a large partner network in the DACH region — exactly what mid-market companies once chose OXID for. The switch takes effort, but it's effort with a clear direction.

If you're facing this decision, we'll work through the module inventory with you and assess the migration path. As a Shopware agency, we've moved mid-market companies from several legacy systems to Shopware 6.

FAQ

Is there an official migration tool from OXID to Shopware 6?

No. The Shopware Migration Assistant provides profiles for Shopware 5 and Magento, not for OXID. For OXID, your options are SaaS services such as Cart2Cart or Next-Cart, import via the Shopware Admin API, or a custom-built profile.

What data can be transferred from OXID to Shopware?

Products, variants, categories, manufacturers, customers, customer groups, orders, images, and SEO URLs. Themes, modules, passwords, and configurations cannot be transferred.

Do I need to pay for the OXID Community Edition since 2022?

For commercial use of code published after 15 August 2022, yes. OXID replaced GPL3 with its own licence terms including a usage fee. Non-commercial use remains free.

Can OXID modules be reused in Shopware?

No. The architectures are fundamentally different. Modules must be replaced with Store extensions, core functions, or custom development.

How long does an OXID to Shopware migration take?

For a mid-sized shop, four to eight months, depending on the number of modules and data quality. Enterprise multi-shops take longer.