Replacement Mindset

By Optimizely Education
Published: Mar 11, 2026
Rating 1 star 2 stars 3 stars 4 stars 5 stars

Average rating: 0 No reviews

Outline

At a glance

Paradigm shift: Moving from .NET-bound LINQ to platform-agnostic GraphQL delivery.
Performance: GraphQL prevents over-fetching by retrieving only the specific data required for the UI.
Unified search: Graph aggregates data from CMS, PIMs, and external sources into a single delivery hub.
Composability: Native Graph integration is the standard, but the architecture remains open to specialized third-party engines.

The release of Optimizely CMS 13 necessitates a fundamental transition in how search and navigation features are architected. The legacy Optimizely Search & Navigation has been deprecated, marking a shift from a .NET-centric, LINQ-based querying model to a service-oriented, GraphQL-based delivery engine.

To succeed in this new environment, developers must adopt a "Replacement Mindset" that prioritizes service decoupling, schema-driven data retrieval, and cross-channel content availability.

1. The Core Mindset Shift: LINQ vs. GraphQL

For over a decade, Optimizely developers used the "Fluent API" to construct search queries. This model was tightly bound to the .NET execution context, treating search as an extension of C# collections.

The Legacy Paradigm (Search & Navigation):

Syntax: Focused on C# LINQ providers (.Search<T>(), .Filter()).
Execution: Highly dependent on the .NET runtime and local class assemblies.
Scope: Primarily searched content stored within the local CMS database.

The Modern Paradigm (Optimizely Graph):

Syntax: Uses standardized GraphQL fragments and arguments.
Execution: Executed against a managed, globally distributed delivery hub.
Scope: Aggregates content from the CMS, external PIMs, DAMs, and "Shadow Content" types.

2. Technical Comparison: Query Construction

The transition requires translating intensive Fluent LINQ logic into structured GraphQL queries. While the objective remains the same—retrieving relevant content—the implementation reflects a shift toward frontend-agnostic delivery.

Legacy implementation (Search & Navigation):

var results = searchClient.Search<StandardPage>()
    .For("Optimizely")
    .Filter(x => x.MainBody.Match("Graph"))
    .OrderByDescending(x => x.StartPage)
    .Take(10)
    .GetContentResult();

Modern implementation (Optimizely Graph):

In CMS 13, the same intent is expressed as a GraphQL query, which can be executed via the .NET SDK or directly via a simple HTTP POST.

query SearchContent($term: String!) {
  Content(
    where: { 
      _Metadata: { types: { eq: "StandardPage" } },
      MainBody: { contains: "Graph" }
    },
    limit: 10,
    orderBy: { StartPage: DESC }
  ) {
    items {
      Title
      MainBody
      Url
    }
  }
}

Technical Advantage

The GraphQL approach avoids "Over-fetching." Developers request only the specific properties required for the UI component, whereas the legacy GetContentResult() often loaded entire IContent objects into memory.

3. Leveraging the "Graph Advantage"

Adopting Graph is not merely about replacing like-for-like features; it is about leveraging architectural capabilities that were unavailable in Search & Navigation.

Multi-Source Agnostic: While Search & Navigation was "CMS-only," Graph allows developers to ingest data from external repositories using the Graph Source SDK. This permits a single query to return both CMS pages and external product catalog items.
Semantic Relevance: Graph supports vector-based search capabilities, allowing for "concept-based" matching rather than simple string matching—a critical requirement for modern AI-driven experiences.
Faceted Navigation: Faceting in Graph is "automatic" based on the schema. Developers do not need to manually register "Facets" in the same way they did with legacy Find; instead, they utilize GraphQL aggregations directly.

4. The Composability Path: Third-Party Alternatives

Because CMS 13 is built with a composable architectural philosophy, the mandatory nature of Graph for internal platform functions does not preclude the use of third-party search providers for specific frontend experiences.

If a technical requirement necessitates a specialized engine—such as Algolia for ultra-low latency e-commerce search or Elasticsearch for highly specialized analytical queries—the CMS 13 architecture supports this.

Decision Rationale

Use Optimizely Graph: When the objective is high-performance, multi-channel content delivery with native integration and "zero-configuration" indexing.
Use Third Party: When the project requires highly specific, proprietary search algorithms or when migrating from a pre-existing enterprise search standard.

Conclusion

The deprecation of Search & Navigation is more than a technical cleanup; it is a mandate to move toward Service-Oriented Architecture (SOA). Transitioning to Optimizely Graph requires developers to stop thinking about search as a .NET library and start treating it as a central content delivery hub. By mastering the transition from Fluent LINQ to Schema-driven GraphQL, implementers ensure that their search solutions are faster, more efficient, and ready for the composable, AI-augmented future of the Optimizely One ecosystem.