The Direct CMS 11 to 13 Leap: Migration Patterns for Teams That Skipped CMS 12

Some teams skipped CMS 12 entirely. It wasn’t a bad decision at the time — CMS 11 was stable, CMS 12 required a .NET 5 re-platform, and the ROI on migrating during a global shift to remote work wasn’t compelling. But now CMS 13 is here, CMS 11 is approaching end-of-life, and the leap has become unavoidable.

If you’re one of those teams planning a direct CMS 11 to 13 migration, you’re facing a unique set of challenges. Unlike teams that moved through CMS 12 incrementally, you’re dealing with a three-layer transformation happening all at once: the runtime jump (.NET Framework to .NET 10), the identity overhaul (ASP.NET Membership to OAuth/OpenID Connect), and the content model changes (classic ContentType patterns to CMS 13’s component architecture).

This guide maps the specific migration patterns that only apply to the direct 11→13 leap, the gotchas that catch teams off-guard, and what you can parallelize versus what must happen sequentially.

The Three Transformation Layers

A direct CMS 11 to 13 migration isn’t one upgrade — it’s three simultaneous transformations that interact with each other in ways you need to plan for.

Layer 1 — Runtime: .NET Framework 4.8 → .NET 10 This is the most disruptive. You’re leaving behind years of .NET Framework patterns: System.Web, WebForms, full AppDomain isolation, and the GAC. Every third-party assembly, every custom HTTP module, every web.config transformation must be rewritten or replaced.

Layer 2 — Authentication: ASP.NET Membership/Identity → OAuth 2.0 / OpenID Connect CMS 11 uses ASP.NET Membership providers (SQL, Active Directory, SAML). CMS 13 uses OAuth 2.0 and OpenID Connect exclusively. Teams that migrated through CMS 12 had a softer path — CMS 12 introduced ASP.NET Identity as an intermediate step. You’re skipping that, which means you need custom provider stubs that bridge the old credential store.

Layer 3 — Content Model: Classic ContentType → CMS 13 Visual Builder CMS 13 introduces Visual Builder, component-based editing, and the componentized content pipeline. The content model migration is similar regardless of whether you’re coming from CMS 12 or CMS 11, but the timing matters — you’ll be doing it simultaneously with a runtime and identity overhaul that consume your team’s bandwidth.

Runtime Migration: .NET Framework 4.8 to .NET 10

This is the section most relevant to engineering leads and architects doing the initial migration scoping. The .NET Framework to .NET (Core) transition is well-documented at the platform level, but several specific issues compound in a CMS context.

The Assembly Compatibility Problem

CMS 11 on .NET Framework 4.8 permits GAC-installed assemblies, full-trust web.config configurations, and binary-serialized session state. CMS 13 on .NET 10 has none of these. The practical impact:

Every NuGet package in your CMS 11 solution must support .NET 10. If a package hasn’t been updated since 2020, you have three options: find a replacement, fork and port it yourself, or build an abstraction layer that isolates the dependency behind a .NET Standard 2.0 interface.

The most common blockers teams discover mid-migration:

• Legacy IoC containers (Unity, Autofac 4.x) — must upgrade to Autofac 8+ or switch to Microsoft.Extensions.DependencyInjection
• Custom HttpModule implementations — must be rewritten as ASP.NET Core middleware
• System.Web.Caching usage — must migrate to Microsoft.Extensions.Caching
• WCF service references — must be replaced with gRPC or REST equivalents
• Enterprise Library blocks (logging, exception handling) — all deprecated, all need replacement

The Configuration Breaking Point

CMS 11 configuration lives in web.config. CMS 13 uses appsettings.json and the Options pattern. The structural difference means all of the following must be addressed:

// CMS 13 appsettings.json equivalent of common CMS 11 web.config sections
{
  "EPiServer": {
    "Cms": {
      "ConnectionString": { "name": "EPiServerDB" },
      "ContentProviderMap": { ... },
      "Security": {
        "OAuthProviders": { ... }
      }
    }
  },
  "AllowedHosts": "*"
}

The practical challenge: many CMS 11 sites have configuration scattered across web.config, external config files, and environment-specific transforms. Auditing every configuration path before migration is essential — missing config surfaces as runtime errors, not compile-time errors.

Authentication Migration: From ASP.NET Membership to OAuth/OpenID Connect

This is where the direct 11→13 migration differs most sharply from the incremental path. Teams that went through CMS 12 had ASP.NET Identity as a transitional authentication layer — they migrated their legacy membership stores to Identity first, then Identity to OAuth in a separate step. You’re doing it all in one jump.

The Custom Provider Pattern

The most reliable approach for a direct migration is to build a custom OAuth provider that bridges your existing membership store to CMS 13’s authentication pipeline:

// Custom OAuth provider that authenticates against legacy CMS 11 membership store
public class LegacyMembershipOAuthProvider : OAuthProvider
{
    private readonly string _connectionString;
    private readonly string _membershipProviderName;

    public LegacyMembershipOAuthProvider(IConfiguration configuration)
    {
        _connectionString = configuration.GetConnectionString("EPiServerDB");
        _membershipProviderName = configuration["LegacyMembership:ProviderName"] ?? "SQLMembershipProvider";
    }

