Optimizely Search & Navigation to Optimizely Graph Migration: What You Need to Know

If you have been running Optimizely CMS for some time, Search & Navigation is likely part of your setup. Many of you still call it Episerver Find, and it is often deeply integrated into the solution. It powers your site search, your listing pages, your "related content" blocks, and a dozen queries your team wrote years ago and hasn't touched since.

That era is ending. With the general availability of CMS 13 on March 31, 2026, Optimizely Graph becomes the platform's content query engine, and Search & Navigation is not part of Optimizely CMS 13. The Find packages will not be upgraded to support it. If CMS 13 is on your roadmap, and for reasons I covered in my earlier blog on Opal AI and AI-ready content operations, it should be, then a Graph migration is on your roadmap too.

The good news: this is one of the most well-supported transitions Optimizely has shipped, and with the right sequencing it is far less disruptive than teams fear. Here is what you need to know.

Why Optimizely is making this change

Search & Navigation was built for a different web. It assumes a server-rendered .NET application querying an Elasticsearch-style index through a LINQ-like API. That worked for MVC sites, but it was never designed for headless delivery, multi-channel content, or AI-driven discovery.

Optimizely Graph is the answer to that gap. It is a GraphQL-based, API-first content delivery service that ships content to web, mobile, and any other channel from a single source. It adds capabilities Search & Navigation never had: semantic search, recursive queries, delta imports, cursor-based pagination, and it is the same engine that powers the new Content Manager interface in Optimizely CMS 13.

Beyond replacing Search & Navigation, Optimizely Graph introduces several advantages that align with modern digital experience requirements. It provides headless architecture support, enabling organizations to build decoupled experiences across channels.

It enables omnichannel content delivery from a single source, offers faster content querying through GraphQL APIs, and delivers better scalability to support growing content ecosystems. It also establishes an AI-ready content infrastructure, improves search relevance through semantic capabilities, and gives organizations confidence that they are investing in a platform that will continue receiving future support and innovation from Optimizely. In other words, Graph isn't just a Find replacement. It is the delivery backbone of the CMS going forward, and the index your AI and personalization investments will sit on.

What carries over, and what doesn't

Most of what your search experience depends on exists on both sides. Full-text search, filtering, faceting, sorting, pagination, synonyms, stopwords, boosting, geospatial search, and best bets (now called pinned results) are all supported in Graph.

Graph also brings genuinely new capabilities: semantic search, Boolean facets, relevance-based ranking modes, time-decay scoring for boosting fresh content, and streaming for large result sets.

Two gaps deserve honest attention before you commit a timeline:

• No admin portal UI. Graph is administered through APIs, not a web interface. Synonyms, for example, are managed via REST rather than the Find admin screens your marketing team knows.
• No built-in statistics dashboard. Search analytics and tracking move to application-level or external analytics tooling. If your editors rely on Find's search statistics to drive content decisions, plan a replacement before cutover, not after.

There are behavioral differences too. The one that catches most teams: Graph has no "all languages" option for synonyms. If you run a trilingual site with one shared synonym list today, you will configure that list once per language in Graph. It is more precise though more work to set up.

The good news: we already have you covered. At Altudo, we know who lives in these admin screens day to day. The marketers and merchandisers managing synonyms, pinned results, and boosting and we know losing a UI is not an acceptable tradeoff for them. That is why we built a complementary administration UI on top of Graph's APIs, and natively available from the CMS. So your team keeps the visual, self-service workflow they have today while the platform underneath moves forward. Your developers get Graph. Your editors barely notice the change.

When to migrate: The timing question

Graph runs on CMS 12 today, and Search & Navigation continues to work on CMS 12. So should you migrate now, or as part of your Optimizely CMS 13 upgrade?

There is a hard date that compresses this decision: .NET 8 reaches end of support on November 10, 2026. Every CMS 12 site running on .NET 8 must take a platform upgrade this year regardless, either moving CMS 12 to .NET 10, which Optimizely now fully supports, or going straight to CMS 13, which is built on .NET 10 from the ground up. That makes a long deferral of the Graph question largely theoretical.

If you upgrade CMS 12 to .NET 10 as a stopgap, you are funding two platform projects in close succession and still carrying the Optimizely Graph migration into the second one. For most organizations, the .NET 8 deadline is the natural trigger to consolidate everything into a single Optimizely CMS 13 move with Graph adoption built in. This is exactly the kind of sequencing decision worth pressure-testing with a partner before you commit budget.

Some good news - Optimizely's recommended strategy, and the one we follow at Altudo, is incremental, with Search & Navigation as your safety net throughout. You can run both in parallel, while you are transitioning off Search & Nav, meaning there is no big-bang cutover and no weekend release where everyone holds their breath. The risk profile is closer to a feature rollout than a platform swap.

For your developers: The muscle memory transfers

The biggest source of anxiety I hear from engineering teams is "we have to learn GraphQL." With CMS 13, you largely don't. The `Optimizely.Graph.Cms.Query` SDK provides a C# fluent API that compiles your expressions into Optimizely GraphQL behind the scenes, and it deliberately mirrors the Find patterns your team already knows.

Optimizely also publishes a complete API mapping from every Search & Navigation method to its Graph equivalent, which turns migration from guesswork into a Optimizely Graph migration checklist.

Questions to answer before you start

From the migrations we have scoped, these determine effort more than anything else:

• How much custom Find code do you have?
• Who uses the Find admin UI today, and for what?
• What depends on search statistics?
• Do you use visitor group personalization in search results?
• Is your synonym and best-bet configuration documented?

What’s next

The move from Search & Navigation to Optimizely Graph is more than a technology upgrade. It represents a foundational shift toward an API-first, AI-ready future for Optimizely customers. While Search & Navigation has served organizations well for years, CMS 13 makes Graph an essential part of the modernization journey.

The good news is that this transition does not have to be disruptive. With the ability to migrate incrementally and run both solutions in parallel, teams can modernize with significantly lower risk while laying the groundwork for future investments in AI, personalization, and omnichannel experiences.

At Altudo, we have been working with Optimizely Graph since its early releases and have built migration accelerators for exactly this transition, from query inventory and effort assessment through parallel-run validation and cutover. If you are planning your CMS 13 move and want a clear-eyed view of what your Search & Navigation footprint means for the journey, let's talk.