Redis to Valkey: the migration decision.

The Redis to Valkey migration decision arrives for most teams not as a project they planned but as a question they cannot yet answer. Redis changed its license, a fork appeared, and someone senior asked whether the company should move. The honest answer is that it depends, and the rest of this guide is about replacing that vague worry with a structured choice. The decision turns on how you deploy Redis, what the new terms restrict, and what each path costs, and it should rest on a map of your estate rather than on the urgency of a headline.

What the migration decision is really about

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, and as of 2025 it added the GNU AGPL as an open license option for newer versions. Source available is not open source, and the Server Side Public License is not approved by the Open Source Initiative. Valkey is the community fork created from the last open source Redis release, held under foundation governance and continued under a permissive open license. So the Redis to Valkey migration decision is really a license posture decision. The two pieces of software are close cousins. What separates them is who controls the terms and whether those terms restrict your use.

Step one: map before you decide

No path can be chosen without an inventory. Map every Redis instance, the version each one runs, and the role it plays, then classify each by how it is exposed to the world. Instances that serve only internal traffic sit in a different risk class from instances that back a product sold to customers or a hosted service offered to third parties. Most estates find that only a handful of instances sit in the competitive use path that the source available terms concern. That handful, not the total count, is what drives the decision. To test whether the change reaches you at all, work through whether your Redis use is affected by the license change.

Step two: weigh the four paths

Once the map is in hand, four paths are open, and each should be scored on the same three measures: license posture, engineering cost, and timeline. The first path is to migrate to Valkey, which returns the workload to an open license and removes the competitive use question, at the cost of a migration project. The second is to stay on an older open source Redis version, which avoids work but pins you to an aging release and a security posture you must manage. The third is to adopt the Redis AGPL option, which is an open license but carries copyleft obligations that may not suit a closed product. The fourth is to negotiate a commercial license, which keeps the vendor relationship and the latest features, at a recurring cost. The choice between leaving and paying is explored in our guide to forking versus paying as a database decision.

When migration to Valkey is the right call

Migration tends to win when any instance offers Redis to third parties as a service, or when the business wants to remove its dependence on terms a single vendor can change again. Valkey is strongly compatible at the fork point and aims to keep the protocol and common clients interoperable, so for typical cache and data store use the engineering change is contained. The move buys predictability: foundation governance lowers the chance of another unilateral relicense, and an open license closes the competitive use exposure entirely. The detailed steps of the move are covered in our guide to migrating from Redis to Valkey.

When holding or paying makes more sense

Holding can be reasonable for a stable internal deployment with no live trigger, provided the decision is documented, the version is pinned, and the security posture is owned by someone. Paying for a commercial license makes sense when you rely on Redis commercial features that Valkey does not replace, or when the cost of a quote is lower than the engineering cost of migrating a large estate. The error to avoid is treating the choice as automatic in either direction. A reflex to migrate wastes effort on a risk that may not apply, and a reflex to do nothing leaves exposure sitting in production and weakens your hand at the next renewal.

Make the call on numbers, not urgency

The cleanest version of the Redis to Valkey migration decision sizes the cost of exposure against the cost to cure for each path, then chooses the lowest total risk that fits the timeline. Acting before a renewal rather than after is itself leverage, because it lets you choose your path on your own schedule. Whatever the decision, record it with the map that supports it, so the reasoning holds up when a vendor, an auditor, or your board asks why you chose as you did.

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