OpenSearch Consulting & Support

OpenSearch Consulting & Support for Enterprises

AceMQ engineers operate OpenSearch clusters across AWS OpenSearch Service, OpenSearch Serverless, and self-managed deployments. We've handled the Elasticsearch 7.10 fork migration path directly and know exactly where client compatibility and security plugin behavior diverge from upstream Elastic.

A senior engineer, not an SDR. No sales sequence attached.

Senior SMEs
11+
Emergency SLA
<15min
Customers
160+
Countries Served
26+

Without going back to Elastic or rebuilding your indices from sourceFor production incident cover, see AceMQ OpenSearch 24/7 support.

Customers

  • Microsoft
  • Henry Schein
  • Enbridge
  • Gojek

Partners

  • Broadcom
  • Redis
  • VMware Tanzu
  • OSSeva

The Problem

Why teams call us about OpenSearch

Eight OpenSearch problems that teams bring to AceMQ, from Elasticsearch clients that fail after a migration and blue/green domain updates that stall to security role mappings that do not carry over and ISM policies that stop rolling over. If one describes your week, that is where the review starts.

  1. 01

    Clients written for Elasticsearch fail against OpenSearch after the version handshake changed

  2. 02

    Security plugin roles and index patterns do not map cleanly onto what the old cluster granted

  3. 03

    The managed domain hit a shard or storage limit that a self-managed cluster never enforced

  4. 04

    ISM policies roll indices over at a size that no longer matches the ingest rate

  5. 05

    Blue/green domain updates take hours and the cluster is degraded for all of them

  6. 06

    Saved objects and dashboards did not survive the move from Kibana intact

  7. 07

    Serverless collection cost moves with query volume in a way nobody forecast

  8. 08

    The fork has drifted far enough that upstream Elastic advice no longer applies and there is no in-house owner

A good fit if you run OpenSearch in production for search, logs or audit data, on AWS or your own infrastructure, and want senior engineers who know where it differs from Elasticsearch.

Not a fit for small teams with non-critical workloads. AceMQ is not a budget consultancy: we work with enterprises running business-critical and compliance-heavy OpenSearch.

Running OpenSearch in production? Get a quote from a senior engineer, answered within one hour.

Contact Us

How it breaks, and the fix

What happens to an OpenSearch cluster when a data node is lost?

When a data node leaves an OpenSearch cluster, its shards turn unassigned and the cluster goes yellow or red. On Amazon OpenSearch Service you cannot log in to the node, so you diagnose through the allocation explain API and CloudWatch, and the fix may be a change that starts a blue/green deployment.

One lost node, shards unassigned

Three data nodes, one coordinating node, one index with a replica per shard

Illustrative

  1. Primaries and replicas sit on different nodes and the cluster is green. Each data node carries about half its capacity.

  2. data-2 is lost. Its shards turn unassigned and the cluster goes yellow, or red where no other copy existed. data-1 and data-3 take the load and run hot, and Dashboards panels that were fine start to time out.

  3. The blocker found with the allocation explain API is cleared and the replicas are re-allocated. Shards recover, the cluster is green and the load levels out.

Unassigned shards after a node loss is the incident AceMQ sees most on OpenSearch. Disk watermarks, zone awareness and replica settings decide whether the cluster can heal itself. On Amazon OpenSearch Service the remedy is often a configuration change that starts a blue/green deployment, which stalls when shard counts are high or free storage is low. AceMQ sizes shards and storage so a cluster can lose a node and recover without help.

Our Services

OpenSearch Consulting & Services

