OXID 6 End-of-Life: What the Calendar Means for Your Frontend

OXID 6 is no longer a current product, it's a winding-down version. In the official OXID eSales release plan, the 6 series has sat on "legacy" status continuously since 2024 and receives only selected important fixes, not full maintenance updates. So the strategic question isn't "whether," it's "when" and "in what order" you react. Our answer: decouple the frontend first, do the backend upgrade separately afterward, no big-bang replatforming.

What exactly does OXID 6 end-of-life mean?

OXID doesn't work with fixed calendar EOL dates per version. It runs a rolling support model: there's always one maintenance version (gets most fixes) and two legacy versions (get only selected important fixes, typically security and compliance related). Everything older counts as outdated and no longer receives all patches.

OXID 6.5 is the last minor version of the 6 series, there is no 6.6. In the release plan, 6.5 sits on legacy status across every quarter from Q2/2024 through "TBA." The active maintenance line is now the 7 series (7.5 as maintenance in Q2/2026, 7.4 as legacy). In practice: if you're on OXID 6, you're running a version that gets emergency care only and slides further out of the support window with every new 7 release.

Note on the dates: OXID communicates status (maintenance / legacy / outdated) and quarterly windows, not hard day-level EOL dates per 6.x version. The table below reflects that status calendar. Verify the current state in the official OXID release plan before you build budget decisions on it.

The OXID 6.x lifecycle calendar (status, not fixed dates)

The calendar is clear: OXID 6 is not "dead tomorrow," but it's a dead end for anything that needs frontend innovation. Performance, accessibility (the German BFSG accessibility law has been mandatory since June 28, 2025), mobile conversion, and fast campaign iteration all come from a core that only gets emergency care.

The problem most OXID stores have right now

With OXID 6 operators we almost always see the same pattern: the frontend hasn't been touched in years "because the 6-to-7 upgrade is still ahead of us." The upgrade is invasive, many adaptations have to be rebuilt, and it typically costs 3-9 months of implementation effort. So the team waits, and while it waits, the frontend keeps aging.

That breeds the false either/or question: migrate to OXID 7 the hard way, or replatform straight to commercetools / Shopware 6 / Adobe Commerce. Both options are painful. The upgrade ties up months. The replatforming throws away years of OXID investment and typically runs six figures into the millions. In both cases, the frontend, the place where the customer actually buys, gets nothing for months.

We described this same pattern for Magento operators when the Magento 2.4.6 EOL question turned into a patch treadmill. Vendor EOL almost always triggers the same reflex, and the reflex is almost always more expensive than it needs to be.

How Laioutr solves it: decouple the frontend, keep the backend stable

You don't have to carry the backend upgrade and the frontend modernization at the same time. With the Laioutr Frontend Management Platform (FMP), you put a Composable Headless Frontend on top of your existing OXID 6 backend, connected via the OXID API. From that moment, frontend and backend are decoupled:

• You modernize the frontend now: Composable storefront on Nuxt, Core Web Vitals out of the box, accessibility-ready components by default, campaign pages from Studio in hours instead of sprints.
• The OXID 6 backend keeps running stable, on the legacy line's security/compliance fix stream, without you having to touch it for the frontend work.
• You do the OXID 7 upgrade later, separately. Because the data binding is normalized through a GraphQL layer (Orchestr), the frontend stays unchanged when you switch backends. You swap the connection, not the storefront.

That's the core of our decoupling promise: every backend, one frontend, no lock-in. The order is frontend-first, not big-bang. We covered what this looks like technically in OXID 6 to 7 upgrade: decouple the frontend without replatforming.

What you gain

FAQ

Do I have to upgrade immediately because of OXID 6 end-of-life? No, not immediately. OXID 6.5 is legacy, not switched off, and still gets selected security/compliance fixes. The pressure is real, but you get to choose the order: decouple and modernize the frontend now, run the backend upgrade as a separate, plannable project afterward.

What does it cost compared to replatforming? A frontend decoupling with the FMP sits well below typical replatforming costs (six figures into the millions). You'll find the exact plan mapping on our pricing page.

How long does connecting the frontend to OXID 6 take? Migrations with founder support take a median of under 14 days for us. It depends on your data complexity, but it's weeks, not months.

Can we still move to OXID 7 or another platform later? Yes, that's exactly the point. The frontend is connected in a backend-agnostic way. If you later move to OXID 7 or another backend, the storefront stays, you only swap the connection.

Next steps

If you're on OXID 6 and keep pushing the 6-to-7 upgrade ahead of you: let's spend 20 minutes on the decoupling path you can run without touching your OXID setup. Backend details are on Headless Frontend for OXID.

More from the Laioutr platform

• Composable Headless Frontend - the decoupled frontend layer on top of any commerce backend
• Composable Visual Page Builder - Studio: campaign pages in hours instead of sprints
• Composable Digital Experience Platform - the DXP architecture without designer lock-in
• Agentic Frontend Management Platform - Larry AI and the Frontend Agents on the decoupled layer
• Headless Frontend for OXID - the OXID-specific connection path

About the author: Marcel Thiesies is Co-Founder of Laioutr. He guides DACH merchants through the step from a monolithic shop to a decoupled composable frontend, with a focus on decoupling over replatforming.