Migrations & Upgrades

Clusters accumulate reasons to move: an end-of-life version, a license decision, a mapping design that can't be fixed in place, a platform bill that stopped making sense. The move itself is where risk concentrates — search and observability are usually in the critical path of whatever runs on top of them.

We run these moves as engineering projects with rehearsals and rollback, not as weekend events.

What we handle

• Major-version upgrades — Elasticsearch and OpenSearch major versions, including the deprecation sweep beforehand (mappings, query syntax, client libraries, plugins) and the reindex work where wire compatibility won't carry you.
• Elasticsearch ↔ OpenSearch — moves in either direction, eyes open: feature parity checked against what you actually use (security model, kNN/vector search, SQL/PPL vs ES|QL, dashboards vs Kibana), client and tooling changes, and snapshot compatibility limits mapped before anything is promised.
• Self-managed ↔ managed — onto Elastic Cloud or Amazon OpenSearch Service when the operations load isn't worth it, or off them when cost or control says otherwise. Node sizing redone for the target, not copied.
• Reindex-based mapping overhauls — when the original mapping choices are the ceiling on performance or cost, we design the target schema, build alias-based cutover, and reindex without a write freeze.

How we de-risk it

• Inventory first — every index, template, pipeline, client, dashboard, and alert that touches the cluster, catalogued before planning starts.
• Rehearsed on real data — the migration runs against a restored snapshot in a staging environment before it runs anywhere that matters.
• Parallel run where stakes demand it — dual-write or dual-read with reconciliation, so cutover is a routing change you can undo, not a cliff.
• Defined rollback — every step has a documented way back, and the plan states the point after which rollback changes shape.

After the move

We don't disappear at cutover: the engagement includes the settle-in period — watching cluster behavior on the new platform, tuning what the rehearsal couldn't predict, and leaving your team with the runbook.