Elias.Lundmark
May 19, 2021
visibility 6898
star star star star star star
(5 votes)

Search & Navigation Backend Migrations

Over the last couple of years, we have been hard at work upgrading the architecture and backend that power Search & Navigation (formerly known as FIND). The most recent development efforts have been on stabilizing the backend we refer to as “V3”, which is discussed in this blogpost. But as the number 3 in “V3” hints at, we have previous versions of our backend, which are still running. 

Some of the improvements that we have made in V3 have trickled down into the previous versions, but not all of them. This is mainly due to other sets of constrains within the legacy platforms, such as different public cloud providers and software versions. But of course, we want all our clients and partners to be able to take advantage of our latest and greatest innovations – so over the coming weeks and months we are going to be consolidating our backends to V3. 

Historically it has been quite an ordeal to migrate indexes between our backend versions as it required re-indexing of data from scratch. To make this a smoother journey, we have been creating migration tools that moves Search & Navigation indexes from one backend to another – data and all. 

What does this mean for you?

Hopefully nothing. Our goal is to make this migration as friction free as possible and at the same time ensure that everything continues to work as expected. The big constrain to accomplish that is ensuring data consistency, and as such have had to make the trade-off of not accepting write operations during an index migration (much like Smooth Deploy). This will prevent indexing from happening for the time period where an index is being migrated, and you may encounter errors stating that read-only mode is activated for your index. In this case, we recommend retrying the indexing job until it goes through. Based on the volume of write operations to our clusters and time to migrate, most users will not notice this migration. There are outliers to this, and in that case, we will be in touch with you to ensure a smooth migration. 

Even if we expect this migration to not affect users, we will be posting updates about this work on our status page for the sake of transparency. Since this work is expected to be going on for quite some time, we highly recommend that you subscribe to our status page to follow our progress. We also recommend that you update your client to the latest version available. 

 

P.S. in this blogpost we also mention the next generation of FIND. Not to worry, we are still working hard on this but have taken some detours along the way. More news to come during the second half of this year – EMVPs, keep your eyes and ears open!

Best regards,

Elias Lundmark

Product Manager at Optimizely

May 19, 2021

Comments

error Please login to comment.
Latest blogs
cms13-scan: A Deterministic CMS 13 Readiness Scanner

Every CMS 12 to CMS 13 upgrade I have looked at starts the same way. Someone opens the solution and starts hunting. A text search for the APIs

Adnan Zameer | Oct 12, 2026 |

Setting Up an Optimizely CMS 13 MCP Server Locally with Codex

Optimizely CMS 13 supports Model Context Protocol (MCP) , allowing AI tools such as Claude and Codex to interact with CMS content and metadata...

Mardy | Oct 12, 2026

Handling SixLabors.ImageSharp vulnerability warnings in Optimizely CMS 12 (unofficial)

UPDATED: Optimizely is officially working with SixLabors to find a solution, if possible; the work ID is CMS-57231. An official decision/announceme...

Cuong Nguyen Dinh | Oct 10, 2026

Optimizely CMS 12 on .NET 10: Fixing a Siteimprove TypeMismatchException

Recently, while upgrading an Optimizely CMS 12 solution from .NET 8 to .NET 10, we encountered a frustrating exception that initially looked like a...

Madhu | Oct 9, 2026 |