Sitecore to Storyblok migration, scoped to be the last one.

What you are being told, and what is actually true

The vendor narrative is straightforward. Stay on Sitecore, upgrade to 10.4 or move to SitecoreAI, ride out the AI wave inside the platform you already know. Migration partners who do not sell Sitecore offer the inverse. Leave for Storyblok, Contentstack, or Contentful, recover 50 to 70% in total cost of ownership, regain editorial autonomy.

Both arguments are partly true and structurally incomplete. The harder question is the one neither side wants to lead with: most replatforming projects fail, and they fail for the same reason. CloudBees' 2025 enterprise migration data puts the average loss per project at €315,000, with 18% cost overruns and 61% of teams reporting fatigue and delay of six months or more. Ekfrazo, citing post-implementation surveys, reports 60% of enterprises regret their CMS choice within 18 months. The platform changes. The structural problem rarely does.

The structural problem is governance. Specifically: content modelling, stakeholder alignment, and migration architecture treated as deliverables, rather than as the actual product.

The AI conversation is the architecture conversation

What the board paper is actually asking about is the content architecture. Whether it can support AI workflows the organisation has not yet specified.

That sounds abstract. It is not.

Sitecore stores rich content as HTML strings, with embedded references resolved at runtime through the Link Manager and proprietary markup. Components are templates with inheritance. Localisation is item versions in a tree. None of this is wrong. It is, however, structurally hostile to language models.

When an AI agent reads Sitecore content, it reads HTML. It cannot reliably tell a heading from a paragraph from an embedded asset reference. It cannot reason about a "feature card" because there is no feature card. There are placeholders, renderings, and inherited base templates. To an agent, the content is a guess, and errors compound from there.

Storyblok and most modern composable platforms store the same content as structured JSON, with typed fields, explicit references, and components that map directly to UI patterns. When an agent reads that, it reads structure. The same is true for any tool that gets wired up later: a personalisation engine, a semantic search layer, an internal RAG application built on top of the content corpus. Paligo's research on structured authoring puts AI customer service performance at 84% better outcomes for organisations using structured content. MadCap reports a 30% reduction in retrieval time and 25% accuracy improvement.

AI requires structured content. Sitecore stores HTML. That is the entire architecture argument compressed to two sentences. Sitecore did its job. The job changed.

Why most Sitecore migrations are the wrong shape

The default migration shape, the one offered by most agencies and most platforms, is a lift-and-shift. Map every Sitecore template to a Storyblok component. Migrate every page. Rebuild the frontend. Cut over.

The lift-and-shift fails for two reasons. The first is technical. Sitecore's content model is not designed to be mapped one-to-one. Templates with deep inheritance chains, GUID-based references, runtime link resolution, and media profiles all need to be decomposed and rebuilt rather than translated. Storyblok's own December 2025 tutorial on Sitecore migration is explicit on this: one-to-one template migration is named as a failure pattern, not a starting point.

The second reason is editorial. The Sitecore content estate that built up over a decade contains drift. Pages nobody owns, components nobody uses, taxonomy that stopped reflecting the business in 2021. Adobe's migration principles recommend reducing migrated content by 40 to 60% during a replatform. Most organisations migrate everything because nobody has the authority to delete.

The migration that actually works has a different shape. It starts with a content audit that names what gets carried and what gets retired. It builds a structured content model designed for AI consumption, not just for the new CMS. It moves the estate in phases, brand by brand or region by region, while the legacy stack stays live. It rehearses the cutover before it commits. The SNV global rollout is a working example of phased multilingual migration at scale.

Technically, the right migration shape is well understood. Commercially, most agencies have no incentive to scope it that way. Discovery is billed by the hour. Modelling is billed by the hour. Migration is billed by the hour. The longer the project, the better the margin. The structural incentive runs against the client.

The exception is small enough teams that the same people who scoped the work also deliver it, with no handoff incentive and no reason to keep the project open beyond what the scope demanded.

What is in scope: Migration Scoping and Architecture Review

The entry point for a Sitecore replatforming decision is fixed scope and fixed price.

In four to six weeks, three deliverables land:

1. An architecture review of the current Sitecore environment, the integration estate, and the content model. Mapped against the structured-content target the organisation actually needs, not against a generic headless reference.

2. A migration blueprint, phased, with named workstreams, dependency mapping, and a defensible TCO projection across legacy run-cost and target-state run-cost. Sitecore-to-Storyblok migrations published in the market report 50 to 70% TCO reduction (FocusReactive, 2025). Numbers in that range are only credible when the blueprint underneath them is. The Royal HaskoningDHV replatform demonstrates the blueprint shape applied to enterprise-scale rebrand and domain migration.

