This brief provides an overview of a typical migration.
Elasticsearch has grown into a widely used search and analytics engine, supporting diverse enterprise applications beyond full-text search. However, as data volumes expand and AI-driven applications demand lower latency and greater scalability, Elasticsearch faces performance, complexity, and operational cost limitations. Organizations struggle with scaling, performance tuning, and service disruptions, making it increasingly challenging to meet modern demands.
Performance benchmarks and real-world deployments demonstrate that Vespa delivers significantly higher efficiency, processing more queries per CPU core, supporting greater query loads, and enabling faster real-time updates. Companies like Vinted have reported improvements such as faster indexing and lower infrastructure costs. While replacing Elasticsearch with Vespa offers clear benefits, migration must be carefully managed. Vespa’s technical documentation and migration partners such as Searchplex help streamline the process.
This brief provides an overview of a typical migration. If you want a high-level overview of how Vespa’s architecture differs (from an operational standpoint) from that of Elasticsearch’s, review this presentation.
“The migration was a roaring success. We managed to cut the number of servers we use in half (down to 60). The consistency of search results has improved since we’re now using just one deployment (or cluster, in Vespa terms) to handle all traffic. Search latency has improved by 2.5x and indexing latency by 3x. The time it takes for a change to be visible in search has dropped from 300 seconds (Elasticsearch’s refresh interval) to just 5 seconds. Our search traffic is stable, the query load is deterministic, and we’re ready to scale even further.”
Elasticsearch was built on Apache Lucene for full-text search and analytics. Vector search, hybrid ranking, and frequent updates expose limits in that design as data volumes and traffic grow.
Lucene stores data in immutable segments, each with its own HNSW vector graph. Updates and segment merges force graphs to be rebuilt, causing resource spikes, and every query must traverse a graph in each segment, which makes tail latency unpredictable under load.
Hybrid queries run keyword and vector retrieval separately across every segment, then merge the results with rank fusion. CPU and I/O costs grow with data volume and concurrency, and the merged results aren’t ranked together with your business signals.
Custom scoring and reranking often end up in a separate rerank service and ML infrastructure. That service loses context the engine had, such as index-time features, scoring signals, and query-time statistics, and adds operational complexity.
Vespa runs retrieval, multi-phase ranking, and model inference in one engine, close to the data. Keyword, vector, and business signals such as price, stock, and seller combine in a single query. Attribute updates, such as price changes or back-in-stock flags, are visible to queries immediately. Teams can test new ranking ideas by selecting a different rank profile per query.
In our published benchmark on one million e-commerce products, Vespa delivered 8.5× higher throughput per CPU core for hybrid queries, up to 12.9× for vector queries, and 6.5× for lexical queries, with about 4× more efficient in-place updates (Vespa 8.427.7 and Elasticsearch 8.15.2, November 2024).
Starting with a proof of concept, a multi-phased migration approach is the most effective strategy for transitioning between search engines, ensuring minimal risk, stable performance, and a controlled rollout. Unlike a Big Bang migration, which can lead to workload overload, unforeseen failures, and degraded search performance, a step-by-step transition enables thorough testing, iterative refinements, and built-in fallback options. This approach reduces disruptions, allows for real-time performance validation, and ensures the new system is fully optimized before taking over production traffic.
Before building anything, audit your Elasticsearch deployment: data models and mappings, query types, business logic in scripts and ingest pipelines, ranking requirements, update rates, and current performance and cost baselines. The audit defines what the proof of concept must reproduce and the metrics it must beat.
A successful migration begins with forming a dedicated team of search engineers and system architects with expertise in existing and target search technologies. Teams new to Vespa can bring in a migration partner to fill gaps in expertise. This team should define key focus areas for the migration, including:
Architecture: Designing a scalable and performant system with the new search engine.
Infrastructure: Planning server deployment, resource allocation, and load balancing.
Indexing: Optimizing real-time data ingestion, ensuring minimal latency.
Querying: Fine-tuning search logic, ranking models, and hybrid search capabilities.
Metrics & Performance Testing: Monitoring system behavior and validating performance under production-like conditions.
Migration begins with developing a proof of concept (PoC) and refining it through iterations until it meets functional, performance, and relevance requirements. This typically involves defining a Vespa application package with a schema that fits the data model and ingesting a representative sample of production data, along with a representative sample of production queries to test against. Tools like Logstash can assist with this process. During this phase, organizations may need to adjust the schema and map Elasticsearch concepts to Vespa, using resources like the Vespa glossary to guide the transition.
Once data is available in Vespa, queries need to be translated as well. Vespa offers multiple ways to express queries, similar to Elasticsearch. Those using SQL or ES|QL in Elasticsearch may find Vespa’s YQL a natural alternative. Vespa's select syntax provides equivalent functionality for applications built on the JSON Query DSL. Aggregation queries can be adapted using Vespa’s grouping feature, which supports nested structures like Elasticsearch. Business logic held in Elasticsearch scripts, ingest pipelines, or application code needs translating too, typically into Vespa ranking expressions, document processors, or searchers.
Once functional equivalence is achieved, the next step is scaling the Vespa cluster to accommodate the full dataset and conducting performance testing. Unlike Elasticsearch, which relies on a fixed number of physical shards, Vespa distributes data across many virtual buckets. This approach simplifies scaling, eliminating the need to manually manage sharding when adding or removing nodes.
Performance optimization typically involves gradually increasing query load, monitoring key metrics, and adjusting cluster size. Vespa’s performance guides provide additional insights on capacity planning, tuning, and best practices for optimizing efficiency at scale.
To ensure the new system can handle real-world traffic loads, provision Vespa and Elasticsearch clusters with the same dataset and query set, then benchmark and stress test both. Depending on your scale, test at 10%, 25%, and 50% of production data. This includes:
Measuring search quality against a golden set of queries, using metrics such as top-K recall.
Baselining node, memory, and CPU use for each system on shared dashboards.
Measuring query throughput, indexing speed, and latency under high load.
Scaling up traffic in controlled increments to identify potential bottlenecks.
Optimizing system configurations to maximize efficiency and stability.
A shadow traffic approach should be employed before making any changes visible to users. This involves sending live queries simultaneously to existing and new search engines and comparing results in real-time. Shadow traffic allows engineers to:
Identify discrepancies in search behavior between the two systems.
Fine-tune ranking and indexing logic to ensure consistency.
Validate infrastructure performance before exposing users to the new system.
Once shadow testing confirms the system's technical stability, A/B testing should be used to evaluate search relevance. Users are gradually exposed to the new search engine in controlled experiments, allowing search teams to:
Measure user engagement, satisfaction, and relevance metrics.
Fine-tune ranking algorithms and query execution.
Iterate through multiple test cycles to match or exceed the previous system's quality.
After refining search quality and validating performance, the final migration should be a gradual switch rather than an immediate transition. Promote each release through development, staging, and production environments, and keep Elasticsearch running in parallel so you can roll back quickly. This ensures:
A fallback option remains available if any unforeseen issues arise.
Load balancing is adjusted to prevent system strain.
Search performance remains stable as traffic progressively shifts to the new search engine.
Monitoring continues at each step, so regressions are caught before more traffic moves.
A migration is a real project, and two challenges come up most often:
Learning curve: Vespa’s application packages, schemas, and rank profiles work differently from Elasticsearch, so teams need time to build operational understanding.
Self-hosting complexity: running Vespa yourself takes more effort if you need multi-tenancy, multi-node clusters, or dynamic scaling.
Two options reduce that risk. Vespa Cloud takes care of operations, scaling, and upgrades, and an experienced migration partner shortens the learning curve.
Migrating between technologies is never straightforward, but by following this structured, multi-phase migration process, organizations can mitigate risks, maintain search quality, and transition seamlessly to a new search platform without disrupting the user experience.
By replacing Elasticsearch with Vespa, Vinted halved its server count, improved search consistency, and dramatically reduced both search and indexing latency, enabling faster updates and seamless scaling. They describe their migration as a “roaring success.”
Customer story: Vinted replaced Elasticsearch with Vespa and halved its server count.
Customer story: Splore moved from Elasticsearch to Vespa with Searchplex to add hybrid search and cut search latency.
Podcast: Vespa Voice with Vinted on replacing Elasticsearch with Vespa.
Benchmark report: A reproducible performance comparison of Vespa and Elasticsearch for an e-commerce application with one million products.
Built for Change: Why Vespa Outpaces Elasticsearch in Modern AI and Search Workloads, a guide to the architectural differences.
Modernizing Enterprise Search, a manager’s guide to migrating from Elasticsearch to Vespa.
Scaling Smarter: Vespa’s Approach to High-Performance Data Management, an eBook on data storage, processing, and performance at scale.
The End of Overprovisioning: How Vespa Automates Growth Without Wasting Resources, an eBook on scaling without wasted infrastructure.
Searchplex audit and migration services.