The OXID 6 to 7 migration is not just a technical upgrade. It is a strategic fork with three options, one right answer per context, and a question many forget to ask first.

This post gives you the decision framework: three options on the table (upgrade, replatform, frontend renovation), an IDC data layer that makes TCO honest, and a decision logic that tells you which option fits your context.

Where OXID customers really stand in 2026

OXID has rolled out the major upgrade from version 6 to version 7. Across the customer base we see three recurring observations:

1. The upgrade is invasive. Many customizations have to be redone, and the implementation effort typically lands at 3-9 months.
2. The frontend has been untouched in many shops for years because the next backend project was always around the corner. Result: weak Core Web Vitals, weak mobile conversion, frontend iteration measured in weeks instead of days.
3. The question turns strategic: "If we put in this much effort anyway, shouldn't we just move to a more modern platform?" Replatforming options like commercetools, Shopware 6, or Adobe Commerce are openly on the table.

That is the picture. Three options, three very different bills, one decision that has to hold for the next 5-7 years.

Three options on the table

The table is deliberately sober. There is no winning column entry per row that holds for every customer. What the table does make visible: option 3 is the only one you can run in parallel to any other option without blocking it.

The IDC data layer many miss

If you are discussing replatforming toward a composable commerce stack (commercetools, Spryker, VTEX), there is one data point missing from most vendor pitches: according to IDC, the TCO of a composable commerce setup over a 3-year horizon runs at 2.2 to 3.1 times that of a headless setup (source: IDC 2024 Worldwide Digital Commerce Spending Guide, cited in the BigCommerce 2026 update).

What does that mean concretely for mid-market OXID customers? The composable story is typically sold as "better, more modern, future-proof". The TCO truth is: you pay a separate license for each MACH component (headless commerce, CMS, search, personalization, checkout), integrate them via custom glue code, host them yourself, and run them with a team that has to know every component. Over three years this stacks up to a bill that never shows up in the pitch deck.

This is not an argument against composable commerce. It is an argument for not making the composable decision out of OXID 6 to 7 upgrade pressure, but out of an honest business calculation. Take the pressure out of the frontend question, and you have a clear head for the backend question. More in our TCO deep dive on budget as a composable barrier.

What does frontend renovation mean in practice?

Frontend renovation means: you modernize the frontend now, while your OXID 6 backend keeps running stably. The OXID 7 upgrade comes later, separately, with no frontend risk.

Technically this works because Laioutr FMP connects to OXID via API. Frontend and backend are decoupled. Storefront iteration runs independently from the OXID core. When OXID 7 comes later, the frontend stays unchanged and the backend is migrated in isolation. That is USP 1 of our platform: any backend, one frontend, no lock-in.

The second effect is time-to-market. Where classic OXID theme work runs at 4-12 weeks per frontend change, we see iterations of 1-3 days in FMP setups. That is USP 2: marketing teams build landing pages themselves in Studio with live preview, engineering reviews and extends. Banner tickets disappear from the backlog.

The full decoupling walkthrough for OXID setups is documented here: OXID 6 to 7 upgrade, decouple the frontend without replatforming.

When does each option pay off

There is no universal answer. There are three if-then statements per option that hold up in practice.

Option 1 (upgrade) pays off when:

• Your backend customization is shallow and the 7 upgrade is realistic in 3-4 months.
• Your growth ambition is stable, no multi-storefront or multi-market pressure.
• Frontend performance is not an acute conversion problem.

Option 2 (replatforming) pays off when:

• OXID no longer fits strategically (e.g. moving to a B2B-only backend with OMS requirements OXID does not cover).
• You are ready to invest 12-24 months greenfield and pause frontend innovation in the meantime.
• The replatforming target is clearly defined and not driven by "away from OXID" alone.

Option 3 (frontend renovation) pays off when:

• Your frontend is the bottleneck (performance, mobile conversion, time-to-market), not the backend.
• You do not want to avoid the OXID 7 upgrade, but you want to spread it out in time.
• You need multi-storefront, multi-market, or multi-brand, without breaking apart the backend.
• You want to keep the replatforming option open for later, without forcing it today.

The last bullet is the underrated lever. Frontend renovation is the only option that preserves optionality.

What you gain

According to a typical DACH mid-market customer in our base, exactly this pattern (frontend now, backend later) put the team in a position to ship Black Friday landing pages in days instead of sprints, while the backend roadmap kept running undisturbed. The customer name is kept neutral here on purpose: the press clause in the reference MSA is not yet cleared for direct attribution.

FAQ

When does replatforming really pay off? When OXID no longer fits the backend requirement strategically (e.g. complex B2B OMS scenarios OXID does not cover), when a concrete target stack is defined, and when the team can absorb 12-24 months of greenfield work organizationally. "Away from OXID" alone is not a replatforming argument.

What does the 6 to 7 migration cost without the frontend share? Pure backend migration typically runs at 3-9 months of implementation effort. The frontend share often pushes that range to 6-12 months. If you decouple the frontend via renovation upfront, the 6 to 7 migration shrinks to a pure backend topic and becomes more predictable.

How long does frontend renovation take? With founder support we see 6-12 weeks for a standard OXID shop in our customer base, with a median migration time under 14 days for the platform setup itself. The rest is content migration, theme build, and go-live preparation.

Does the OXID investment stay intact? Yes. Frontend renovation does not touch the OXID core. Product data, order management, checkout logic, B2B pricing, ERP integration all stay in the OXID backend. Laioutr connects via API. All OXID customizations and modules stay functional.

When do I still switch later? When your backend requirements change to the point where OXID no longer fits. The benefit: the frontend stays unchanged, and the backend swap becomes an isolated project. You skip the classic replatforming double pain (frontend + backend at once).

Next steps

If you are in the middle of the 6 to 7 decision, or replatforming is being discussed internally: does this pattern match your situation? Let us walk through your setup in 30 minutes. We look at backend depth, frontend age, multi-storefront requirements, and give you a read on which of the three options pays off for your context.

Book a slot

More from the Laioutr Platform

• Headless Frontend for OXID
• Composable Digital Experience Platform
• Multi-Brand, Multi-Market

Related Insights

• OXID 6 to 7 Upgrade: Decouple Frontend Without Replatform
• Headless CMS for Next.js eCommerce in 2026: A Decision Framework That Survives Five Years