3. A platform recommendation, with the case for Storyblok, Umbraco, or staying on Sitecore 10.4 made on architecture and TCO grounds rather than partnership preference. The recommendation can be Sitecore. It frequently is not. Compare our full technology coverage to see where each platform fits.

Fixed scope. Fixed deliverables. No optional add-ons, no discovery extension clause. The output is the input to a board decision, not a sales document.

The blueprint stands alone. The replatforming itself, when it follows, is scoped separately. That separation matters procedurally. The recommendation is platform-agnostic until the moment the decision is made.

Why the migration that follows runs differently

The replatforming work that follows the blueprint runs on agent-assisted delivery, using the same Storyblok MCP server the client will use after launch.

In practice, agents do work that used to be manual. Content audit runs against the Sitecore estate rather than against a spreadsheet. Bulk transformation of Sitecore exports into structured Storyblok payloads is scripted, not hand-mapped. Schema diffing happens across migration phases. Rich-text conversion from Sitecore HTML into Storyblok JSON is performed once and re-runs cleanly when the model changes.

Most CMS vendors tell an agentic story about features the customer will use after migration. The story behind this service is about the migration itself: same MCP server, same structured content, same agents, before the cutover and after. Productised delivery is what holds the fixed scope. AI in the delivery chain is what holds productised delivery. The TIAS modular platform shows what the post-migration editorial pace looks like once that infrastructure is in place: page publishing compressed from days to one hour.

Where the decision is being made right now

The Benelux Sitecore installed base includes regulated insurers, retail multi-brands, FMCG, healthcare, and tourism organisations whose Sitecore investment was made between 2014 and 2019. Those investments were correct then. The architecture they sit on now is the architecture that determines whether AI lands inside the organisation or stays outside it.

Most of these organisations are looking at a renewal quote, an end-of-support window, or a board-level AI question right now. Some are quietly evaluating. Some are publicly committed. None has a credible non-Sitecore migration story published in the Benelux yet.

That is the gap this service is built around.

The position

Sitecore extended support has already ended for 9.2 and 9.3. Sitecore 10.4 carries mainstream support until December 2027. Migrating from Sitecore XP to XM Cloud requires the same rebuild as migrating to a different platform. Sitecore renewals get treated as procurement events. What they actually decide is the architecture under every digital workflow for the next decade.

The replatform will happen. The decision is whether it is the last one.

Frequently asked questions

Is Sitecore extended support actually ending?

Sitecore XP 9.2 and 9.3 reached the end of extended support on 31 December 2025. No further security patches will be issued for those versions. Sitecore 10.4 carries mainstream support until December 2027 and extended support until 2030. Organisations on 9.x are running unsupported software now. Organisations on 10.x have a planning window, not a renewal-cycle decision.

How long does a Sitecore to Storyblok migration take?

The scoping and architecture review takes four to six weeks. The migration itself depends on estate size, brand portfolio, and integration complexity. Focused single-site migrations published in the market run 6 to 10 weeks. Full enterprise replatforms with multiple brands or regions typically run 12 to 18 months in phases, with the legacy stack staying live throughout.

Can the migration happen in phases without taking the legacy site offline?

Yes. Phased migration is the recommended shape. The Sitecore environment stays live while content moves to Storyblok by brand, region, or content type. URL routing is handled by proxy or DNS rules, so traffic shifts gradually as each phase verifies. The big-bang cutover is no longer a structural requirement, and avoiding it removes the largest single source of migration risk.

Does Sitecore content move automatically into Storyblok?

No. There is no automated tool that maps Sitecore templates, references, and rich text to Storyblok components. Sitecore stores content as HTML with proprietary markup; Storyblok stores it as structured JSON. The migration requires content modelling, schema mapping, and transformation scripts. The work compresses significantly with agent-assisted tooling and the Storyblok MCP server, but does not automate end-to-end.

What does the migration cost compared to a Sitecore 10.4 upgrade?

A Sitecore XP-to-XM Cloud migration requires a full rebuild: frontend, controllers, content model. The same rebuild applies if moving to Storyblok. The cost differential lies in licensing and ongoing run-cost. Sitecore enterprise licensing typically runs €100,000 or more per year. Sitecore-to-Storyblok migrations published in the market report 50 to 70% TCO reduction over a five-year horizon (FocusReactive, 2025).

Why move to Storyblok specifically rather than Contentstack or Contentful?

The platform recommendation depends on the content estate, integration footprint, and team profile. Storyblok wins where visual editing, multi-brand structure, and developer-marketer collaboration matter most. Contentful wins where API-first developer workflows dominate. Contentstack wins where enterprise governance and large-scale content operations are primary. The architecture review names the trade-off explicitly rather than defaulting to partnership preference.