Cookpad is the largest recipe sharing platform in the world. Our mission is to make everyday cooking fun, and central to that is our search product. Our search engine helps cooks everywhere find tasty dishes to cook within our ever-growing catalogue of five million recipes created by everyday cooks. As a global recipe search – available in 70+ countries, 30+ languages, and to over 40 million monthly users – delivering this is no small feat. In order to prepare for a substantial new iteration of our search product, we realised that our existing legacy search system was not suited to our goals. We embarked on a transition to a new system, along with new team structures and team composition. Over two years we delivered a new system, without halting product development along the way, and without disruption to the user experience. Our starting point was a team and system with capacity limited to legacy system maintenance and bug fixes, where relevance enhancement was delivered through incremental knowledge base tuning by SMEs (non-engineer subject matter experts). Our end point was multiple search teams who have direct ownership over the search experience and relevance enhancement, supported by SMEs, and following rigorously tested data-driven experimentation. This change involved transition to a new event-driven architecture, along with technologies that were new to Cookpad search, such as Kubernetes, Kafka, Python, Elasticsearch, and machine learning. In addition – and just as importantly – it also involved a transformation in team structures and team composition, for which we borrowed many concepts and practices learned from the search community and the Team Topologies movement. This talk will cover our journey, why we did it, as well as the trials, tribulations, successes along the way. Hopefully, it will give others ideas on how to reinvent their own search system and search function, while minimising disruption to product delivery, in order to move faster.