Crossing the .NET divide

If your website runs on Optimizely CMS 11 — many organisations still know it by its former name, Episerver — you are on a version built on Microsoft’s older .NET Framework. The current version, CMS 12, is built on modern .NET. That single change underneath turns what looks like a routine version increment into a re-platform, and it is the reason a large number of CMS 11 sites have not moved.

Why CMS 11 to 12 is more than a version bump

CMS 12 moved the platform from the .NET Framework to modern, cross-platform .NET. That is the same divide that affects .NET applications generally, and it brings the same consequences. The way the application is configured changed. The way it handles core plumbing such as dependency injection changed. A range of components that were specific to the older approach are simply no longer applicable in CMS 12, and the custom code and plugins built for CMS 11 have to be reworked for the new platform.

Optimizely provides tooling to assist the move, and it is more structured than a from-scratch rebuild. But “assisted” is not “automatic.” The bespoke functionality, the integrations and the third-party add-ons your site depends on each need attention, and some have no direct equivalent and must be replaced. The content carries across; the implementation around it is migrated and, in places, rebuilt.

Why staying on CMS 11 is a growing liability

A CMS 11 site keeps working, so the move keeps being deferred. But CMS 11 sits on the older .NET Framework, which — as covered in the broader .NET picture — is frozen rather than evolving. The platform’s investment, its new capabilities and its ecosystem are all on the modern side of the divide. Staying on CMS 11 means staying on the wrong side of that line, with a widening gap, a shrinking pool of developers comfortable in the old model, and an increasing difficulty integrating with anything current.

For a site that matters to the business, that is a slow-building risk: not a single deadline, but a steady erosion of your ability to maintain, secure and extend the platform.

The opportunity in the move

Because the move requires real engineering effort either way, it is the right moment to do more than lift-and-shift. Which custom components are still earning their place? Which integrations are still needed? What has the site accumulated that it could shed? A CMS 12 migration planned around those questions produces a leaner, more maintainable platform. One run as a mechanical port carries the old weight onto a new foundation.

What to do now

Start with an assessment of your CMS 11 implementation: the custom code, the plugins, the integrations, and which of them have a clean path to CMS 12 versus which need replacing. That picture sizes the work accurately and surfaces the dependencies that tend to cause overruns. Done independently of whoever will perform the migration, it also keeps the scope and the cost honest.

If your site is on Optimizely or Episerver CMS 11, the move to CMS 12 is a re-platform across the .NET divide, not a routine update — and it is better planned than postponed. We will establish what your implementation actually requires.

Start a Conversation