Migrating Off End-of-Life Elasticsearch Without Losing Detection Coverage
A multi-engineer team at AiRAT migrated a Tier-1 financial institution off end-of-life Elasticsearch 6.x, unifying seven independently-running log services onto OpenSearch under a single, searchable interface - solving a version problem and a licensing problem in one project.
What was at riskEvery day on an end-of-life version was a day the next Elasticsearch CVE would have had no patched upgrade path.
Does this match your situation?
Tick what sounds familiar. This is for you, not us — nothing is submitted.
Nothing ticked yet — read on, or skim the outcomes below.
What we were solving
Bank running self-hosted Elasticsearch 6.x since before Elastic's 2021 SSPL license change, now blocked from re-platforming under a resale-safe license, facing the wall that Elasticsearch 8.x cannot read 6.x-era indices directly.
- Elasticsearch 6.x had reached end of life - every future CVE advisory would ship with no patched version to upgrade to in place.
- Elastic's post-2021 licensing (SSPL / Elastic License) meant the bank's own downstream use across subsidiaries was no longer permitted without a new commercial agreement.
- Elasticsearch 8.x cannot read indices created under 6.x - a straight version bump was never actually available; every index needed a migration plan.
What we built
- Selected OpenSearch (Apache 2.0 fork) as the target platform to remove the licensing constraint permanently, not just the version constraint.
- Ran dual-write ingestion for six weeks: new events landed in both the legacy 6.x cluster and the new OpenSearch cluster while historical indices reindexed in the background.
- Replayed every detection rule and saved search against the new cluster and diffed alert volume before cutover to catch silent rule breakage.
Architecture notes for your engineers
- Blue/green alias switch moved query traffic to OpenSearch in a single atomic step, with instant rollback to the legacy cluster available for the first two weeks.
- Reindexing prioritised the hottest 30 days of data first so analysts had full recent-incident coverage from hour one of cutover.
What actually changed
- Security patching
- End of life - no patched version to upgrade to
- Actively maintained release line
- Licence
- SSPL / Elastic Licence, restricts service use
- Apache 2.0, no downstream restriction
- Upgrade path
- 8.x cannot read 6.x indices - blocked
- Standard supported upgrades
- Detection coverage
- Years of rules, provenance unclear
- Every rule replayed and volume-diffed
- Rollback
- None - a failed cutover means an outage
- Two-week alias rollback to the legacy cluster
The delivery arc
Catalogued every index, detection rule, and saved search, and mapped which downstream uses the existing licence actually prohibited.
Key results
- Zero detection rules lost across the cutover
- Licensing risk fully removed - no SSPL/Elastic License dependency remains
- Six-week dual-write window with a two-week rollback safety net
- Hottest 30 days of data fully queryable from hour one of cutover
What it was built on
Representative tools and patterns — exact vendors vary per client environment.
Search & indexing
Migration tooling
Validation
What we'd tell the next team
- A version migration and a licensing migration are two different projects wearing the same trenchcoat - plan them as one.
- Reindexing newest-data-first buys analysts real coverage immediately, even while older data is still catching up in the background.
- Detection-rule replay against the new cluster is non-negotiable - silent rule breakage is worse than an outage because nobody notices it happened.
Questions this engagement anticipated
Why migrate to OpenSearch instead of upgrading Elasticsearch in place?
Elasticsearch 8.x cannot read 6.x-era indices, so 'upgrade in place' was never actually available past a point - and Elastic's SSPL/Elastic License also restricted the bank's own downstream use. OpenSearch's Apache 2.0 license solved both problems in a single migration instead of two.
How were detection rules protected during the cutover?
Every rule and saved search was replayed against the new cluster and diffed against historical alert volume before the blue/green switch - so silent rule breakage was caught before analysts ever depended on it.
Go deeper on the thinking
This is one of several case studies on data engineering & legacy migrations.
See the rest of the cluster →Compare your situation to this case.
Bring your constraints - environment, timeline, and budget. We scope before we quote.