Recently, while upgrading an Optimizely CMS 12 solution from .NET 8 to .NET 10, we encountered a frustrating exception that initially looked like a CMS compatibility issue. After several rounds of troubleshooting with Optimizely Support, dependency analysis, debugging, and elimination testing, the root cause was eventually traced back to the Siteimprove Optimizely plugin.
This blog shares the journey, findings, root cause, and final resolution to help others who may encounter the same problem during their CMS 12 modernization efforts.
The Upgrade Journey
As part of our modernization initiative, we upgraded:
- Optimizely CMS from 12.34.3 to 12.34.5
- Application runtime from .NET 8 to .NET 10
- Supporting CMS packages and dependencies
- Development environment to Visual Studio 2026
Most of the upgrade activities went smoothly. We successfully resolved issues related to:
- TinyMCE initialization
- Language Manager gadget visibility
- Dependency scanning problems
- .NET 10 compatibility adjustments
However, another issue surfaced immediately after the upgrade.
The Exception
Whenever editors attempted to open any block in the CMS editor, Optimizely threw the following exception:
and appeared before any custom block code was executed.
At first glance, this looked like:
- Database corruption
- Content type mismatch
- Invalid content references
- CMS core regression
All reasonable assumptions.
Unfortunately, all of them turned out to be wrong.
Initial Investigation
The first suspicion was corrupt CMS data.
Optimizely Support referenced earlier cases where similar exceptions were caused by invalid fkContentTypeID values in the database. They recommended comparing content records between healthy and failing environments.
To validate this theory, we:
- Restored multiple database backups
- Created fresh blocks
- Tested newly created content
- Verified content type mappings
Surprisingly, the issue persisted even on fresh databases.
This effectively ruled out data corruption as the primary cause.
The Breakthrough
During the investigation, Optimizely’s development team performed deeper tracing and discovered something interesting.
Their analysis revealed:
“It’s a bug in the package SiteImprove.Optimizely.Plugin which subscribes to contextChange and gets PageData for all content without checking the type.”
This was the clue we needed.
Under .NET 10 and the newer CMS version, this incorrect type handling became visible and resulted in:
The Root Cause
The Siteimprove Optimizely integration was subscribing to content context change events.
During those events, it attempted to retrieve content using logic that effectively expected: PageData for every content item.
The plugin did not properly verify whether the content was:
- PageData
- BlockData
- MediaData
- Other CMS content types
before casting or loading it.
Confirming the Cause
One of the most valuable debugging techniques during upgrades is dependency isolation.
We tested by removing the Siteimprove package entirely.
The result was immediate.
The TypeMismatchException disappeared.
Even Optimizely support confirmed that after retesting, the exception was no longer reproducible once the problematic plugin code path was removed.
At this stage the evidence was conclusive.
The upgrade itself was not the root cause.
The Siteimprove plugin was.
The Fix
After engaging Siteimprove support and raising a GitHub issue, their development team investigated and released an updated package:
SiteImprove.Optimizely.Plugin 4.3.5
The updated version addressed the compatibility issue.
