Two weeks into a CMS 12 → 13 migration

A few honest notes from the field, two weeks in.

The new platform is good. There’s clean .NET 10 underneath, dependency injection used properly throughout, and a serious commitment to headless. Cold starts are noticeably faster, the memory footprint is smaller, and the codebase finally feels like it belongs in 2026.

A good platform doesn’t make for a smooth migration, though. Those turned out to be separate problems.

The CMS itself isn’t where the difficulty lives. It’s everything around it. The Content Delivery API packages we’ve relied on for years are pinned hard to CMS 12, and the official replacement story comes in two halves: Graph for reads, REST API for management. The docs for both are still being filled in. Support replies and webinar Q&As don’t fully agree with each other yet either, which tells you how new all of this still is.

Then there are the less glamorous surprises. Database collation differences breaking startup. Historical content type names that the old CMS accepted without complaint, now rejected by the new validators. Custom add-ons written years ago by someone who’s long gone. You won’t find any of this in a release note.

Last week I hit a point where I started wondering whether the timing was right at all. Then we sat down for an architecture sync and walked through what the next two or three years of feature work look like on each stack, and the discussion stopped being abstract. Paying off this debt now costs less than carrying it into another major release cycle. That meeting straightened out my thinking.

Where we landed: with no near-term pressure, we’re staying on 12 for now and will revisit once the partner ecosystem catches up.

I’d like to hear how others are handling this, especially the third-party packages that still don’t have a 13-compatible release.