Written version
This webinar explains why companies consider moving production search from Elasticsearch to Vespa, the architectural differences that motivate that decision, and the stages used to evaluate and carry out a migration.
What Vespa is
Vespa is a platform for building and running real-time AI search applications, including RAG, enterprise search, recommendations, and personalization. The webinar introduces it as a unified platform for search and ranking that supports different data types and computations through its tensor framework.
It performs computations where the data resides, reducing the need to move data between separate retrieval and ranking systems and making updates available in real time.
Who typically considers an Elasticsearch-to-Vespa migration
The companies discussed in the webinar have search as a core business driver. Search performance directly affects conversions and customer experience.
They tend to be in one of two situations. Established enterprises already have mature search platforms, most often based on Elasticsearch, OpenSearch, or Solr, and are exploring how to add AI and vector-search capabilities. Earlier-stage companies have proved their value with a proof of concept and now want to establish a search architecture that can support their next phase of growth.
Why Lucene-based vector search can strain at scale
Lucene-based systems organize data into immutable segments. Lucene has been optimized over time for keyword search, while vector search operates within that segment model.
This may not be a problem at smaller scale or for workloads without frequent writes and updates. At larger scale, however, customers can encounter resource spikes, latency spikes, and inconsistent query times. The scale may come from queries per second, index size, or write throughput.
Each segment has its own HNSW graph. When segments merge, those graphs are rebuilt. Search also has to operate across segments, which means traversing more than one graph before combining the results. The webinar identifies these operations as possible sources of update cost and variable query latency in large vector-search deployments.
How hybrid search magnifies the problem
Elasticsearch makes it straightforward to express keyword and vector retrieval in one query. Internally, however, hybrid retrieval still uses separate structures: an inverted index for keywords and a vector index for nearest-neighbor search.
Both structures exist within immutable segments and are affected by the segment lifecycle. A hybrid query retrieves candidates from the different indexes and then combines the results, using a method such as reciprocal rank fusion.
Updates also matter. In the e-commerce example from the webinar, a document may contain a product vector alongside frequently changing values such as price. Updating the document means working within an immutable segment model even when only one value has changed. At scale, the combination of retrieval, result merging, and frequent updates introduces more moving parts.
Why advanced ranking often adds another system
Custom scoring and reranking are foundational requirements for many advanced search applications. A common Elasticsearch architecture retrieves a top set of documents, sends them to an external reranking service backed by separate machine-learning infrastructure, and then serves the rescored results.
This approach is flexible, but it adds infrastructure to operate. Moving reranking outside the search system can also make index-time features, scoring signals, and query-time statistics harder to use in the reranking stage.
Vespa provides native multi-phase ranking. Retrieval can be followed by first-phase ranking, second-phase reranking, and global-phase ranking. These phases can use query signals, document features, and ranking expressions close to the data. Machine-learning models, including gradient-boosted models and models exported through ONNX, can also run within the Vespa serving infrastructure.
Ranking profiles support faster experimentation
Vespa ranking profiles define alternative ranking configurations in the application package. A team can create separate profiles for lexical, semantic, or hybrid search and select a profile when sending a query through the Vespa API.
The webinar presents this as a way to experiment with ranking strategies or deploy ranking changes without building a separate serving path for each approach.
An e-commerce example
E-commerce search often combines keywords, vectors, and filters such as price, stock, and seller. Search and recommendation may also be operated as separate systems.
Vespa can serve search and personalization from the same engine and use machine-learning models for both. Frequently changing values such as stock and price can be updated and become immediately visible to queries, allowing them to affect filtering and ranking without a refresh operation.
Vespa's tensor framework also supports multi-vector representations. Text, image, and multimodal signals can therefore participate in the same search and ranking application.
How the migration process works
The webinar describes migration as four stages: audit, proof of concept, benchmarking, and phased rollout.
1. Audit the current Elasticsearch setup
Start by analyzing the current Elasticsearch architecture, resource usage, and dependencies. Identify plugins, custom features, and capabilities that may not map directly to Vespa. The result should clarify the work involved and the areas that require further investigation.
2. Build a proof of concept for functional equivalence
Translate the relevant Elasticsearch schemas into Vespa schemas and map the query types used by the application. Elasticsearch Query DSL constructs need Vespa equivalents; Elasticsearch aggregations, for example, correspond to grouping in Vespa.
The proof of concept should use a representative sample of production data, representative search queries, and the business logic that matters to the application. Its purpose is to establish that the required behavior can be reproduced before testing the system at production scale.
3. Benchmark search quality and performance separately
First evaluate search quality. Use a golden set and measures such as top-k recall to determine whether the Vespa implementation provides the required results. Latency is not the focus at this stage.
After reaching the required quality, run performance benchmarks for latency, concurrency, resource usage, and cost. Provision Vespa and Elasticsearch with the same dataset and query set so their behavior can be compared. For large production systems, tests can progress through representative fractions such as 10%, 25%, and 50% of production data before moving to full scale.
4. Roll out in phases and monitor continuously
Keep Vespa running in parallel with Elasticsearch while production traffic moves gradually to the new system. The webinar describes progressing through development, staging, and production, then diverting traffic in controlled stages.
Monitoring and rollback are essential throughout the rollout. If a problem appears, traffic can return to Elasticsearch. The transition is complete after the relevant quality and performance measures remain stable under production traffic.
What is difficult about adopting Vespa
Vespa is a different stack with different terminology and operating practices, so teams face a learning curve.
Self-hosting can add complexity when an organization needs multi-tenancy, a multi-node cluster, or dynamic scaling. The webinar presents Vespa Cloud as one way to reduce this infrastructure burden during the early stages, allowing the team to focus on building the application.
Questions from the webinar
Can an audit be completed before signing up for Vespa?
Yes. The audit is independent of Vespa adoption. It evaluates the current system and produces a plan covering migration challenges, risks, and considerations.
How long does an audit take?
At the time of the webinar, a typical audit was described as a fixed-price, fixed-timeline engagement lasting two to three weeks, depending on the complexity of the organization.
Do real-time updates require refresh operations?
No. Vespa uses mutable data structures, and updates become immediately visible. A separate refresh operation is not required.
How much data is required for benchmarking?
It depends on the scale of the production system. A relatively small dataset can be tested in full. For datasets in the terabyte range, the webinar recommends starting with representative samples such as 10% or 20% and increasing the scale during benchmarking.