Best practice for migrating from Redis 7.4 cluster (RDB v12) to Valkey 8.x at scale (~100 data centres)?

[sunijha]

Context

We're running Redis 7.4.0 in a 15-node TLS cluster (3 masters × 4 replicas, ~159M keys per cluster) across ~100 data centres on an internal PaaS (not Kubernetes/EKS). We need to migrate to Valkey due to Redis's license change (RSALv2/SSPLv1 — prohibited under our corporate policy).

Problems We've Hit

1. Rolling upgrade doesn't work

We attempted a rolling upgrade (Redis 7.4.0 → Valkey 8.0.9) on a staging cluster. Valkey nodes joined the cluster but:

• master_link_status:down, DBSIZE:0 on Valkey replicas
• When Valkey replicas were promoted to master → all shard data lost (0 keys)
• Root cause: Redis 7.4 produces RDB v12, which Valkey (forked from Redis 7.2.4, RDB v11) cannot parse

2. RDB file restore doesn't work

Our existing DR scripts download dump.rdb from S3 and restart the server — but Valkey rejects the RDB v12 file with Can't handle RDB format version 12.

3. Scale makes offline migration impractical

With ~100 data centres, tools like rdb-cli (offline RDB replay) require per-cluster maintenance windows — not feasible at this scale.

Questions for the Community

1. Has anyone successfully migrated from Redis 7.4+ (RDB v12) to Valkey at scale? What approach did you use?

2. Are there plans for Valkey to support RDB v12 parsing? This would make rolling upgrades from Redis 7.4+ possible — a very common migration path given Redis 7.4 was widely deployed before the license change.

3. **Any other tools or approaches we should consider?

Environment

• Source: Redis 7.4.0, TLS-only (port 6379), AUTH enabled, 3 shards × 5 replicas
• Target: Valkey 8.0.9 (Cloud9/Chainguard image, BSD-3-Clause)
• Scale: ~100 data centres, ~159M keys per cluster
• Infra: Quadra PaaS (Consul service discovery, not K8s)

Any guidance or shared experience would be greatly appreciated!

[sueun-dev]

I reproduced the compat bit with stock containers. Redis 7.4.0 writes REDIS0012; Valkey 8.0.9 and 8.1.7 both reject that dump with Can't handle RDB format version 12. Redis 7.2.4 writes REDIS0011, and Valkey 8.0.9 loaded that one fine.

Full sync doesn't dodge it either: a Valkey 8.0.9/8.1.7 replica of a Redis 7.4 primary stayed master_link_status:down and logged the same RDB v12 error. Per-key DUMP/RESTORE from Redis 7.4 to Valkey 8.0.9 also failed with ERR DUMP payload version or checksum are wrong.

So I wouldn't plan a Redis 7.4 -> Valkey 8.x cutover around RDB restore, full-sync/PSYNC, or tools that use Redis serialization under the hood. The safer path is a logical/type-aware copy that reads keys/types and writes normal commands into Valkey, then validates before traffic cutover. Can't speak for roadmap, but 8.1.7 source still has RDB 11 as the Valkey 7.x/8.x format and treats Redis RDB 12+ as unsupported.