Problem:
Migrating a complex application from Elasticsearch 7.x to Opensearch 3.x creates a chicken-and-egg problem in that you cannot upgrade only the server side first (es client won’t talk to os), or the client side (os3 client won’t work with es7).
Our solution:
A client of mine was stuck with ES 7.10.2 due to the license changes. After the AGPL release they bumped to latest 7.x, but really wanted to jump to Opensearch.
The switch to Opensearch got complicated by the deprecation of RestHighLevelClient both en ES and OS. So in addition to upgrading the server side they also had to upgrade multiple client applications, and do it all in a big bang. Which is not very attractive as we’d need to maintain two versions of our applications during trasition phase.
To make it possible to do a phased migration, I developed a thin proxy application using nginx. Your client application will connect to the proxy, and they will see an elasticsearch 7.10.2 (spoofed status response, type info and headers). The proxy will connect to Opensearch (removing type information, translating headers etc).
We have now upgraded our backends to Opensearch 3.x, and started phase 2 of the migration which is to replace use of RestHighLevelClient in our applications with opensearch-java. We can even have some parts of a single application talking directly to OS while other parts go through the proxy. Once all our applications are migrated, we’ll throw out the proxy.
I open-sourced it here https://github.com/janhoy/esos-proxy so go read about it if you believe it may help your use case as well.
PS: This proxy only attempts to handle the search / indexing use case, and it is also verified for simple index creation. I’m sure there are APIs that this proxy won’t handle at all, YMMW.
PPS: We migrated the indexes by either re-indexing or using _reindex API with remote support, i.e. OS slurping an index from the remote ES cluster.