OXID 6 to 7 Upgrade: Decouple the Frontend Instead of Replatforming

OXID 6 runs, the back office is dialed in, custom modules work. But the frontend stack is eight years old, Core Web Vitals sit in the red, and the 7-upgrade path means either an 18-month replatforming project or staying on 6.x and hoping security patches keep coming. There is a third option almost no one discusses.

TL;DR

• OXID-6 shops face a 2026 upgrade decision that is, in practice, a replatforming. The 7.x branch bundles a Symfony jump, a theme-layer break, and custom-module migration into one package.

• Option A (full 6 to 7 upgrade) ties up 6 to 12 months of engineering. Option B (stay on 6.x) defers the problem rather than solving it.

• Option C: decouple the frontend. Put a composable frontend on top of the OXID-6 backend, modernize the storefront in 4 to 6 weeks, keep the backend stable, then pull the 7-upgrade later in isolation or skip it altogether.

• For most OXID-6 shops with a working custom-module landscape, Option C is the only rational choice.

The 2026 picture: OXID 7 is here, the pressure is real

OXID has stabilized the 7 branch. Version 7.2 runs in production at the first lighthouse customers, and the vendor is already working on 8.0 with a Symfony 6 jump and a MySQL 8 baseline. For every OXID-6 shop operator that means one thing: the question is no longer if, but when. The longer you wait, the closer the 8 upgrade pulls into the 7 upgrade, and the vendor will eventually push 6.x into end-of-life.

At the same time, 2026 is not 2018. A standard OXID-6 theme delivers Core Web Vitals that sit in the weaker third of the market under Google's Page Experience signal. LCP values between 3 and 5 seconds are the norm, mobile conversion suffers, and the pool of frontend developers with real OXID-theme expertise in the DACH market shrinks every quarter.

The combo of upgrade pressure plus frontend modernization pressure means that many managing directors currently have a replatforming pitch on their desk. commercetools, Shopware 6, Adobe Commerce. All three are valid. All three throw away years of OXID investment.

The three strategic options at a glance

| Option | What it means | 3-Year TCO | Time-to-Value | Risk profile |
|---|---|---|---|---|
| **A: Full 6 to 7 upgrade** | Symfony upgrade, theme-layer rebuild, custom-module migration, full QA round | $275k to $880k implementation plus ongoing maintenance | 9 to 18 months to go-live | High: frontend and backend in flight at the same time, custom-module risk, theme-layer break |
| **B: Stay on 6.x (patch strategy)** | Apply security patches, freeze the theme, leave the frontend alone | $55k to $165k ongoing maintenance plus opportunity cost | Immediate, but stagnant | Mid-high: performance slowly degrades, EOL risk, developer-skill erosion |
| **C: Decouple frontend, keep backend stable** | Composable frontend (Laioutr FMP) as the storefront layer, OXID 6 as the backend, API-first integration | $33k to $99k setup plus $6.5k to $33k per year in FMP licensing | 4 to 6 weeks to go-live for the new frontend | Low: frontend and backend separated, custom modules untouched, upgrade becomes optional |

Option A is the default answer from most OXID solution partners. It is the most expensive, the slowest, and the only one that has to touch the entire custom-module universe again. Option B is a hope strategy. It defers the decision and accepts a slow loss of performance and skill.

Option C is the option that usually goes missing in the conversation. It carries a different architectural idea: separate the two problems that sit on the desk together today. The backend upgrade is a maintenance topic. The frontend is a growth topic. They have different time horizons and different risk profiles. Forcing them together means paying full price for both at the same time.

What decoupling looks like in practice: three phases

Phase 1: Stand up the composable frontend (4 to 6 weeks)

The Laioutr Frontend Management Platform is set up in parallel to the OXID-6 backend. The storefront is rebuilt on the composable stack, with a live editor for marketing content, a component library aligned to brand guidelines, and pre-configured performance patterns. The connection to the OXID backend runs through the OXID REST API plus a connector layer that exposes the custom-module endpoints in a stable way.

What does not happen in this phase: the OXID backend stays untouched. No code changes in custom modules. No theme-layer migration. No back-office training. The back office stays exactly what the operations team has known for years.

Phase 2: Replace the OXID storefront with the Laioutr storefront

Once the composable frontend is signed off, traffic is moved from the OXID storefront to the new storefront. That typically happens through a sub-domain cut or a route-based rollout. Teams that want to reduce risk can ship the frontend brand-by-brand, market-by-market, or page-type-by-page-type. The multi-brand and multi-market pattern is built exactly for that, see the Multi-Brand and Multi-Market product module.

From this point on, the conversion path runs on a modern stack. Core Web Vitals out of the box, mobile-first performance, A/B tests per page type, segment-level personalization. The back-office team does not notice any of this, because order and customer flows still go through the OXID backend.