    protected override async Task<AuthenticateResult> HandleAuthenticateAsync()
    {
        // Extract credentials from the legacy login flow
        // Validate against the old aspnet_Membership tables
        // Create or map to a CMS 13 identity
        // Return AuthenticateResult with mapped claims
    }

    protected override async Task HandleChallengeAsync(AuthenticationProperties properties)
    {
        // Redirect to a legacy-compatible login page
        // that handles both new OAuth flows and legacy credential validation
    }
}

This approach lets you keep your existing user database operational while you plan a full identity migration to a proper IdP (Azure AD, Auth0, Okta, or Keycloak). The custom provider acts as a bridge — functional for the immediate cutover, replaceable when you have capacity for a proper identity strategy.

The Migration Sequence Most Teams Get Wrong

The common mistake is attempting to migrate authentication after the runtime migration. This creates a window where neither the old nor new authentication works reliably. The recommended sequence:

1. Build the custom OAuth bridge provider first — before touching the runtime
2. Test the provider against a CMS 13 development instance with your real membership data
3. Perform the runtime migration (.NET Framework → .NET 10) with authentication already in a testable state
4. Retire the legacy membership tables and provider after the IdP migration is complete

Content Model Migration: Classic ContentType to CMS 13

The content model migration is similar to what CMS 12→13 teams face, but the scope is larger because you’re dealing with content that may have been in production for 5+ years without a schema change.

Content Property Mapping

CMS 11 content types commonly use these patterns that need migration:

CMS 11 Pattern	CMS 13 Equivalent	Migration Approach
ContentArea with block types	ComponentList with VB components	Map registered block types to component registrations
XhtmlString (TinyMCE)	RichTextComponent in ComponentList	Content migrates, editor experience changes
Custom PropertyDefinition types	Custom component properties	Each custom type needs a direct mapping
PageReference / ContentReference	ContentReference (same data, new resolution)	Data migrates, API patterns shift
Dynamic properties on pages	Component-typed properties	Requires explicit schema migration

The Tenancy Gap

CMS 11 sites with multi-site configurations need careful handling. Site definitions, host bindings, and URL routing all changed between CMS 11 and CMS 13. A site that maps host names to content roots in CMS 11’s Sites.config or web.config must be remapped in CMS 13’s configuration model. The migration utility handles the basic mapping, but custom host resolution logic — especially for sites with wildcard bindings or language-specific hosts — needs manual review.

Parallel vs. Sequential Work Streams

The biggest risk of a direct 11→13 migration is treating all three layers as one work stream. They’re not. Here’s how to think about parallelism:

Can be done in parallel (independent teams):

• Runtime migration engineering and NuGet audit
• Authentication bridge provider development
• Content model audit and component mapping

Must be done sequentially (depends on completion of prior step):

• Runtime migration → integration testing with custom auth provider
• Integration testing → content migration
• Content migration → editor training and UAT

The optimal timeline for a mid-size CMS 11 site (50-200 content types, 10-30 blocks, custom auth) is typically 10-16 weeks with a dedicated team of 2-3 developers. Teams that attempt to parallelize the sequential steps inevitably discover issues at integration time that consume the weeks they saved.

What This Means for Your Migration Timeline

The total effort for a direct 11→13 migration is roughly 1.5x to 2x that of a CMS 12→13 migration. The additional effort comes from the identity layer — building and testing the custom OAuth bridge provider — and from the broader runtime compatibility surface.

However, the total is often less than the sum of two separate migrations (CMS 11→12, then 12→13). You save the intermediate deployment, the dual-maintenance period, and the overhead of coordinating two separate upgrade projects with your team’s capacity.

The key decision point: if your CMS 11 site has heavy custom authentication (SAML with custom attribute mapping, Active Directory with nested group resolution, or a proprietary identity store), the direct 11→13 migration’s authentication bridge effort may approach the cost of a separate CMS 12 intermediate step. In those cases, a staged approach — CMS 11→12 first to simplify identity, then 12→13 for the content model — can be more predictable even if the total calendar time is longer.

Getting Started

1. Audit your CMS 11 solution — inventory every NuGet package, HTTP module, custom membership provider, web.config section, and third-party dependency.
2. Build the auth bridge first — the custom OAuth provider is your longest-lead item and determines whether the rest of the migration can proceed on schedule.
3. Choose a content migration strategy — all-at-once cutover vs. phased content type migration. For direct 11→13 leaps, a phased approach is recommended to reduce risk.
4. Set up a parallel test environment — you need a CMS 13 instance with your custom auth bridge and a subset of your content model running before you commit to the full migration.
5. Plan for editor training — CMS 13’s Visual Builder is a fundamentally different editing experience from CMS 11. Don’t assume muscle memory carries over.

A direct CMS 11 to 13 migration is more complex than the incremental path, but for many teams it’s the right call. The key is recognizing that you’re doing three transformations in one, planning the sequences carefully, and not underestimating the authentication layer. With the right preparation, the direct leap saves time, avoids dual-maintenance, and gets you to CMS 13’s ecosystem faster.

Need a hand with your CMS 11 to 13 migration? Contact the geniusOS team for a migration scope assessment or a second opinion on your upgrade timeline.