Who Marc O'Polo Are
Marc O'Polo SE is a premium European modern casual fashion brand, founded in Stockholm in 1967 and headquartered in Stephanskirchen near Rosenheim, Germany. The brand operates across 40 countries — over 2,200 retail and franchise stores, including 111 flagship locations — generating annual brand sales exceeding half a billion euros.
Their portfolio spans ten product lines released across eight seasonal collections and ten delivery windows per year. Their loyalty programme has over one million active members. Operationally, they run 37 localised storefronts across 6 languages, each with its own editorial content, pricing, and promotional calendar managed by a mix of developers and non-technical marketing staff.
What made their digital challenge real was not scale alone — it was velocity. Fashion brands launch, adjust, and retire content continuously. Any system that makes that process slower for the people who need to execute it becomes a commercial liability, and that is exactly what had happened with their in-house CMS.
The Problem
When we came into the project, Marc O'Polo was five months into a relaunch with an in-house CMS they had built themselves. The system had been purpose-built to give them more content control than a traditional monolithic suite would allow. Instead, it created new constraints — and harder ones.
Johannes De Zordo, Senior Frontend Developer at Marc O'Polo, described the situation directly: "We were really struggling to work with content. The CMS was part of a bigger monolithic system, and you could see that it was not their key feature. When we built something, we always had to struggle with a workaround."
The documented pain points were specific.
Restrictive editing. The system provided no consistent editing experience across developer and marketing workflows. Developers and business users were working in different mental models with no shared interface, creating constant back-and-forth that slowed every content request.
Heavy upkeep. The in-house CMS required significant developer maintenance to run. Even a change as minor as updating a product title required developer involvement. At the pace that fashion content moves, that does not scale.
No local development. Every code change — including UI component work during the frontend revamp — had to be pushed to a remote environment before it could be tested. For a team simultaneously rebuilding the storefront's design, this eliminated most of the feedback loop that makes frontend development workable.
Steep learning curve for non-technical users. Content editors could not operate the system without assistance. Creating new content modules always required a developer. The marketing team had no meaningful autonomy.
Maria Künzner, Technical Project Manager at Marc O'Polo, summarised it: "In the past, it was hard for project managers and developers when a new content request came in. We knew we couldn't build it the way we wanted to — something smart and sustainable."
The commercial context made the problem urgent. According to McKinsey's The State of Fashion 2026 report (January 2026), 71% of fashion brand executives rated their digital channels as significantly underperforming relative to growth ambitions — with editorial velocity and platform inflexibility cited ahead of inventory or marketing spend as the primary bottlenecks. Marc O'Polo's setup was a precise example of that pattern.
What We Built
We built a fully decoupled content and commerce platform: Storyblok as the headless CMS, Commercetools as the commerce engine, Nuxt.js with Vue.js as the storefront layer, and AWS for hosting — all connected through a best-of-breed integration approach. Each layer can be upgraded or replaced without rebuilding the others.
Alongside the CMS migration, we ran a complete UI/UX revamp of the Marc O'Polo digital storefront. The two workstreams were interdependent: the new Storyblok component architecture had to align with the new visual design system, which meant design and CMS content modelling had to be worked out together rather than sequentially.
The core outcome: marketing teams can now publish content, launch campaigns, configure promotions, and manage redirects across 37 storefronts without raising a development ticket. Storyblok's Visual Editor gives them a real-time preview of exactly what any change looks like before it goes live — no staging review cycle required, no developer standing by.
According to Gartner's 2025 Hype Cycle for Digital Commerce (August 2025), composable commerce — the pattern that Storyblok and Commercetools together embody — moved into the Slope of Enlightenment, marking the shift from architectural trend to proven enterprise practice. The Marc O'Polo implementation is representative of that maturity: no single vendor owns the full stack.
How We Built It
CMS — Storyblok Components and Localisation
The Storyblok implementation uses a component-based content model. Every module — hero sections, campaign banners, editorial grids, product spotlights — is a reusable Storyblok component that content editors compose freely within the Visual Editor. A campaign page for the German market and the same campaign for the French market share the same component library; only the content fields differ.
Localisation handles the 37 storefront variants across 6 languages using field-level translations with a fallback to the base language where a translation has not been created. This avoids content tree duplication — editors work on one canonical story, not 37 separate duplicates.
Storyblok's workflow and publishing pipeline was configured to match Marc O'Polo's internal approval process. Content moves through a draft → review → approved → published cycle without developer involvement at any step.
Frontend — Nuxt.js Storefront and the UI Revamp
The storefront is built on Nuxt.js with Vue.js — which aligned with Marc O'Polo's existing frontend stack. Migrating to Storyblok did not require a framework change; the Storyblok SDK integrates natively with Vue, and the existing Nuxt routing structure carried over. This compatibility was one of the factors that made a 14-day implementation window achievable.
The UI revamp ran in parallel. The component redesign work — updating the visual design language, improving mobile UX, refining navigation and product page layout — was developed in the same Nuxt component architecture that Storyblok would render. Every component rebuilt for the new design was made Storyblok-aware from the start.
Commerce Engine — Commercetools
Commercetools handles the full commercial layer: product catalogue, cart, checkout, pricing, and loyalty programme integration. The best-of-breed approach means Marc O'Polo's developers can integrate any new technology — including their POS system — directly with Commercetools without touching the CMS layer. A change in the commerce engine does not require a CMS update, and vice versa.
Infrastructure
AWS handles hosting. Storyblok's Webhooks trigger cache invalidation on content publish, so updates go live globally without a rebuild cycle. The decoupled architecture makes each layer independently deployable.
What Made It Hard
Convincing Stakeholders to Abandon a System Mid-Project
The most significant challenge was not technical — it was organisational. Proposing to stop work on an in-house CMS five months into a relaunch, and switch to an entirely different system, required a case the team could demonstrate rather than argue.
We built a working prototype in 48 hours using Storyblok's free trial. The same scope — a homepage with full content modelling and real-time Visual Editor preview — had taken approximately four months of effort with the legacy system. Presenting that comparison to internal stakeholders: developers, marketers, project managers. When the argument can be shown instead of debated, the conversation is different. That prototype was what secured the green light.
Running Two Workstreams Without Either Blocking the Other
Migrating a live CMS and redesigning the frontend UI at the same time creates a dependency problem: new visual components need to be mapped to Storyblok content types, but content types can only be finalised once design direction is confirmed. Run them sequentially and the timeline doubles. Run them in parallel without alignment and the components do not match the schema.
The solution was to treat Storyblok's component structure as the shared boundary between design and development. Design defined what a component looks like; we defined what data fields it requires. Every UI component approved in design went directly into the Storyblok schema before frontend implementation started. This gave both workstreams a single source of truth to build toward simultaneously.
Content Migration Across 37 Live Storefronts
Moving live content from the in-house CMS to Storyblok across 37 storefronts and 6 languages — without disrupting ongoing marketing operations — required a structured migration plan. Storyblok's Management API allowed us to create content programmatically: we wrote migration scripts that mapped the old content structure to the new Storyblok component schema, ran per-story validation checks, and loaded content in batches per storefront. The full migration ran within the 14-day implementation window.
Achieving Zero Onboarding Time for Content Editors
One stated success criterion from the Marc O'Polo team was that content editors should be able to start working in the new system immediately, without formal training. Storyblok's Visual Editor — where editors see the live page as they make changes — was central to this. But the component schema also had to be designed so that each field's purpose was obvious without documentation. Every field label, help text, and component name was reviewed for clarity from an editor's perspective before launch. The zero-onboarding target was met at go-live.
What Changed
The results Marc O'Polo reported after the migration were direct:
1. First prototype: built in 48 hours — versus approximately 4 months for the same scope with the legacy system 2. Full implementation: completed in 14 days across 37 storefronts and 6 languages 3. Onboarding time: zero — content editors started working immediately without formal training 4. Developer dependency: removed from content publishing and campaign management entirely
Johannes De Zordo: "Storyblok is a great fit for our needs. Developers appreciate the API-based system and how simple it is to use. Business users also love the interface with real-time preview with the Visual Editor."
Maria Künzner: "Storyblok is more than just a CMS for us. We've finished projects on time and within budget. I would recommend Storyblok not only to development teams — project managers and business users can benefit with Storyblok as an easily maintainable CMS."
What's Next
The platform's modular architecture positions Marc O'Polo well for the next phase of their digital operations. Several initiatives are in scoping or active development:
- AI-powered product recommendations — personalised outfit suggestions using collaborative filtering on purchase history, integrated at the commerce layer
- Visual search — photo-to-product matching using image embedding models
- LLM-assisted localisation — automated first-pass translation of product content for new market entries, reducing the editorial overhead of regional expansion
- Virtual try-on — AR-based fit visualisation for apparel on mobile
- Inventory intelligence — cross-market stock balancing and predictive restocking using Commercetools data
Headless CMS Migration for E-Commerce — Common Questions
What are the main reasons fashion brands migrate from a monolithic CMS to headless? The immediate trigger is usually editorial velocity — a content team that can't make changes without developer involvement, or a system with maintenance overhead that grows faster than the team. The deeper reason is that a monolithic CMS couples content management to the presentation layer, which makes both harder to change. A headless CMS exposes content via API, so the frontend can be rebuilt or redesigned without touching the content infrastructure, and vice versa. For a fashion brand launching 8 seasonal collections and 10 delivery windows per year, that independence is not optional.
How long does a headless CMS migration take for an enterprise e-commerce brand? Timeline depends on content volume, existing data model complexity, and whether the frontend is being rebuilt simultaneously. The Marc O'Polo migration — 37 storefronts, 6 languages — was completed in 14 days. This was achievable because the existing tech stack (Vue.js + Nuxt.js) was natively compatible with Storyblok's SDK, content migration was scripted programmatically via the Management API, and the component schema was finalised before migration started. Migrations without those conditions take significantly longer.
Why Storyblok over other headless CMS options for a multi-market fashion brand? For teams where non-technical editors need genuine autonomy, Storyblok's Visual Editor is the differentiating capability — real-time WYSIWYG preview without a separate preview environment. For multi-market deployments, Storyblok's built-in localisation handles per-locale field overrides with language fallbacks, which avoids the content tree duplication problem that compounds at scale. For developers, the API-first architecture integrates cleanly with Commercetools and any other best-of-breed commerce tool without custom middleware.
How do you run a frontend UI revamp and a CMS migration at the same time without each blocking the other? Treat the CMS component schema as the shared contract between design and development. Design defines what a component looks like; engineering defines what data fields it requires. Every UI component approved in design gets a corresponding Storyblok content type before frontend implementation begins. This way both workstreams are building toward the same boundary simultaneously — design is not waiting on engineering, and engineering is not waiting on a final design handoff.
Migrating a live CMS mid-project — while simultaneously redesigning the storefront — is not the low-risk approach. The case for doing it at Marc O'Polo was specific: the in-house system was accumulating operational debt for developers and marketing teams alike, and the 48-hour prototype made the cost of staying visible in a way that arguments alone could not. The technical migration was, in the end, the straightforward part. The harder work was sequencing two parallel workstreams so neither blocked the other and both landed in 14 days.
If you are evaluating a headless CMS migration or a frontend revamp for a multi-market e-commerce brand, explore our case studies to see how we have approached similar complexity, or book a discovery call to talk through your specific platform and team setup.