Magento Open Source Elasticsearch to OpenSearch migration

OpenSearch compatibility describes the search engine, not your Magento store. OpenSearch is a fork of Elasticsearch 7.10 and is wire-compatible with it. According to the OpenSearch FAQ, it can use indices created by Elasticsearch 6.0 through 7.10 and supports rolling upgrades from those versions. That background explains why the switch is plausible, but it does not decide how your catalog moves. Read it as a statement about the engine's protocol and data handling. Your store still needs its own evidence that Magento runs correctly on the new cluster, and that evidence comes from testing your configuration, modules and extensions on that cluster.

Wire compatibility does not mean Magento has been validated against every OpenSearch minor version. Adobe's system requirements for 2.4.9 and 2.4.8-p5 list OpenSearch 3, and Adobe supports only the combinations it lists. OpenSearch ships a new minor version about every eight weeks, with 3.8.0 released on August 4, 2026 and 3.9.0 on September 29, 2026. Before you build the cluster, check the requirements page for your exact target release and identify the OpenSearch 3 minor version Adobe lists. Provision and test that minor version, and treat a newer minor as untested until Adobe lists it or you have validated it yourself.

Magento's catalog indices are rebuilt through reindexing during the switch, so the open question is not whether data survives the move but whether the engine answers queries the same way. Reindexing produces new indices from the catalog database, which means the outcome depends on how the new engine analyzes text, scores matches and applies filters to the queries Magento sends. Differences in those areas can change which products appear and in what order. Before cutover, record current search results on the source engine for a representative set of queries, so you have a baseline to compare against. The relevance checks in a later section describe how to run that comparison.

Confirm three things before you commit to a date. First, the exact OpenSearch 3 minor version Adobe lists for your release, and whether your hosting platform offers it. Second, whether any installed extension or custom module queries Elasticsearch or OpenSearch directly, or depends on custom analyzers, synonyms or scoring tweaks, because those components need their own tests on the new engine. Third, whether Adobe's release notes or known-issue listings mention search behavior for your release line. Ask your implementation partner to document these answers in the written scope, so the test plan covers the engine version you actually run.

Before any Magento setting changes, the team needs a running OpenSearch 3 cluster that it controls, sized for the catalog and secured for production. Adobe's requirements for Magento Open Source 2.4.9 list OpenSearch 3 as the only supported search engine on the stack, so the cluster build is the first hard dependency of the migration. Confirm the exact OpenSearch 3 minor version against Adobe's system requirements for your target Magento release before you pick an install method, because Adobe supports only the combinations it lists. OpenSearch documents several installation routes: Docker, Helm, the OpenSearch Kubernetes Operator, tarball, RPM, Debian packages, an Ansible playbook and Windows. Choose by the platform your team already operates. If you run Kubernetes clusters you control, Helm or the Operator fit into existing GitOps and backup tooling. If you run virtual machines, the RPM or Debian packages with the Ansible playbook give repeatable node builds and a clear patch path. Docker suits development and staging parity more than long-lived production nodes unless your platform team already runs it at that level. Whichever route you pick, keep the same method in staging and production so that the search behavior you test is the behavior you ship. Security decisions must be made before go-live, not after the reindex. Plan TLS for both node-to-node and client traffic, and decide how Magento's search client will trust the certificate chain. Choose one Security plugin authentication backend, from SAML, OpenID Connect, Active Directory, LDAP, Kerberos or JSON Web Token, based on your identity provider. Define roles that limit the Magento application user to the index patterns it writes and reads, and keep administrative roles separate. Enable audit logs and decide where they are stored and who reviews them, since changes to catalog indexes are part of your change history. Read the Creating a cluster guidance in the OpenSearch documentation before you fix node counts, master-eligible roles and zones. That guidance is the reference for cluster design, and your design should be checked against it rather than copied from a generic example. Sizing and shard layout depend on catalog size, attribute count, query volume and the number of store views, so they cannot be set from a formula in this article. Measure index size, indexing time and search latency in a staging copy loaded with a production-sized catalog, then set primary shard counts and replicas from those results. Treat the staging measurements as the gate for the cutover plan. Record the cluster version, the install method, the TLS and authentication settings, and the role definitions in version control, so the production build can be reproduced and audited. Ask your OpenSearch partner or internal platform team to confirm how upgrades and security patches will be applied to this cluster after go-live, because the OpenSearch maintenance policy determines which versions still receive security fixes.

