Two more database surprises when upgrading from CMS 11 to CMS 13

Back in June I wrote about four database surprises when upgrading from CMS 11 to CMS 13 (old post). Here are two more, found on another CMS 11 upgrade. Both come from the same place — the site name — and both break the new Application Manager while the public site keeps working as if nothing were wrong.

The background for both: the CMS 13 upgrade copies your site name verbatim from tblSiteDefinition into the new tblApplication table, where it becomes the application's identifier — with rules CMS 11 never had.

Whitespace in the site name: Application Manager won't even load the site

If the name has a trailing space ("My Swedish Site " — easy to have sat unnoticed for years), every attempt to view the site in Application Manager fails with:

System.NullReferenceException
   at EPiServer.Cms.UI.Admin.ApplicationManager.Internal.CompositeApplicationRepository.ToModel(Application application)

The name is round-tripped as a URL route key, where the trailing space is lost. The repository lookup on the other side is an exact dictionary hit (StringComparer.OrdinalIgnoreCase — forgives casing, not whitespace), so it returns null, and ToModel dereferences it without a guard.

This one is sneaky twice over: the public site keeps working (content binds via GUIDs, host resolution is unaffected), and the stack trace ends in whatever middleware sits first in your pipeline — pointing you at your own code instead of the actual problem.

Fix: RTRIM the name columns and restart — the application dictionary is cached under ep:apps. SQL in the gist below.

Swedish characters in the site name: Application Manager loads — but nothing can be saved

With the whitespace gone, a name like "My Swedish Sité" loads and displays just fine. But try to save anything — a new hostname, for example — and you get a validation error saying the name isn't valid. Renaming the application in the UI doesn't help; the error keeps pointing at the old name.

The reason is in EPiServer.Applications.Application:

/// The name must start with a letter and can only contain
/// letters, digits, and underscores.
[Required]
[ResourceName]                          // ^[A-Za-z][_0-9A-Za-z]+\z — ASCII only
public string Name { get; private set; }

The name is validated on every save against ^[A-Za-z][_0-9A-Za-z]+\z — ASCII only. Any å, ä, ö or space fails it. And the kicker: Name has a private setter, so it cannot be changed through the admin UI or any public API. Save clones the stored application — old name and all — validates the whole entity, and fails on the stored name no matter what you type. A migrated site with a non-ASCII name is permanently unmanageable in Application Manager until the name is fixed directly in the database.

The working fix: set a new ASCII Name in tblApplication and keep the human-readable name in DisplayName, which only has a length limit and is what editors see. Nothing else is derived from the name — hosts, entry point and assets bind via keys and their own columns — so the rename is safe. Restart afterwards, same cache.

Both issues are reported to Optimizely: the missing null guard, the missing name validation/normalization at migration, and the absence of any rename path for names the migration itself created in an invalid state.

Wrapping up

Same lesson as last time, with two more entries for the pre-flight runbook: check your site names before the first CMS 13 boot — both for whitespace and against ^[A-Za-z][_0-9A-Za-z]+\z. Detection and fix SQL is in this gist — as always, read it, understand it, and run it at your own risk: [Gist]