AceMQ runs five OpenSearch service lines: architecture and implementation, performance tuning, migration, managed operations and health checks. A senior engineer leads each one, and any of them can roll into 24/7 support with a 15-minute emergency SLA.

  • 01

    OpenSearch Architecture & Implementation

    We design cluster and index architecture for OpenSearch specifically — not a copy-pasted Elasticsearch runbook — accounting for how ISM, the Security plugin, and OpenSearch Dashboards actually behave.

    • Cluster and shard architecture design for AWS OpenSearch Service, self-managed, or OpenSearch Serverless
    • Index State Management (ISM) policy design for automated lifecycle transitions
    • Security plugin configuration: fine-grained access control, role mapping, tenant isolation
    • OpenSearch Dashboards setup and visualization architecture
  • 02

    Performance Tuning & Optimization

    Hot nodes, ingest-heavy workloads, and slow aggregations show up differently on OpenSearch than on Elasticsearch — we tune against the platform you're actually running.

    • Shard sizing and rebalancing to eliminate hot nodes and long GC pauses
    • Query and aggregation profiling using slow logs and Query Insights
    • JVM heap and circuit breaker tuning for ingest-heavy workloads
    • Bulk indexing throughput tuning: refresh interval, replica placement, segment merge policy
  • 03

    OpenSearch Migration & Modernization

    Most OpenSearch migrations start from Elasticsearch 7.10.x, the last Apache 2.0 licensed release before the fork. We've mapped the client compatibility gaps and know which plugins don't carry over cleanly.

    • Elasticsearch 7.10.x to OpenSearch migration, including client library compatibility assessment
    • Self-managed cluster to AWS OpenSearch Service migration and domain sizing
    • Solr or legacy ELK stack to OpenSearch migration
    • Reindex-from-remote cutover with alias-based zero-downtime swap
  • 04

    Managed OpenSearch Operations

    Ongoing operational coverage with a specific focus on AWS OpenSearch Service cost control, since domain sizing decisions made at launch tend to compound quietly on the monthly bill.

    • 24/7 domain and cluster monitoring: shard allocation, JVM pressure, disk watermark
    • AWS OpenSearch Service cost optimization: instance sizing, UltraWarm and cold storage tiering, reserved instance planning
    • Cross-region snapshot and disaster recovery automation
    • Version upgrade planning across OpenSearch releases and plugin compatibility
  • 05

    OpenSearch Health Check & Assessment

    A structured audit covering cluster health, security plugin configuration, and — where relevant — AWS domain cost, delivered as a prioritized action list, not a scorecard.

    • Cluster health audit: shard allocation, replication factor, node role balance
    • Security plugin audit: role mappings, tenant isolation, audit logging configuration
    • AWS OpenSearch Service cost and rightsizing review
    • Written remediation report with findings ranked by production risk
  • 15 MIN SLA

    24/7 OpenSearch Support

    Named senior engineers on your account — 15-minute emergency response, no ticket routing, no junior triage.

    • 15-minute emergency response SLA
    • Named engineer, zero cold-start
    • Proactive CVE & health monitoring
    • Quarterly deployment reviews
    Compare the four OpenSearch support tiers

Want AceMQ to take this off your team's plate? Tell us about your OpenSearch estate.

Contact Us

24/7 Support

OpenSearch Support When It Matters Most

AceMQ OpenSearch support gives you named senior engineers and a 15-minute first response when a cluster or domain degrades, 24/7. Lower severities get 1-hour, 4-hour and next-day responses. The same tiers apply to self-managed OpenSearch and Amazon OpenSearch Service.

  1. 15 minfirst responseEmergencyProduction down, messages not flowing, queue manager failure
  2. 1 hourfirst responseCriticalSevere degradation, high error rates, approaching capacity
  3. 4 hoursfirst responseHighPerformance issues, configuration problems, non-critical failures
  4. Next Dayfirst responseStandardQuestions, guidance, best practices, non-urgent improvements

P1 escalation path

A replay of one P1, from the first page to the written root-cause analysis

SLA 15:00
T+Elapsed15:00
Engineer on your bridge

15-minute P1 response, 24/7.
A response time, not a resolution time.

  1. T+00:00

    P1 opened, on-call engineer paged

    Phone, email or Slack reaches the on-call senior engineer directly, whether the incident is in RabbitMQ, Kafka, Redis, PostgreSQL or Kubernetes. No web form, no tier-1 queue.

    Paged
  2. T+15:00

    Senior engineer on your bridge

    A senior engineer who already knows your environment joins a live bridge, so nobody has to re-explain your topology.

    Live
  3. T+30:00

    Specialists across the stack join

    When an incident crosses components, the engineers who know each one join. For RabbitMQ, the path runs to the core team.

    If needed
  4. After

    Written root-cause analysis

    Root cause, the fix applied and the prevention steps, delivered after every P1.

    Every P1

