Recommendation for Valkey version when migrating from Redis OSS 7.2.16, want stable & feature‑preserving switch

[chenshi5012]

Hi Valkey community,

We are planning to migrate our production environment from Redis OSS 7.2.16 to Valkey.
Our main goals:

1. Keep all existing features and behavior as much as possible, avoid breaking changes
2. Smooth, low‑risk production switch, minimal business impact
3. RDB/AOF persistence, Redis Cluster, Sentinel are all in use, no Redis Stack modules.

We are considering two options:

• Valkey 7.2.x latest patch release (forked from Redis 7.2.4)
• Valkey 8.x latest stable release

Questions:

1. Which version would you recommend for our migration scenario?
2. Are there any hidden behavior differences between Redis 7.2.16 and Valkey 7.2.x that we need to pay attention to?
3. What are the critical breaking changes we should validate if we choose Valkey 8.x?
4. Any migration pitfalls or best practices for zero‑downtime replication‑based cutover?

Our current deployment:

• Redis OSS 7.2.16, cluster + sentinel topology
• Using standard core commands, no custom modules
• RDB + AOF persistence enabled
• Standard Redis clients (no special Valkey‑specific client yet)

Thanks a lot for your advice!

[gyanu2507]

Do not stay on Valkey 7.2.x for this. That line is Redis OSS 7.2.4. You are on 7.2.16, so 7.2.x Valkey is a patch downgrade. For a low-risk, feature-preserving cutover, take current Valkey 8.1.x. 8.1.0's notes say it is compatible with previous Valkey releases and with Redis OSS 7.2.4, and 8.1 added no extra breaking behavior on top of 8.0.

Things to validate on 8.x vs Redis 7.2.16 (from the 8.0 notes):

• Nested MULTI/WATCH inside a transaction now aborts (used to be ignored).
• SCAN no longer returns lazily expired keys.
• BITCOUNT / BITPOS error on bad args for missing keys instead of returning 0.
• Default repl-backlog-size is 10 MB.

You said no Redis Stack modules, so the usual module trap does not apply. Cluster and Sentinel together is the operational oddity. Redis Cluster does not use Sentinel. Confirm which topology you actually fail over with, then replicate that in staging (replicaof / cluster meet, not both).

Zero-downtime: stand up Valkey replicas of the Redis masters (replicaof / replica-of), wait for sync, then failover. RDB+AOF from 7.2 loads. Keep the same client library. INFO server will say Valkey. Do not jump to 9.x for the first cutover. 9.0 adds atomic slot migration and numbered DBs in cluster mode, which is more than you need for a 7.2.16 replacement.

[chenshi5012]

Thanks a lot @gyanu2507 for this critical reminder! I had overlooked the fact that Valkey 7.2.x is based on Redis OSS 7.2.4 and would be a patch‑level downgrade compared to our current Redis 7.2.16. So we will target Valkey 8.1.x for our migration.

We will add these four points to our staging validation checklist:

1. Nested MULTI/WATCH inside a transaction will abort instead of being silently ignored
2. SCAN will no longer return lazily‑expired keys
3. BITCOUNT / BITPOS will throw errors for bad arguments / missing keys instead of returning 0
4. The default value of repl‑backlog‑size is now 10 MB

For our deployment topology: we maintain two independent sets of instances. One is Redis Cluster for sharded data, another standalone Sentinel‑managed master‑replica group for non‑sharded workloads. We do not mix Cluster and Sentinel on the same node. We will build corresponding staging environments to verify failover logic for both scenarios separately.

A few follow‑up questions to clarify our zero‑downtime migration plan:

1. When Valkey 8.1.x acts as a replica of Redis 7.2.16 via replicaof, are there any known replication‑protocol edge cases we should watch for?
2. After we promote Valkey replica to master, are there any subtle config defaults, INFO metrics or server‑identity changes that may surprise standard Redis clients?
3. Apart from the four breaking‑behavior items you listed, are there any other silent behavioural divergences between Redis 7.2.16 and Valkey 8.1.x we should validate?

We agree we will skip Valkey 9.x for this initial production cutover. Thank you again for your valuable guidance!