Knowing what actually breaks before you commit to the migration

Overview

A digital media platform wanted to move off a licensed Elasticsearch distribution to OpenSearch, but the estate had grown organically and nobody had a clear picture of which features were actually in use. AceMQ assessed feasibility, effort, and risk before any migration work started.

Challenge

The application estate used a mix of official Elasticsearch clients across several languages, and the newer client versions include a product check that refuses to talk to OpenSearch. Several teams had also built on features that diverge between the two projects, including specific machine learning jobs and a licensed alerting configuration. Without an inventory, the migration effort estimate was pure guesswork.

Environment

Elasticsearch clusters on AWS serving content search and log analytics, applications in Java, Python, and Node.js.

Approach

The assessment inventories every client library, plugin, index mapping feature, and query construct in use, then classifies each as compatible, requiring a client swap, or requiring redesign. We test the ambiguous cases against a real OpenSearch cluster rather than relying on compatibility matrices, and produce a phased migration plan with effort attached to each phase.

Solution

• Client library inventory across all application languages, flagging versions that will fail the product check
• Plugin and feature usage inventory covering alerting, anomaly detection, and any licensed-tier functionality in active use
• Query and mapping constructs tested against a live OpenSearch cluster to confirm behavior rather than assume it
• Index and snapshot compatibility path documented, including which snapshots can be restored directly and which need reindexing
• Phased migration plan with a dual-write or reindex strategy per workload and rollback criteria at each phase
• Cost and licensing comparison based on the customer's actual node counts and data volumes

Outcome

Technologies