How Our Support Actually Works

Beyond SLAs — the model behind senior-only, zero-cold-start expert access.

  • Named Engineers on Your Account

    Every ticket is handled by a senior SME assigned to your account — not a pool of anonymous agents. Zero cold-start. No re-explaining your environment.

  • Live Escalation on Any Ticket

    Any ticket can be escalated to a live session with your named engineer via calendar booking. No gatekeeping, no approval required — direct access, always.

  • Proactive Risk Mitigation

    Quarterly health checks on your deployment plus shared intelligence from 50+ support customers — we surface risks before they reach production.

  • Critical Bug & CVE Intelligence

    Proactive alerts on critical bugs and CVEs affecting your exact version, with version compliance monitoring so you're never caught off guard.

  • Commercial EOL Versions

    Commercial support for end-of-life OpenSearch versions, with security fixes backported through OSSeva, so the upgrade happens on your schedule rather than the community's.

Compare OpenSearch support plans

How It Works

What actually happens next

An AceMQ OpenSearch engagement runs in four stages: a domain and index review of 1 to 2 weeks, written findings within a week, changes made behind aliases with your engineers, then a handover with runbooks. Each stage ends in writing before anything changes.

1–2 weeks

Domain and index review

We look at shard layout against instance sizing, ISM policies against real ingest and retention, security plugin roles and tenant mapping, and client compatibility across each application that talks to the cluster.

Within a week

Written findings and plan

What is a genuine OpenSearch-versus-Elasticsearch divergence, what is simply a sizing problem, and what to change first. Sized for your own engineering leadership to sign off.

Scoped per engagement

Implementation alongside your team

Index template and mapping changes applied behind aliases, domain updates scheduled with the blue/green behaviour understood in advance, client upgrades staged application by application.

Ongoing

Handover and optional cover

Runbooks for domain updates, snapshot restore and security role changes, plus 24/7 support with a 15-minute emergency SLA if you want it.

  • Written findings before any change
  • Index and domain changes staged behind aliases
  • Your engineers in the room
  • You keep the runbooks
  • Ad hoc engagements or an annual partnership

A senior engineer, not an SDR. No sales sequence attached.

Customer Success

Real OpenSearch Results

OpenSearch work from AceMQ, from snapshot restore recovery and regulated cluster support to multi-tenant design and an Elasticsearch migration assessment. Each card links to the full write-up: the environment, what AceMQ assessed or changed, and the result.

1 / 4 case studies

  • Remediation

    OpenSearch Snapshot Restore Failure Remediation

    Insurance Services Provider

    Emergency recovery of an OpenSearch domain where snapshot restores were failing partway through and leaving indices in a red state.

    OpenSearchAmazon S3OpenSearch DashboardsLinux
    Read case study : OpenSearch Snapshot Restore Failure Remediation
  • Assessment

    Elasticsearch to OpenSearch Migration Assessment

    Digital Media Platform

    Assessment of the technical and licensing implications of moving a large Elasticsearch estate to OpenSearch, including client and plugin compatibility.

    OpenSearchElasticsearchAmazon S3Terraform
    Read case study : Elasticsearch to OpenSearch Migration Assessment
  • Consulting

    OpenSearch Multi-Tenant Search Architecture Design

    B2B SaaS Platform Provider

    Consulting engagement to design tenant isolation, index strategy, and query governance for OpenSearch serving thousands of customer tenants.

    OpenSearchKubernetesOpenSearch DashboardsTerraform
    Read case study : OpenSearch Multi-Tenant Search Architecture Design
All use cases

Solutions

Every way AceMQ works with OpenSearch.

AceMQ covers OpenSearch end to end: cluster consulting and Elasticsearch migrations, 24/7 support and incident management, proactive monitoring, managed clusters and domains on your infrastructure or on AceMQ's, and a fixed-price health check.

