{"id":345,"date":"2026-06-05T18:42:39","date_gmt":"2026-06-05T15:42:39","guid":{"rendered":"https:\/\/blog.twis7.com\/?p=345"},"modified":"2026-06-19T10:49:18","modified_gmt":"2026-06-19T07:49:18","slug":"upgrade-elasticsearch-6-8-to-aws-opensearch-3-5-with-minimum-downtime","status":"publish","type":"post","link":"https:\/\/blog.twis7.com\/index.php\/2026\/06\/05\/upgrade-elasticsearch-6-8-to-aws-opensearch-3-5-with-minimum-downtime\/","title":{"rendered":"Upgrade ElasticSearch 6.8 to AWS OpenSearch 3.5 with minimum downtime"},"content":{"rendered":"
\n
\"\"<\/figure>\n<\/div>\n\n\n

The moment I received this image in a private Teams chat, I knew it would be a challenge… Not the dance. The migration \ud83d\ude41<\/p>\n\n\n\n

The product depended on a stable Elasticsearch cluster. Uptime had to remain at 100%, and no data could be lost. If the deployment failed, a single misclick could jeopardize the 99.99% SLA commitments we had signed with our partners.<\/p>\n\n\n\n

Manually repopulating the data – 26 million records – would have taken an enormous amount of time. Twelve or thirteen hours, perhaps even longer.<\/p>\n\n\n\n

The pressure was high. Fortunately, thanks to thorough preparation, detailed documentation, and extensive testing in environments that closely mirrored production, I completed the migration with only 30 seconds of downtime.<\/p>\n\n\n\n

Could I have achieved zero downtime? Yes. However, doing so would have increased the risk of data loss. Given the trade-off, 30 seconds of downtime was an acceptable and responsible decision.<\/p>\n\n\n\n\n\n\n\n

Migration Assistant for OpenSearch<\/h2>\n\n\n\n

I found a great tool that could handle the migration. It promised near-zero downtime and supported migrations from Elasticsearch 6.8 to OpenSearch 3.5. The tool was well documented, and the team behind it had even created a series of video tutorials explaining how to use it. Most importantly, deployment was automated via Cloudformation.At the time of writing, the creators of the tool recommend using EKS (Kubernetes) as the preferred migration platform. ECS way is expected to be deprecated soon. However, I used ECS anyway, as I didn\u2019t have time to experiment with EKS. EKS way was not an option when I found the tool. For reference, I have included all the documentation and resources that I used throughout the migration process.<\/p>\n\n\n\n