Your CMS Runtime Just Expired. What Does That Mean for Your Content Team?

If your website runs on EPiServer or Optimizely CMS, there's a good chance someone in IT has started talking about a platform move. Maybe it's already in the budget. Maybe an agency has been briefed. And your editors probably found out last.

I've been through enough of these projects to know how they go. The migration plan covers data models, integrations, and API contracts. All important. But somewhere between the technical audit and the go-live date, the people who publish content every day get left out of the conversation.

This post is for them. And for the project leads trying to make sure the migration doesn't just succeed technically but actually works for the people using the CMS daily.

Why this is happening now

The short version: the .NET runtime underneath your CMS is losing or has already lost support from Microsoft. Your CMS vendor didn't expire, but the foundation it's built on did.

If you want the specifics, here they are. If you're not technical, the key takeaway is simple: Microsoft has stopped patching the software layer your CMS depends on, and that means security risks accumulate over time.

The technical picture

CMS 11 (classic EPiServer) runs on .NET Framework 4.x. Microsoft still ships Windows security patches for this, so it's not dead. But Optimizely has been steering customers toward newer versions for years. New features and ecosystem investment flow elsewhere.

CMS 12 is where things get urgent. It originally shipped on .NET 5, which reached end of life on May 10, 2022. It was updated to support .NET 6, which reached end of life on November 12, 2024. To stay on a supported runtime, you need the latest CMS 12 patches running on .NET 8, which is supported until November 10, 2026.

Optimizely has also introduced CMS SaaS (sometimes called v13), a cloud-only offering that changes the deployment model entirely.

To be clear, Optimizely hasn't published specific end-of-life dates for CMS 11 or CMS 12 as products. The forcing function is the .NET lifecycle, not the vendor's roadmap. But the practical effect is the same.

What migrations actually feel like for content teams

Every migration pitch deck shows a clean timeline. Discovery, build, launch. Twelve weeks, maybe sixteen. It looks manageable on paper.

What those timelines rarely account for is what happens to editorial workflows.

Your content team has spent years building muscle memory around their CMS. They know where things are, they know the workarounds, they have publishing routines and approval chains that are deeply embedded in how they work.

A migration resets all of that.

I've seen projects where the technical work finished in three months, but the content team was still struggling six months later. Not because the new system was bad, but because nobody planned the transition from their perspective.

The questions that matter most often go unasked: How will editors preview content? Can they schedule publishing the way they're used to? Will they need developer help for things they used to handle themselves?

A successful migration is one where the content team is productive on day one. Everything else is infrastructure.

What to look for in a replacement

If you're actively evaluating alternatives, there's one question worth asking before anything else: Does this CMS respect the editor's workflow, or does it just serve the developer's architecture?

That single question filters out a surprising number of options. Many modern platforms are built API-first, which is great for developers. But "API-first" too often means "editor-last."

I'll dig into this in the next post, where I'll share the five questions we ask every team that comes to us mid-migration.

A word about headless

You'll hear "go headless" a lot during this process. Decoupling content from presentation gives you flexibility a traditional CMS can't match. But for many editors, "headless CMS" translates to "I lost my visual editor and now I'm filling in forms."

That's a design choice, not a technical constraint. Headless doesn't have to mean editorless. More on that in post three of this series.

Where we come in

We built Strife for exactly this moment. A content platform that gives developers the headless architecture they want, without sacrificing the editing experience your content team needs.

Happy to talk through your specific situation. No pitch deck required.

This is post 1 of 3 about CMS migrations for EPiServer and Optimizely users. Next: the five questions to ask before choosing a replacement.