At the beginning of 2019, we decided to update the corporate Kyivstar website. We worked with an agency that maintained it and used Drupal as a CMS back then. We decided to move the production in-house and gathered a team of developers who would work on this project. Their stack is Java, React Native, and React, and we needed a CMS that would match it. Since Drupal is PHP-based, it didn’t work for us.

We were looking for a React-friendly CMS. I selected 12 options and compared them using SWAT analysis. I chose Strapi because it has a big community, can be deployed locally, and allows us to be independent of cloud solutions, one of the security criteria. We can also customize it however we want and build on top of it, making Strapi a powerful page-builder tool.

It had several drawbacks as well. For example, there was no internationalization back then, but we spoke to the Strapi team and learned that it was already in progress, so we decided to wait. We also needed custom fields to link to maps, audit logs, and see who changed the content and when. Strapi team suggested workarounds that solved these problems.

Last September, we launched a production website built on Strapi. The old website had nearly 6000 pages. In 9 months, we migrated from Drupal to Strapi about 1000 pages, accounting for 80% of the traffic. We kept an old Drupal-based website with nearly 5000 less important pages targeting specific audiences or containing regulatory information.

To make both stacks work together, we created a proxy setting collection type in Strapi, where we added the URLs we needed to redirect the user. This way, the links stayed the same, but we could control whether the page that opens is the new one based on Strapi or the old Drupal-based one. Once we create a new page on Strapi, we turn this redirection off, so users are no longer sent to the old page. This way, content managers control proxy settings using the Strapi admin panel. For us, it’s not only a CMS but a configuration system.

We also have a personal cabinet feature that allows users to purchase and manage services on the website. Before it was built using many legacy CMSs, including custom ones, but now we’re migrating everything to Strapi.

We do! It was important to let our content team easily edit the content on the mobile app. It was not possible before, as a lot of content was stored in the code or configuration files. We needed to wait for nearly two weeks and involve at least three people to make a simple change. Now one person can do it in a couple of minutes.

We’re using the same Strapi instance for the My Kyivstar mobile app and the website, but we have two different environments for the site and app. Since both projects are voluminous, we didn’t want to mix different collection types and confuse our content team.

Nearly 40 developers, content editors, and managers are actively using Strapi. We needed to ensure that everyone had access to well-defined content & actions. That’s why we needed custom roles to precisely choose who can create, edit, publish or delete specific content types. With custom roles and permissions, we’re sure nobody will accidentally delete or publish something.

First of all, the website and mobile app perform well. Nearly 10 million users access our Strapi-powered products every month. It’s a lot of traffic, but the pages load fast with our stack.

Second, we’re able to ship new content more quickly. Since content managers can create landing pages using components, preview, and publish them independently from developers, the time to market is much shorter.

Finally, we’re happy that Strapi is customizable, so if we have a new need or use case, we can tweak it as we want - there’s no vendor lock-in risk and no need to change a CMS every year.