// OSSeva Blog

Migration

Migrate Redis to Valkey: A Step-by-Step Cutover With Rollback

Randall McClureOctober 5, 202611 min read

The short answer

If you run Redis OSS 7.2 or earlier, you can move to Valkey by making a Valkey server a replica of your Redis primary, waiting for it to sync, pausing writes for a few seconds, repointing clients and promoting Valkey. The Valkey migration guide says Valkey 7.2 and later use a "compatible protocol, configuration, and RDB/AOF formats" with Redis OSS 2.x to 7.2.x. If you run Redis Community Edition 7.4 or 8.x, that path is closed: the guide states that RDB files from Redis CE 7.4 and later are not compatible, so you need a key-level copy instead.

Land on Valkey 8.1 first, not 9.x. Valkey 7.2 and 8.x still write RDB version 11, which Redis 7.2 can read, so you keep a way back. Valkey 9.0 writes a new RDB format that Redis cannot load. Upgrade to 9.x once the rollback window has closed.

If you are still deciding whether to switch at all, read Valkey vs Redis first. This post is the how-to.

Why teams move

Redis 7.2 and earlier are BSD-3-Clause. From 7.4, Redis is under a choice of RSALv2 or SSPLv1, and Redis 8 added AGPLv3 as a third option. Valkey, the Linux Foundation fork started from Redis 7.2.4, stays BSD-3-Clause. For many teams the licence matters less than patching: the older Redis lines are no longer getting fixes, while Valkey has active 7.2, 8.1 and 9.x lines. All three shipped releases on 1 September 2026 (7.2.14, 8.1.10 and 9.1.2). The Redis licence change post has the full history.

Version compatibility

Source	Target	Supported method	Rollback path
Redis OSS 7.2.x	Valkey 7.2.x or 8.1.x	Replication or RDB copy	Valkey 7.2 and 8.x write RDB version 11, the same version as Redis 7.2, so an RDB taken on Valkey can go back to Redis 7.2. Test it first.
Redis OSS 6.2 or 7.0	Valkey 7.2.x or 8.1.x	Replication or RDB copy	Redis 6.2 writes RDB 9 and 7.0 writes RDB 10, so neither reads the RDB 11 files Valkey writes. Roll back to Redis 7.2, not to your original version.
Redis OSS up to 7.2.x	Valkey 9.x directly	Replication or RDB copy	None by data file. Valkey 9.0 writes RDB 80 with a Valkey header that Redis does not read.
Redis CE 7.4 or 8.x	Any Valkey	Not by replication or RDB. Redis 7.4 writes RDB 12, a range Valkey reserves as a foreign format.	Keep Redis running until you are satisfied.

For a Redis 7.4 or 8.x source, copy data at the key level with a tool or script that reads values through ordinary commands and writes them to Valkey, or rebuild the cache from the system of record. DUMP and RESTORE do not help, because the serialized value carries the source's RDB version.

What changes for clients and tools

Area	Redis	Valkey	Action
Protocol and commands	RESP2 and RESP3	Same	None for Redis 7.2 command sets. Valkey's client page says clients that support Redis OSS 7.2 are compatible with Valkey 7.2 and above.
Binaries	`redis-server`, `redis-cli`, `redis-sentinel`	`valkey-server`, `valkey-cli`, `valkey-sentinel`	A source install creates `redis-*` symlinks by default (`USE_REDIS_SYMLINKS=yes`). Distribution packages vary, so check unit files and scripts.
`INFO server`	`redis_version`	`redis_version:7.2.4` plus `server_name:valkey` and `valkey_version`	Monitoring that parses the version keeps working, but it will report 7.2.4.
Server identity	Reports itself as Redis	Reports itself as Valkey in a few places, such as `HELLO`	If a tool rejects it, Valkey 8.0 and later offer `extended-redis-compatibility yes`, a temporary setting the config file says will be removed later.
Replication auth	`masterauth`, `masteruser`	`primaryauth`, `primaryuser` in 8.x, old names accepted	Existing config files load unchanged.
Lua scripts	`redis.call()`	Same; the `redis` namespace still works	None.
Modules	RedisModule API	Same API; the guide says such modules work	Check each module's licence and version. Valkey has its own JSON, Bloom and Search modules if you are replacing Redis Stack ones.
Client libraries	redis-py, Jedis, Lettuce, ioredis, go-redis	These keep working; Valkey also maintains GLIDE, valkey-py, valkey-java, valkey-go and iovalkey	Switch libraries later, as a separate change.

Before you start

