Migrating from Redis to Valkey.

Migrating from Redis to Valkey starts with a license change and ends with an in memory data store, and the work in between is mostly about scoping the move so it does not become an open ended project. This guide walks the decision and the migration from the buyer side, with the license facts stated plainly and the engineering choices framed by what they cost. The aim is a move you can defend to your board and your counsel, not a reflex triggered by a headline.

Why the Redis license changed

As of March 2024, Redis moved from a permissive open source license to a dual model under the Redis Source Available License and the Server Side Public License. The stated aim was to stop cloud providers from offering Redis as a managed service without contributing back. Whatever the merits of that goal, the effect for buyers was a shift in terms on software many had adopted years earlier under an open source license. Source available is not open source, and the Server Side Public License is not approved by the Open Source Initiative. As of 2025, Redis also added the GNU AGPL as an open license option for newer versions, which gives buyers more than one open path but also makes the version you run the thing that decides which terms apply. The mechanics are covered in our explainer on what the Redis Source Available License and the Server Side Public License mean.

In response, a group of contributors and cloud providers forked the last open source Redis release, and Valkey was the result. Valkey is held under foundation governance and continues under a permissive open source license, which is what makes it the destination for buyers who want to return to an open footing. For a side by side view of the two, see our comparison of Redis versus Valkey for enterprises.

Should you migrate from Redis to Valkey?

The move is not automatic. For an internal cache that never leaves your own walls, the competitive use language in the source available terms may not reach you at all, and the cost of migrating could outweigh a risk that does not apply. For a vendor that embeds Redis in a product sold to customers, or a platform that offers a hosted data service, the calculus changes. The honest first step is to map where Redis sits in your estate and how each instance is used, then decide. Migration is one of several valid answers, alongside staying on an older open source version, adopting the AGPL option, or negotiating commercial terms. To test whether the change touches you at all, read whether your Redis use is affected by the license change.

We weigh the choice between leaving and paying in our guide to forking versus paying as a database decision. The point here is that you should reach the migration decision through a scoped review, not under the pressure of a renewal clock.

Step one: inventory every Redis instance

Start by finding every Redis instance, every service that talks to it, and the role each one plays. Software composition analysis will surface the client libraries, but Redis often hides in places a dependency scan misses, such as session stores, rate limiters, job queues, and the caching layer inside third party tools. Record the version of each instance, because the version sets the license that governs it. A complete inventory turns the migration from a guess into a bounded list of named systems, ranked by how exposed each one is. The handful of instances in the competitive use path are the ones that matter; the rest can move on their own schedule.

Step two: test Valkey compatibility against real workloads

Valkey began from the last open source Redis release, so compatibility is strong at the fork point and the project aims to keep the protocol and common clients interoperable. For typical cache and data store use, the migration is often a configuration change rather than an application rewrite. Do not assume permanent parity. Stand up a Valkey instance, point a copy of your real traffic at it, and confirm that your client libraries connect and behave, paying attention to any module or command that sits outside the core set. The gaps you find here are the true scope of the migration, and they are far cheaper to find in a test than in production. Client version pinning is the most common source of breakage, so check every application that hard codes a Redis client version.

Step three: plan the data move and the cutover

Redis is often used for ephemeral data such as cache entries and sessions, which makes the data move simpler than a relational migration, because much of it can be rebuilt rather than copied. Where Redis holds state that matters, plan a replication or snapshot path and confirm it restores cleanly into Valkey. Sequence the cutover by service rather than all at once. Move the lowest risk instance first, validate it behind a test suite, then promote it. Run Valkey and Redis side by side during the transition so any regression can be reverted in minutes rather than rolled back across the estate. The side by side window costs some infrastructure for a period, and it buys a safe path that does not bet the platform on a single switch.

Step four: update clients and decommission cleanly

With traffic flowing to Valkey, update each application to a current client and retire the configurations that pointed at the source available Redis versions. This is the step where the inventory pays off, because you already hold the list of every service to touch. Once traffic has fully moved and a rollback window has passed, decommission the Redis instances that carried the new terms. Update your software bill of materials to reflect the new state, so the next person to ask what governs your data layer has a current answer rather than a stale manifest.

What the migration does and does not solve

A clean migration to Valkey returns your data layer to an open license and removes the competitive use question the source available terms raised. It does not, by itself, fix the discipline gap that let the license change go unnoticed. The estate that ran Redis on terms no one had revisited probably runs other components the same way. The lasting value of the migration is the inventory it forces you to build, which becomes the asset that catches the next relicense at intake rather than in an audit.

Migration work like this is the focus of our open source remediation advisory service. For the wider frame, read our pillar on Redis, Elastic, and database relicensing. Interpretation of whether your Redis use is restricted under the new terms is a question for your own counsel.