Already know you're moving off Optimizely?
This page helps you decide which parts of the suite to keep and which to replace. If you want a team to plan and run the migration, see Website migration services.
What Optimizely is, and why you’re probably here
Optimizely today is really two heritages under one brand: Episerver, the .NET CMS that became the Nordic and Northern-European standard for large organizations, and Optimizely, the experimentation platform that supplied the name recognition. The merged company sells a suite (content management, experimentation, and commerce), but most installed estates are Episerver-heritage CMS implementations, often years old and deeply customized in .NET.
Most visitors to a page like this run one of those estates and are asking a suite-shaped question: which parts of Optimizely are actually earning their keep? That’s the honest framing we’ll use, because the parts decouple.
Where Optimizely still fits
The experimentation product is genuinely strong. For many teams it’s the piece that would survive any platform review, and it works fine pointed at a non-Optimizely website. The CMS side fits when the organization is a committed .NET shop with a current implementation, uses the personalization and commerce integrations as an actual suite, and has the specialist capacity to run it. It also covers the requirements procurement checks: SSO, role-based workflows, audit trails, vendor SLAs. Optimizely’s SaaS CMS direction offers a headless-flavored modernization path inside the vendor relationship, which matters to teams that want lower risk without a new procurement cycle.
Why teams migrate the CMS away
- Suite pricing for CMS-only needs. When the website is the only part of the suite in real use, the licensing is out of proportion to what’s delivered.
- Monolith drag. Long-lived Episerver-heritage implementations couple content, templates, and .NET code, so front-end delivery is slower than it should be, and editors queue behind developers for changes that should be routine.
- Specialist dependence. Episerver/Optimizely CMS developers are a small, regional pool; delivery capacity is capped by it.
- The suite decouples anyway. Experimentation runs happily against any front end. Keeping it doesn’t require keeping the CMS.
Stay or go: the short version
| Stay on the Optimizely CMS when | Move the CMS when |
|---|---|
 Personalization and commerce are in real use alongside the CMS: the suite is actually a suite |  The website is the only part of the suite earning its keep |
| Your implementation is current and your .NET team runs it comfortably | The estate is years old, deeply customized, and slow to change |
| Specialist capacity, internal or partner, is secure and affordable | Delivery queues behind a small regional pool of Episerver specialists |
| Moving to Optimizely's SaaS CMS is a realistic modernization for your setup | You're facing a rebuild-scale re-implementation either way |
| Editors are productive and campaigns ship without developer tickets | Editors are blocked on developers for routine pages and updates |
The realistic paths off the Optimizely CMS
Stay, but modernize
Move to Optimizely’s SaaS CMS and decouple the front end, staying inside the vendor relationship. This is the lowest-disruption path through procurement, but suite pricing and the specialist pool remain the constraint.
Keep experimentation, replace the CMS
Rebuild the web estate on a headless CMS and a modern framework, and keep Optimizely Experimentation pointed at the new front end. This is the most common pattern we see: the cost win comes from the CMS side, where going headless consolidates the estate and gives editors autonomy, while the experimentation program carries over without disruption. Content, URLs, and SEO have to be handled deliberately: content model mapping, a full redirect plan, and editorial retraining are part of the project.
Pricing, in plain terms
Optimizely pricing is negotiated per product, not listed. CMS licensing for Episerver-heritage estates typically runs into five or six figures per year before implementation and operations; experimentation is priced separately, usually by traffic and scope. The growth drivers are the number of suite products under contract, sites and markets on the CMS, and partner day rates for a shrinking specialist pool. The practical consequence: because the products are priced separately, they can be evaluated, and kept or dropped, separately.
The Bejamas take
Optimizely is the migration where the answer is most often partial: keep the experimentation product, move the web CMS off the monolith. The Episerver-heritage CMS is where the licensing weight, the .NET coupling, and the specialist bottleneck live. It’s the part a composable stack replaces cleanly, while experimentation carries over to the new front end without drama. Whether that split is right for you depends on how much of the suite is genuinely in use and how current the implementation is. In an audit we map which Optimizely products are actually load-bearing, model the paths, and recommend one honestly. Then, if it’s a migration, we run it without losing your rankings.