Record the source state: INFO server, INFO keyspace, DBSIZE per database, MODULE LIST, ACL LIST and CONFIG GET *.
Port the configuration file. Valkey accepts the same directives, so redis.conf becomes valkey.conf with paths and service names changed. Copy your ACL file if you use one.
Size the Valkey host for at least the source's memory plus the replication buffer, and match maxmemory and the eviction policy.
Decide how clients will move: DNS, a service endpoint, a proxy or a config change. That is your cutover lever and your rollback lever.

Cutover steps: standalone primary

Start Valkey with the ported config. If the Redis primary needs a password, set masterauth (and masteruser with ACLs) on Valkey.
On Valkey, run REPLICAOF <redis-host> <port>.
Wait for INFO replication on Valkey to show master_link_status:up and the initial sync to finish. Compare INFO keyspace on both sides.
Pause writes on Redis with CLIENT PAUSE <milliseconds> WRITE, long enough to cover the next two steps. Reads keep working.
Confirm Valkey's replication offset matches the primary's, then repoint clients to Valkey.
On Valkey, run REPLICAOF NO ONE. INFO replication should show role:master and connected_slaves:0.
Leave Redis running, untouched, until the rollback window closes.

The Valkey guide also documents an offline method: run SAVE on Redis, copy the RDB file to Valkey's directory, start Valkey with AOF disabled, and compare INFO keyspace. Use it when a write outage is acceptable.

Cutover steps: Sentinel

Add Valkey servers as replicas of the current Redis primary, as above. Sentinel discovers replicas from the primary, and Valkey's INFO output keeps the fields Sentinel reads.
Give the Valkey replicas a better replica-priority (a lower number) than the Redis replicas, so Sentinel prefers them.
Run SENTINEL FAILOVER <master-name> and confirm a Valkey node is the new primary.
Remove the Redis replicas, then replace each Sentinel with valkey-sentinel one at a time, keeping a quorum throughout.

Valkey's guide does not document a mixed Redis and Valkey Sentinel setup, so rehearse this in staging with your Sentinel version before production.

Cutover steps: Cluster

Start each Valkey node with cluster-enabled yes.
Add it as a replica of an existing primary: valkey-cli --cluster add-node <valkey-ip>:6379 <existing-ip>:6379 --cluster-replica.
Once it has synced, run CLUSTER FAILOVER on the Valkey node to promote it.
Repeat for each shard, then remove the Redis nodes with valkey-cli --cluster del-node <host>:<port> <node-id>.

Cluster-aware clients follow the topology change on their own. Check that yours refreshes its slot map after MOVED replies.

Test plan

Key counts per database match after the initial sync and again at cutover.
A sample of keys of every data type returns identical values and TTLs on both sides.
Every client library and version in use connects, authenticates with its ACL user and runs its usual commands against Valkey in staging.
Lua scripts and functions load and run.
Monitoring, backup and alerting tools still parse INFO and still trigger.
Persistence works: force a BGSAVE, restart Valkey and confirm the data loads.
For Sentinel and Cluster, a failover drill with clients under load.

Rollback plan

Before promotion: stop replication on Valkey and leave clients on Redis. Nothing has changed for them.
After promotion, on Valkey 7.2 or 8.x: point clients back to the old Redis primary. Writes made on Valkey since the cutover are lost unless you carry them back. To carry them back, take an RDB from Valkey and load it into Redis 7.2, which reads RDB 11. Replicating from Valkey to Redis is not part of Valkey's documented path, so test either method in staging before you count on it.
After upgrading to Valkey 9.x: there is no data-file path back to Redis. That is why the upgrade to 9.x should wait until you no longer need a rollback.

If you cannot migrate in time

Some estates cannot change engines quickly, because of a vendor appliance that bundles Redis, a module with no Valkey equivalent, or an audit freeze. OSSeva ships patched, signed builds of Redis 6.2, 7.0 and 7.2 under the original BSD licence and supports Valkey 7.2 and 8.x, with VEX attestation for scanner findings and 24/7 operations on the Operate tier. That lets you migrate on your own schedule. See Redis support, the Redis end-of-life tracker, the Redis 7.2 end-of-life page and the Valkey release tracker. If you are on ElastiCache, see ElastiCache Extended Support for Redis.

Common questions

Can I migrate from Redis 8 to Valkey?

Not by replication or by copying the RDB file. Valkey's migration guide says RDB files from Redis CE 7.4 and later are not compatible. Copy data at the key level or rebuild it from its source.

Do I need to change my application code?

Usually not. Clients that support Redis OSS 7.2 work with Valkey 7.2 and later. Code that checks the server name or version string is the main exception.

Which Valkey version should I start on?

8.1. It keeps the RDB format Redis 7.2 understands, so a rollback is still possible. Move to 9.x afterwards.

Ready to get your open source under control?

Talk to an OSSeva engineer about CVE coverage, compliance, and migration support for your stack.

Book a discovery call View services