CMS 12 and Commerce 14 overview

This module initiates the e-learning section on migrating to CMS 12 and Commerce 14. It provides a technical overview of Optimizely’s latest Digital Experience Platform versions, focusing on architectural shifts, key features, and the benefits these platforms offer to developers and businesses.

For teams coming from older Optimizely builds, the change is not just “new packages.” CMS 12 and Commerce 14 are aligned with modern .NET, which means your mental model (and a few beloved habits) must update. This overview helps you build the right foundation before you get into migration mechanics.

1. The shift to .NET 6 and ASP.NET Core

The most profound architectural change in Optimizely CMS 12 and Commerce 14 is the transition from the legacy .NET Framework to .NET 6 (and ASP.NET Core). This aligns Optimizely’s DXP with Microsoft’s modern, high-performance, cross-platform stack.

This transition is not merely an update; it is a re-platforming. You move away from the classic ASP.NET request pipeline, configuration patterns, and hosting assumptions—and into the ASP.NET Core way of composing and running web apps.

Key implications for developers

• Cross-platform development: applications can run on Windows, Linux, and macOS, enabling more flexible hosting and deployment strategies.
• Performance enhancements: .NET 6 improves throughput, startup time, and memory usage—benefiting both site delivery and administrative workloads.
• Removal of System.Web: web.config-centric configuration, HttpModules, and Global.asax patterns are replaced by appsettings.json, middleware, and programmatic setup.
• Unified platform: modern .NET reduces fragmentation and standardizes the tooling and runtime story across project types.

2. Optimizely CMS 12: key architectural changes and benefits

Optimizely CMS 12 is re-engineered on ASP.NET Core, adopting the modern application composition model and benefiting from the .NET 6 runtime improvements. In practice, you’ll feel this in how you configure the app, register services, and reason about the request pipeline.

Configuration

The configuration paradigm shifts from web.config to appsettings.json (plus environment-specific overlays), and programmatic configuration in Program.cs (or Startup.cs in some setups). This makes configuration more hierarchical, environment-aware, and testable.

Example: Basic Optimizely CMS 12 Program.cs (minimal hosting model)

The snippet below shows how Optimizely services are registered and then activated in the ASP.NET Core pipeline.

using EPiServer.Cms.UI.AspNetIdentity;
using EPiServer.Web.Host;
using Microsoft.AspNetCore.Builder;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddCmsHost()
    .AddCmsUI()
    .AddAspNetIdentity<ApplicationUser>();

builder.Services.AddCms();

var app = builder.Build();

if (app.Environment.IsDevelopment())
{
    app.UseDeveloperExceptionPage();
}

app.UseStaticFiles();
app.UseRouting();
app.UseAuthentication();
app.UseAuthorization();

app.UseCms();

app.Run();

Dependency injection

ASP.NET Core has built-in dependency injection, and CMS 12 leans into it heavily. Services are registered in Program.cs and injected via constructors. This promotes a cleaner architecture and improves testability.

Middleware

The old HttpModules model is replaced by ASP.NET Core middleware. Middleware is explicit, ordered, and composable, giving you more predictable request handling and easier debugging when something goes sideways.

Cloud-native readiness

CMS 12 aligns with modern cloud hosting patterns (containers, managed web apps, and scalable infrastructure), reducing friction when deploying and operating in environments like Azure.

Headless capabilities

CMS 12 supports decoupled delivery patterns with APIs and SDKs, enabling omnichannel content delivery across websites, apps, and other front-ends without duplicating content management workflows.

Performance

Beyond .NET 6 runtime improvements, CMS 12 includes platform-level optimizations that improve delivery performance and the responsiveness of editorial/admin flows.

3. Optimizely Commerce 14: key architectural changes and breaking changes

Commerce 14 also moves fully to ASP.NET Core, and with that comes several breaking changes that tend to be “migration hot spots.” This is where many upgrades slow down—not because Commerce is hard, but because legacy dependencies are stubborn.

Configuration management

Commerce configuration shifts into the ASP.NET Core configuration model, typically via appsettings.json plus the Options pattern (strongly typed configuration objects).

Membership provider

The legacy ASP.NET Membership Provider is deprecated and not supported. Commerce 14 expects identity and user management through ASP.NET Identity.

Payments

The Mediachase.Commerce.Plugins.Payment assembly is removed, which impacts older provider integrations. Payment integration often needs refactoring toward modern gateway SDKs or direct API integrations.

Example: adding Commerce services in Program.cs

This snippet shows CMS + Commerce composition in the same ASP.NET Core host.

using EPiServer.Cms.UI.AspNetIdentity;
using EPiServer.Commerce.UI.AspNetIdentity;
using EPiServer.Web.Host;
using Microsoft.AspNetCore.Builder;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddCmsHost()
    .AddCmsUI()
    .AddAspNetIdentity<ApplicationUser>();

builder.Services.AddCommerce()
    .AddCommerceAspNetIdentity<ApplicationUser>();

builder.Services.AddCms();

var app = builder.Build();

if (app.Environment.IsDevelopment())
{
    app.UseDeveloperExceptionPage();
}

app.UseStaticFiles();
app.UseRouting();
app.UseAuthentication();
app.UseAuthorization();

app.UseCms();
app.UseCommerce();

app.Run();

4. Benefits for developers and businesses

The upgrade to CMS 12 and Commerce 14 brings practical benefits that show up in day-to-day dev and ops work: faster apps, easier cloud hosting, improved security posture, and a more modern development experience.

• Modern technology stack: access to current .NET features, tooling, and best practices.
• Improved performance and scalability: better throughput and responsiveness under load.
• Enhanced security: alignment with actively supported frameworks and security patching.
• Cross-platform and cloud-native: more options for hosting models (including containers) and streamlined cloud deployments.
• Increased developer productivity: DI + middleware + modern config patterns reduce friction and improve maintainability.
• Headless and API-first approach: content/commerce delivery across channels without rebuilding the content engine each time.

5. Conclusion

Migrating to Optimizely CMS 12 and Commerce 14 is not a routine upgrade—it’s a modernization step that changes how the platform is built, configured, and extended. You’ll address real breaking changes, especially where legacy dependencies existed.

The payoff is a DXP aligned with modern .NET: faster, more scalable, better suited for cloud operations, and more flexible for omnichannel delivery. Once you’re on this foundation, future platform work tends to feel less like archaeology.