Storefront search should not be trusted until a full reindex has completed on every indexer. Changing the catalog search engine setting only tells Magento where to send queries. It does not move existing documents into OpenSearch, so the new cluster can be empty or partly populated after the switch. Run a full reindex with bin/magento indexer:reindex, then confirm with bin/magento indexer:status that every indexer reports Ready, including the catalog search full text indexer and the indexers that feed product and category data into it. Do not open the storefront search box to customers, or judge relevance, while any indexer is still invalid or working. Record the completion time and the indexer status output as evidence for the cutover file.

Once the reindex is complete, run the captured query baseline against staging, which should point at the new OpenSearch 3 cluster. For each query, compare the top results with the baseline from the Elasticsearch environment, and note any product that drops out of the first page or moves sharply. Check zero-result queries next, since a small change in analyzers or synonym handling can turn common searches into empty pages. Then test synonym behavior with a defined set of terms, facet counts and their filtering results, sort options such as relevance, price and newest, and autocomplete suggestions. Compare counts and orderings rather than relying on a visual check, and keep the raw output for each run so the same comparison can be repeated after fixes.

Relevance cannot be signed off by the engineering team alone. Build a list of merchandising-critical queries, such as brand names, best-selling product types, seasonal terms and high-value category searches, and assign a named owner to each group. Owners are usually merchandising or category managers who know what a correct result looks like. Each owner reviews the comparison for their queries and gives a written sign-off or raises issues. Log every difference in the tracker. A difference that breaks expected behavior becomes a defect with the query, the expected result, the observed result and a severity. A difference that the business accepts becomes an accepted change, with the owner's name, the reason and the date. Both types should be visible at the go or no-go review.

Custom search boosting, custom sort rules and any extension that sends engine-specific queries must be tested individually, because a general relevance pass can hide failures in them. Identify each module that changes search behavior, review its queries against OpenSearch, and run its scenarios on their own. Ask each extension vendor to confirm in writing which OpenSearch versions they support, and do not assume that support for Elasticsearch carries over. Adobe's system requirements for 2.4.9 list OpenSearch 3 and state that Adobe supports only the listed combinations, so a vendor that has not confirmed OpenSearch 3 support is an open risk for the upgrade. Record any unsupported extension as a blocker or a planned replacement before the cutover date is set.

Keep the previous Elasticsearch cluster, its indices and the store configuration that points at it intact until the OpenSearch 3 cluster has passed your acceptance checks. Before cutover, record the current catalog search engine value and the connection settings it uses, including host, port, index prefix and any authentication, in the runbook. With those values written down, switching back is a configuration change followed by a cache refresh and a reindex check, not a rebuild. Confirm that nobody decommissions, snapshots away, or resizes the old cluster during the acceptance window, and that its node health and disk usage are monitored like production. Also confirm that its indices still reflect the catalog as it stood at cutover.

Define the switch-back triggers before cutover and assign an owner to each. For this migration, the usual triggers are a full reindex that fails or does not finish in the planned window, relevance regressions on a list of critical queries, and sustained error rates from search in the web server and Magento system logs after cutover. Name who can call the rollback, who executes it, and who verifies the storefront afterward. The critical query list should come from your merchandisers and top search terms, not from a generic test set. Confirm the log sources and error patterns with your own platform team, since the thresholds that justify a rollback depend on your traffic and catalog.

Reverting the search setting is quick, but once the store has taken orders, the switch-back decision also belongs to the business. Any change made on the OpenSearch cluster during the window, such as new synonyms, stop words or boosting rules added by merchandisers, will not exist on the old engine unless someone reconciles it. Decide in advance whether those changes are re-entered by hand, exported and replayed, or accepted as lost, and who approves that choice. Also check whether any reindex run after cutover wrote catalog data that the old cluster now needs to reflect, and agree how long the old cluster stays in a state where a switch back remains safe.

A rollback also raises a release line question. Adobe's lifecycle policy lists August 11, 2026 as the end of regular support for 2.4.6, and May 31, 2027 for 2.4.7. If your store must return to an older 2.4.x line to restore search, the code, PHP, database, cache and search engine combination may no longer receive security patches. Confirm with Adobe which combinations remain supported on the old stack, since Adobe's requirements for both 2.4.8-p5 and 2.4.9 list OpenSearch 3. If the old stack is unsupported, record that as a documented risk with an approver and an expiry date, and plan the next upgrade so the exposure does not persist.