For Magento 2.4.8 the decision is made for you: OpenSearch is the supported search engine and Elasticsearch is deprecated. Magento 2.4.8 requires OpenSearch 2.x, optimized for 2.19, and version 2.4.8-p2 adds OpenSearch 3.x support. The Elasticsearch 8 modules still in the codebase carry deprecation notices, and Adobe recommends migrating to OpenSearch to keep receiving support and security updates. If you are on Elasticsearch, plan the move.
Search is not a place to run unsupported software. It is a core storefront function, and an unpatched search engine is both a performance risk and a security exposure. This guide covers exactly what changed in 2026, how to migrate from Elasticsearch to OpenSearch without downtime, how to size your nodes, and how to tune catalog search so results are fast and relevant.
What changed, and why Elasticsearch is out
Elasticsearch and OpenSearch share a common ancestor. OpenSearch was forked from Elasticsearch after Elastic changed its license, and the open-source community and major cloud providers standardized on OpenSearch. Adobe followed. Over the last few Magento releases, OpenSearch went from an option to the default to, in 2.4.8, the supported engine, while Elasticsearch support was deprecated.
The practical meaning for a merchant is simple. If you upgrade to Magento 2.4.8 and stay on Elasticsearch, you are running a deprecated module that will not receive the same support and security attention. The correct path is to migrate to OpenSearch as part of, or before, your 2.4.8 upgrade. This is one of the changes we flagged in the Magento 2.4.8 upgrade guide, and it is not optional for stores that want to stay supported.
OpenSearch versus Elasticsearch: the honest comparison
For a Magento store, the two engines are functionally very similar, because Magento’s search integration abstracts most of the difference. The distinctions that matter are support, licensing, and hosting.
| Factor | OpenSearch | Elasticsearch |
|---|---|---|
| Magento 2.4.8 support | Supported engine | Deprecated |
| License | Apache 2.0, open source | Elastic License, restricted |
| Cloud availability | AWS OpenSearch Service, self-host | Elastic Cloud, self-host |
| Magento integration | Native, current | Legacy modules, deprecated |
| Security updates | Ongoing for Magento | Winding down for Magento |
| Cost | No license fee | Depends on Elastic tier |
For a Magento merchant in 2026 the choice is not really a choice: OpenSearch is where support and updates live. Elasticsearch is only relevant as the thing you are migrating away from.
Migrating from Elasticsearch to OpenSearch without downtime
The migration is more routine than most teams expect, because Magento treats both engines through the same integration. The safe sequence:
- Stand up an OpenSearch cluster. Provision OpenSearch 2.x, matching or exceeding your current Elasticsearch capacity. On AWS this is OpenSearch Service; self-hosted is also fine.
- Point a staging environment at OpenSearch. Configure Magento’s search engine setting to OpenSearch on staging and run a full reindex.
- Verify search quality. Test your top search terms, facets, and category filtering against production behavior. Confirm nothing regressed.
- Reindex and cut over production. Because a fresh reindex is fast, a store of 10,000 products typically finishes reindexing in under 30 minutes, you can point production at OpenSearch and reindex during a low-traffic window.
- For very large catalogs, plan more time. A snapshot-and-restore migration for 100,000-plus products runs 1 to 4 hours including verification. Schedule accordingly and keep the old cluster available for rollback.
Because catalog search data is rebuilt from the Magento database by reindexing, the migration carries low data-loss risk: the source of truth is Magento, not the search cluster. That is what makes a clean cutover possible. Doing this as part of disciplined Magento development means testing on staging first and keeping the old engine ready until the new one is proven.
Sizing your OpenSearch nodes
Under-provisioning search is a common cause of slow category pages and search timeouts under load. Size to your catalog and traffic, not to a default.
A typical Magento store with around 10,000 products runs well on two m7g.medium.search nodes, roughly $100 a month for compute plus storage. Larger catalogs with 100,000 or more products need larger instances and more storage, and high-traffic stores benefit from more nodes for redundancy and throughput. Two nodes rather than one also gives you resilience: if a node fails, search stays up.
The signals that you are under-provisioned: search latency climbing under peak traffic, reindex times growing, or CPU and memory pressure alerts on the cluster. If you see those, scale up before they become storefront outages.
Tuning catalog search for relevance
A supported, well-sized engine still needs tuning to return good results. Magento gives you several levers.
- Search weight on attributes. Boost the attributes that matter, product name and SKU, above less important ones, so the right products rank first.
- Synonyms. Add synonyms for the terms shoppers actually type, including nicknames, abbreviations, and common misspellings, so a search never dead-ends.
- Stop words and minimum term frequency. Tune these so common words do not dilute results and rare product terms still match.
- Facets and filters. Configure filterable attributes so shoppers can narrow large result sets quickly, which matters more the bigger your catalog.
- Zero-result monitoring. Review searches that return nothing and fix them with synonyms or catalog changes. Every zero-result search is a lost sale you can recover.
Tuning is ongoing, not a one-time setup. Review search analytics regularly, because your catalog and the language shoppers use both change over time. A synonym list that was complete last year will have gaps this year as you add new products and shoppers adopt new terms, so treat search relevance as a living configuration rather than a task you close.
Self-managed OpenSearch versus AWS OpenSearch Service
Once you commit to OpenSearch, the next decision is where it runs. The two common paths are a self-managed cluster on your own servers and the managed AWS OpenSearch Service.
Self-managed gives you full control over configuration and version timing, and can be cheaper at small scale if you already run the infrastructure. The cost is operational: you patch it, monitor it, scale it, and handle failover yourself. For a lean team that is real ongoing work.
AWS OpenSearch Service hands the operational burden to AWS. You choose instance types and node counts, and AWS handles patching, snapshots, and much of the failover. It costs more per hour than raw compute, but it removes a class of work that otherwise lands on your engineers at the worst possible moment, usually during a traffic spike. For most mid-market Adobe Commerce merchants, the managed service is the pragmatic choice, because search uptime matters more than saving a few dollars on compute.
Whichever you pick, keep the search cluster in the same region and close to your Magento application to minimize latency, and never expose it to the public internet without proper access controls.
Common search problems after migration
A few issues surface after an OpenSearch cutover, and all are fixable.
The first is stale results, usually a reindex that did not complete or an indexer stuck in “invalid” status. Check indexer status and run a full reindex to clear it.
The second is missing products from search or category pages, often an attribute that is not set as searchable or a visibility setting that changed. Confirm your searchable attributes and product visibility.
The third is slow search under load, which points back to node sizing. If search was fine in testing but slow in production, the cluster is likely under-provisioned for real traffic, and the fix is to scale the nodes rather than to blame the engine.
Catching these in staging is far cheaper than catching them in production, which is why the migration sequence puts verification before cutover.
When to consider Live Search instead
If you are on Adobe Commerce rather than Magento Open Source, you have a third option: Adobe Live Search, the SaaS engine that replaces the self-hosted cluster entirely. It removes the node-sizing and tuning burden in exchange for an Adobe Commerce license and less customization control. For Open Source stores, OpenSearch is the path. For Adobe Commerce stores that would rather not run a cluster, Live Search is worth evaluating against the OpenSearch route, weighing customization needs against operational simplicity.
Frequently asked questions
Does Magento 2.4.8 support Elasticsearch?
The Elasticsearch 8 modules are still in the 2.4.8 codebase but carry deprecation notices. OpenSearch is the supported engine. Adobe recommends migrating to OpenSearch to keep receiving support and security updates, so plan the move as part of your upgrade.
Which OpenSearch version does Magento 2.4.8 need?
Magento 2.4.8 requires OpenSearch 2.x and is optimized for 2.19. Version 2.4.8-p2 adds support for OpenSearch 3.x. Match your cluster to the version your specific patch level supports.
How long does an Elasticsearch to OpenSearch migration take?
A fresh reindex is fast, a 10,000-product store usually finishes in under 30 minutes. Very large catalogs of 100,000-plus products using snapshot and restore take 1 to 4 hours including verification. The engine data is rebuilt from Magento, so downtime can be minimized.
Will migrating to OpenSearch change my search results?
Not materially, because Magento drives relevance through its own configuration, which carries over. You should still test your top search terms and facets on staging before cutover to confirm nothing regressed in your specific setup.
How many OpenSearch nodes do I need?
A store around 10,000 products runs well on two m7g.medium.search nodes. Larger catalogs and higher traffic need bigger instances and more nodes. Two nodes minimum is wise for resilience, so search stays up if one node fails.
Where this fits
In 2026 the Magento search question is settled: OpenSearch is the supported engine, Elasticsearch is on its way out, and the work is to migrate cleanly, size the cluster correctly, and tune relevance on an ongoing basis. Treat it as core infrastructure, not an afterthought, and search stays fast and reliable through your 2.4.8 upgrade and beyond.
Bemeir is the first US-based Hyva partner and a full Adobe Commerce agency, with a deep technology partner ecosystem across hosting, search, and infrastructure. We handle OpenSearch migrations, node sizing, and search tuning as part of Hyva and Magento builds, and we also work across Shopify, Shopware, and BigCommerce. Read more about Bemeir and how we manage Magento infrastructure.
External references: a guide to Magento OpenSearch and Elasticsearch setup and migration, a walkthrough of migrating Elasticsearch to OpenSearch on Adobe Commerce, and a reference on why Magento 2.4 requires a search engine.