Phase 3: Pull the 7 upgrade in isolation, or not at all

Once the frontend is decoupled, the 7 upgrade becomes a pure backend project. No theme-layer break, because the theme no longer exists. No frontend regression tests, because the frontend does not come from OXID. The upgrade project shrinks to the backend scope only: Symfony update, custom-module adaptation to the 7 API, data migration.

Many shops that walk this path find, 6 to 12 months later, that the 7 upgrade is not strictly necessary. If the backend runs stable, if performance is solved through the decoupled frontend, and if the custom modules still work, the backend upgrade becomes a normal maintenance topic. It happens when the vendor forces it, not because the managing director has to decide.

When decoupling makes sense, and when it does not

Decoupling is not a universal answer. It pays off when the following conditions hold:

1. The OXID backend works. Order management, pricing, custom modules, logistics integrations. If the backend itself has become the burden, replatforming is the more honest move.

2. The frontend is the bigger pain. Core Web Vitals, mobile conversion, time-to-market for marketing content. If the pain clearly sits at the front, decoupling is the sharpest answer.

3. The custom-module landscape is substantial. Shops with 30, 50, or 100+ custom extensions throw away significant investment when they replatform. Decoupling preserves it.

4. Time-to-value matters. If you need frontend performance this year, decoupling gets you there in weeks. Option A gets you there in quarters. Replatforming gets you there in years.

5. The frontend team can run the composable stack. Or a partner takes over frontend operations. Composable is not magic, it requires different skills than an OXID theme.

If these points do not match, decoupling is not the right path. For acutely broken backends, very small shops with no custom logic, or teams that are happy on the standard OXID theme, the simpler answers fit better.

What we have seen on a comparable Magento stack

The same architectural idea applies to other legacy stacks. To see how the decoupling pattern plays out under Magento 2.4.6 EOL pressure in concrete terms, the sister post on the Magento 2.4.6 EOL patch treadmill and frontend decoupling covers the analogous move. For an OXID-specific deep-dive on the frontend alternative itself, the OXID Frontend Alternative post is the companion read.

FAQ

What happens to our OXID custom modules? They stay untouched. Custom modules continue to run in the OXID backend and are exposed to the composable frontend through the OXID REST API plus a connector layer. Where the standard API is not enough, the connector layer fills in the missing endpoints. Module migration is only needed when a module hangs directly in the theme layer, which is not the case for cleanly built modules.

How long does the decoupling phase take? Phase 1 (standing up the composable frontend plus the connector layer) typically lands at 4 to 6 weeks for a mid-sized shop. Phase 2 (cut-over) depends on the rollout style and can be anywhere between 1 day (big bang) and 8 weeks (page-type by page-type). Phase 3 is optional and has no fixed timeline.

Do we still have to move to OXID 7 later? No, not strictly. With the frontend decoupled and the OXID-6 backend running stable, the 7 upgrade becomes a normal maintenance decision. Many decoupled shops stay on 6.x for several years on patch support and only upgrade when the vendor forces EOL. The upgrade is then a clean backend project with no frontend risk.

What does it cost compared to a full replatforming? A full replatforming to commercetools, Shopware 6, or Adobe Commerce for mid-sized DACH shops typically falls in the $220k to $2.2M implementation range, plus license cost on the new platform. Decoupling with Laioutr FMP starts at $33k to $99k setup plus $6.5k to $33k per year in FMP licensing. The OXID backend investment stays intact.

Who runs the frontend then? Three models are common. An in-house frontend team with composable-stack skills (for shops with a substantial digital crew). A frontend partner agency with Laioutr certification (for shops without a dedicated frontend team). A hybrid setup with Laioutr founder support during the first 12 weeks (typical for shops building the capability in-house). The back office and the OXID backend continue to be supported by the existing OXID partner. That part does not change.

Next steps

If the picture fits, let us talk about the concrete decoupling path for your shop. We walk through the custom-module landscape, look at the Core Web Vitals baseline, and lay out a phased plan that does not require a replatform. Talk to us about the OXID decoupling path on the backend pillar page for OXID. For the broader platform view across all supported backends, the Composable Digital Experience Platform overview is the right entry point.

About the author: Marcel Thiesies is Co-Founder of Laioutr and has been working on the Frontend Management Platform category since 2024. Prior to Laioutr he worked as an advisor and operator on several e-commerce platform migration projects across the DACH market.

Sources:

• OXID eShop Release Plan, docs.oxid-esales.com/en/releases/release-plan.html

• OXID eShop 7 Roll-out, Netensio, netensio.de/en/e-commerce-blog/articles-about-oxid-eshop/oxid-eshop-version-7-is-now-available.html