.NET 8 and 9 Support Is Ending. Do You Need to Upgrade Optimizely CMS?
Microsoft support for .NET 8 and .NET 9 ends on November 10, 2026. For organizations running Optimizely on either version, the immediate question is how to move to a supported runtime. A CMS 13 migration is one option, but CMS 12 can also run on .NET 10.
The right scope depends on your application, its dependencies, and your wider plans for the platform. Start by establishing what is running today, then decide which changes belong in the next release.
What changes on November 10
After November 10, Microsoft will no longer provide security fixes, servicing updates, or technical support for .NET 8 and .NET 9. Applications will continue to run, but those runtime versions will be outside Microsoft support. Microsoft recommends .NET 10, a Long Term Support release supported through November 2028.
An operational website is not necessarily a supported website. Your team needs to know whether it can continue to receive fixes for the software beneath it.
How to check whether your website is affected
Optimizely CMS manages your website content. .NET provides the runtime and framework used by the application. Their version numbers describe different parts of the system: CMS 12 does not mean .NET 12.
Ask your development or hosting team to confirm:
- The .NET version actually running in production, including any runtime bundled with the application.
- The installed CMS and Commerce Connect package versions, add-ons, and third-party dependencies.
- Where the application is hosted and who owns application updates, runtime updates, and deployment.
Check the running application rather than relying only on project files or hosting settings. Those can show the intended runtime or installed versions without confirming what the application actually uses. Your technical team can record the runtime version in the application’s startup logs.
Check each environment separately: development, test, and production may be running different versions. For self-contained deployments, the runtime is bundled with the application, so applying a security patch requires rebuilding and redeploying it.
This guide concerns CMS and Commerce Connect implementations running on the affected .NET versions. Using another Optimizely product does not, by itself, establish that this deadline applies to your service.
Can you stay on CMS 12 and move to .NET 10?
Yes. Optimizely confirmed CMS 12 compatibility with .NET 10 in May 2026. Its announcement names EPiServer.CMS.Core 12.24.0 and EPiServer.CMS.UI 12.34.4 as minimum versions to address dependency vulnerability warnings. Later CMS 12 releases include further fixes, including for .NET 10 editing scenarios, so teams should target the latest patch releases at the time of the upgrade and review the complete dependency set.
Include the editing interface and rich-text editor in regression testing, because compatibility issues can affect content teams even when the website builds and starts successfully.
Retaining CMS 12 may be appropriate when the existing platform supports your business needs and the immediate priority is updating its underlying technology. Compatibility at the product level still needs to be validated against your custom implementation.
What if you also use Commerce 14?
Optimizely added .NET 10 support in Commerce Connect 14.46.0. For implementations using Search & Navigation with Commerce, it also specifies EPiServer.Find.Commerce 12.3.0 or later and advises updating the packages together. Check other add-ons and integrations as part of the same work.
That means moving to .NET 10 does not automatically require Commerce 15. However, the Commerce 14.46.0 and Find.Commerce 12.3.0 releases that add .NET 10 support also remove legacy BinaryFormatter serialization, and Commerce 14.47.0 changes how some promotion exclusions are applied. Package updates therefore still require impact assessment and testing, including pricing and checkout.
Plan the release sequence carefully. Package updates can change the database schema, so rolling back may require restoring the database as well as redeploying the application. Where the package versions support it, updating packages on the existing runtime first and switching to .NET 10 in a separate release helps isolate problems.
For implementations using Search & Navigation, confirm whether the required package changes involve a full reindex. Include the time needed to rebuild and validate search in both the deployment and rollback plans.
For example, First Line Software’s CMS 12 and Commerce 14 implementation for a luxury retailer connects product information, customer and order data, and payment services across Salsify, Tibco, and Fortis. These are the kinds of connected workflows an upgrade assessment needs to account for alongside the CMS and Commerce packages.
When to consider CMS 13 instead
Consider a broader upgrade when your plans already call for platform changes, when current limitations are blocking delivery, or when combining the work would avoid repeated changes to the same components. Compare that scope with a focused CMS 12 and .NET 10 update before committing.
For teams approaching the support deadline, this may be a question of sequence. A focused CMS 12 and .NET 10 update can address the immediate runtime requirement while a broader CMS 13 migration is assessed and planned.
That route may be appropriate when the existing platform meets business needs, Commerce is heavily customized, or essential add-ons are not yet ready for CMS 13. A broader migration deserves consideration when a redesign, search changes, or new platform capabilities are already on the roadmap. Compare the effort that carries forward with any work that would need to be repeated.
CMS 13 requires .NET 10 or later. Commerce Connect 15 also requires .NET 10 and depends on CMS 13; its documented changes cover areas including order processing, payment handling, and catalog APIs. Those changes need their own assessment.
The decision should account for business requirements, integration impact, delivery capacity, and testing effort. The runtime deadline alone does not tell you which CMS major version is right for your organization.
What should an upgrade assessment cover?
A useful assessment should produce a scoped recommendation and a release plan. It should cover:
- Compatibility: CMS, Commerce, search, add-ons, custom code and integrations.
- Environments: SDK versions, build pipelines and agents, deployment configuration, and hosting readiness, including memory limits on the new runtime.
- Validation: test editing and publishing, including the rich-text editor; forms, authentication, search results, scheduled jobs, and memory-heavy reports and exports. For Commerce, include catalog, pricing, promotions, cart, and an end-to-end checkout in test mode. Compare performance, memory usage, and errors before and after the change.
- Deployment: test on environments that reflect production hosting, rehearse database upgrades where applicable, and agree backups, rollback steps, production checks, and monitoring. Include search reindexing and any hosting support requests in the release plan.
- Where possible, release the package updates on the current runtime first and switch the runtime in a separate release, so each change can be tested and rolled back on its own.
A successful local build is not enough. Hosting limits, environment settings, and search indexes can affect the application after deployment. Check that search returns the expected results, rather than only confirming that requests succeed.
During testing, disable or redirect outbound integrations that could send live transactions or records to external systems. Agree acceptance criteria and a named owner for each release phase.
In a separate Optimizely migration project, First Line Software moved a live ecommerce platform’s digital assets to Optimizely CMP DAM, using visual regression testing, manual validation, and monitoring to check continuity. The migration was completed with zero downtime. Although the work concerned a DAM transition, it illustrates the importance of validating the customer-facing experience during platform changes.
What if you cannot finish before the deadline?
Ask the technical owner to document the affected applications, blockers, and earliest tested deployment date. Agree responsibility for completing the work and for managing the period on the unsupported runtime. For managed hosting, confirm the provider’s responsibilities and any deployment requirements directly.
Keep the application on the latest available patch while the upgrade is being completed. Record the unsupported runtime as an accepted risk, with a named owner and a target completion date. Closer monitoring can help manage exposure, but it does not replace security updates or extend Microsoft support.
For Commerce implementations, involve the person responsible for payment security and compliance in assessing the implications.
A deadline does not remove the need for testing. Make the remaining work visible and agree on a controlled route to production.
Choose the scope before committing to the upgrade
Start with your current implementation, its dependencies, and the time needed to test and release changes. From there, decide whether to update CMS 12 and Commerce 14 for .NET 10, plan a broader CMS 13 migration, or sequence the two.
First Line Software can support a focused .NET 10 update through assessment, package and runtime upgrades, regression testing, rollout support, and knowledge transfer.
Need to move your Optimizely application to a supported runtime? Talk to our team about the appropriate scope of the upgrade for your implementation.