Martin Visser, Valkey Tech Lead at Percona, explains how to plan and de-risk your migration to this open source Redis fork, taking you step by step through the key considerations.

Your applications will have critical instances that support your data. Some of these will use an in-memory database, or use an in-memory data cache, and the chances are you rely on Redis for this. According to our research, Redis is the most popular key-value database in place at organisations, with around two thirds of deployments.

When Redis announced that it would change the license for Redis the project, this did not go down well with the community, leading to the creation of a new project named Valkey. As a fork of Redis supported by the Linux Foundation and multiple companies, Valkey provides an open source option for an in-memory database or data cache deployment. But for those enticed by this option, how should you plan your migration? 

The migration basics

Any data migration involves planning for before, during and after the implementation. It starts with a migration runbook that goes through all the steps required to move from one system to another, whether this is a simple software upgrade or a complete change in one application infrastructure component to another. You should also create a rollback plan in case you want to move back to the previous implementation.

You should carry out performance testing both before and after the move, including different metrics like throughput and transaction speed, patterns in transactions, or latency in your application. This reference baseline shows any current bottlenecks that you have. One approach here is to create synthetic workloads with generated data that demonstrates similar performance requirements to your production workload. This allows you to identify potential issues without using real data.

Once you have implemented your new infrastructure, you will have to manage the cutover from your existing deployment to your new instances. This process should be gradual, allowing you to shift traffic to your new clusters and run instances in parallel. For many implementations, pre-populating your new systems with data will make your migration window shorter.

Lastly, your migration should monitor system, application and component technology metrics for memory usage, throughput, command latencies and application performance after the cut-over takes place. Alongside this you can define what level of deviation in performance you consider acceptable – for the latest versions of Redis and Valkey, the performance level should be comparable. If you are migrating from a previous Redis version, you can expect improved performance while moving to Valkey.

Things to know when migrating from Redis 

Since Valkey is a direct fork of Redis, functionality is and will remain the same in the future. However there are some specific migration planning tasks that you have to consider.

A common consideration is what versions you are running. With the stability and functionality of Redis, current implementations may still be at Redis 6. Since Valkey originated out of Redis 7.2, moving to Valkey is also a major version upgrade. Your standard upgrade procedure should therefore be part of the planning.

Beyond core Redis, there are many popular add-ons and modules that also have to be migrated. As part of your planning phase, go through the installed modules and test them with your target Valkey version. Valkey is compatible with Redis but you should always check compatibility.

In the event of a problem, you will have two choices – either look for an alternative module that is compatible with Valkey, or work on the compatibility side yourself. This community contribution will deliver the result that you need and help other teams meet their requirements over time.

Following your module audit, you will also have to look at your connection string abstractions. Connection strings are used to connect application components to Redis and Valkey instances. When you need to migrate your application to Valkey, you will have to update those connections to point to your new instances.

Another potential issue is authentication. When you have multiple components in your application, those components have to communicate with each other. Whatever method that takes, you need to ensure that any communication only takes place with other authorised services. This also ensures that only authorised users can access data. This level of control is essential for compliance around personally identifiable information (PII) or payment data. If your starting point is Redis 6, now is the time to tighten this up by implementing the security improvements that come with Valkey 7.

Finally, ahead of any change, you should create a staging environment that mirrors your production setup. Redis is flexible and covers multiple data deployment options, including more complex deployments with more advanced clustering or multi-site deployments. Mirroring ensures that your migration target is as similar to your existing environment as possible. This step reduces the risk involved in cutting over and makes it easier to roll back in the event of any problem.

Reducing the risk in any migration

As you migrate, there are some best practices that you can implement to reduce risk. One common approach is to use a canary deployment. This involves using one deployment that can act as a guide for the others, so that you find any potential problems in advance. When you need to migrate multiple deployments, you will want to avoid moving too many at one time. Going live with one cluster or instance in advance provides an opportunity to check at a smaller scale how the migration target performs live. Once this pilot is implemented and you have checked your before-and-after metrics, you can move further instances into production.

You can also use traffic shadowing to track performance across both versions of your deployment on Redis and Valkey. This technique copies any application traffic or transactions to a separate system. The shadow traffic can demonstrate the real world behaviour of your application against the target whilst maintaining the original for rollback.

When you are carrying out a migration, you want to validate that services are running as expected. However, tracking those dashboards manually can be hard, particularly if you have a small team or your service is used around the clock. Setting automated rollback triggers enables you to move a service, or the traffic, back to the previous infrastructure if performance dips below a given threshold.

While the technical side of any migration can be challenging, the biggest hurdle is often communication. Creating a communications plan for everyone involved – from the developers and IT operations teams directly involved through to those that are indirectly affected like line of business teams or executives – makes the process easier. This includes covering what issues the migration will face, any expected pain points, and the potential business impact that could occur. By agreeing communication paths ahead of the move, you make it more likely that you can work together effectively around the whole project.

With the change in license for Redis, 83% of organisations are either moving to Valkey or have already implemented Valkey as an alternative. This points to the value around in-memory data and how vital an open source in-memory project will be. Getting your migration right is critical, so start planning ahead. By adopting common data migration techniques and understanding Redis specifics, you can ensure a successful transition.