Projects

Build, fix or move OpenSearch

Fixed-scope work led by a senior engineer: architecture and new builds, a health check of what you run today, or a migration with a reversible cutover.

Support and managed services

Keep OpenSearch running

Four tiers of ongoing cover once you are live. Each tier hands more of the day-to-day work to AceMQ, from a 15-minute emergency SLA to AceMQ hosting and running OpenSearch for you.

Compare the four OpenSearch support tiers

Side by side

OpenSearch or Elasticsearch, and where should it run?

OpenSearch is the Apache 2.0 fork of Elasticsearch 7.10.2. It can run self-managed or on Amazon OpenSearch Service, while Elasticsearch stays the choice for teams that rely on Elastic's features. AceMQ supports all three routes, and each row below answers one question about the choice.

Self-managed OpenSearch, Amazon OpenSearch Service and Elasticsearch compared on licence, node operations, clients, security, versions and AceMQ cover
QuestionOpenSearch (self-managed)Amazon OpenSearch ServiceElasticsearch (self-managed or Elastic Cloud)
What licence applies?Apache 2.0 for OpenSearch and OpenSearch Dashboards, governed by the OpenSearch Software Foundation.The software is Apache 2.0 OpenSearch. AWS bills for running it as a service.Source under AGPLv3, SSPL 1.0 or the Elastic License 2.0. Elastic's default binaries use the Elastic License 2.0.
Who runs the nodes?You, or AceMQ under managed operations.AWS runs the domain, patching and node replacement. You cannot log in to a node.You, AceMQ, or Elastic on Elastic Cloud.
Which clients connect?The OpenSearch clients. Elasticsearch clients from 7.14 onwards refuse to connect.The OpenSearch clients, with requests authenticated through IAM or fine-grained access control users.Elastic's own clients, which check that they are talking to Elasticsearch.
How does security work?The Security plugin: roles, tenants, field- and document-level security and audit logging, all free.Fine-grained access control with role mappings and IAM, SAML or Cognito sign-in.TLS and role-based access control are free. Field- and document-level security needs a paid subscription.
How are versions and upgrades handled?3.x is current, 2.x is maintained until 4.0 ships, and 1.x reached end of life on 6 May 2025. Rolling upgrades work within a major version.An upgrade is a blue/green deployment started from the console. How long it takes depends on shard count and free storage.7.17 is out of support, 8.x maintenance ends on 15 January 2027, and 9.x is current.
What does AceMQ add?24/7 support for 1.x, 2.x and 3.x, the Security plugin, ISM and Dashboards.Support for what AWS support does not take on: shard design, mappings, queries, ISM, access control and cost.24/7 support on the same terms, and the migration to OpenSearch when it is the right call.

For the full side-by-side, read OpenSearch vs Elasticsearch compared. If you are moving off Elasticsearch, follow the Elasticsearch to OpenSearch migration guide.

Not sure which option fits? A senior OpenSearch engineer will scope it with you.

Contact Us

One partner, not five

We Support Your Entire Tech Stack

OpenSearch rarely fails in isolation. AceMQ covers the full surrounding infrastructure — so one team owns the whole path instead of pointing at each other.

Messaging & Streaming

Databases & Caching

Search & Analytics

Lakehouse & Compute

Observability & Monitoring

Data Integration

Cloud & Containers

API Management

VMware Tanzu

See all 51 technologies we supportShow fewer

Guides, articles and comparisons

Go deeper on OpenSearch.

Guides from AceMQ engineers on moving from Elasticsearch to OpenSearch, comparing the two, and who supports OpenSearch, plus the AceMQ services for the search tools that usually sit next to it.

Related services

Ready to talk OpenSearch? Get a quote or send us a message.

Contact Us

FAQs

OpenSearch Questions Answered

Seven answers on OpenSearch from AceMQ: supported and end-of-life versions, who answers when a cluster fails, how an engagement starts, working with your team, Elasticsearch client errors, stalled blue/green deployments and where to run it.

Still have questions about OpenSearch? Email an Expert

Which OpenSearch versions are supported, and is 1.x still safe to run?

OpenSearch 3.x is the current line, 2.x is in maintenance until 4.0 is released, and 1.x reached end of life on 6 May 2025, so it gets no more upstream fixes. AceMQ supports 1.x, 2.x and 3.x clusters 24/7 and plans the upgrade path from 1.x through 2.x to 3.x, rehearsed on a restored snapshot first.

Who answers when an OpenSearch cluster or domain fails, and how fast?

A named AceMQ senior engineer answers within 15 minutes, 24/7, when a cluster is red, a blue/green deployment is stuck or Dashboards is down. Lower severities get a first response within 1 hour, 4 hours or the next business day. You get a written root-cause analysis after every P1.

How does an OpenSearch engagement with AceMQ start?

It starts with a free consultation with a senior engineer, booked in our reply within 1 hour. A domain and index review of 1 to 2 weeks follows, covering shard layout, ISM policies, security roles and client compatibility. Written findings and a plan arrive within a week, and nothing in the cluster changes before you have read them.

Can an AceMQ engineer work alongside our in-house team?

Yes. A named senior engineer works with your engineers rather than around them, changing index templates, ISM policies and role mappings together. Domain updates are scheduled with the blue/green behaviour understood in advance, client upgrades are staged application by application, and you keep the runbooks when the work ends.

Why do our Elasticsearch clients fail against OpenSearch?

Elasticsearch clients check the server's version and, from 7.14, its product, so they refuse OpenSearch. The compatibility.override_main_response_version setting makes OpenSearch report 7.10.2 and unblocks older clients, but it is only a bridge. The lasting fix is moving each application to the OpenSearch client libraries, which AceMQ stages one application at a time.

Our Amazon OpenSearch Service domain is stuck in a blue/green deployment. Why?

Several changes, including instance type, EBS volume, node count and some advanced settings, force a full blue/green migration. It stalls when there are too many shards, too little free storage or a red index, and the domain runs degraded meanwhile. AceMQ finds the trigger, clears the blocker and rehearses the next change on a restored snapshot.

Should we run OpenSearch ourselves or on Amazon OpenSearch Service?

Amazon OpenSearch Service removes node patching and replacement, at the cost of storage ceilings by instance family, no node access and blue/green updates. Self-managed gives full control and runs anywhere, including on premises and air-gapped. Shard design, mappings and query cost need an owner on both routes, and AceMQ supports both.

Can we work with AceMQ on OpenSearch without a long contract?

Yes. AceMQ works on OpenSearch in two ways: ad hoc engagements for a defined piece of work, such as a health check, an upgrade or an incident, or an annual partner engagement that covers 24/7 support, proactive reviews and named engineers. Many teams start ad hoc and move to an annual partnership once the first engagement is done.

How much does AceMQ OpenSearch support or consulting cost?

Every AceMQ proposal is tailored to your requirements: your OpenSearch environment, the SLA you need, the hours of cover and the scope of work. Most contracts run $24,000–72,000 a year, depending on the SLA, the scope and how OpenSearch is deployed, with aggressive discounts when several technologies share one contract. Request a quote and AceMQ replies within 1 hour.

Let's talk

Ready to Stabilize Your OpenSearch Cluster?

Whether you need emergency support, a health check, a migration partner, or ongoing managed operations — AceMQ staffs every engagement with a named senior OpenSearch engineer. Quote requests answered within 1 hour.

A senior OpenSearch engineer, not a sales queueAbout your cluster or domain, not a pitch deckQuote requests answered within 1 hour

Production incident right now?Email an OpenSearch Architect

Get in Touch

Talk to an OpenSearch Expert

Send us a message and we'll follow up within 1 hour — or book a free 30-min consultation directly.

305-204-2607
info@acemq.com
66 W. Flagler St. 9th Floor
Miami, FL 33130

Prefer to talk now? Call us directly or use the consultation tab to find a time that works.

We respond within 1 hour.

Pick a time that works — no pressure, no pitch. Just 30 minutes with an expert.

We respond within 1 hour.