Migration in flight — sound familiar?
- ▸ Lua scripts breaking on Valkey 8 — Function signature changes you didn't catch in staging — EVAL scripts that worked on Redis 7.2 are returning WRONGTYPE on Valkey 8 production.
- ▸ Client library version pinning incomplete — Some app services are using older redis-py / jedis / ioredis releases that silently degrade against Valkey; failures are intermittent and load-dependent.
- ▸ ElastiCache → self-managed rollback plan — If cutover at 3am goes wrong, you can't fail back to ElastiCache because backup format and the AUTH workflow are different. The rollback plan was never tested.
JusDB migration consultants own the cutover playbook + rollback plan, end-to-end. Book a migration scoping call →
Execution playbook — strategy lives on /consulting
Redis to Valkey Migration
Replication-based cutover from Redis 7.2.x or ElastiCache Redis to Valkey 8 with <30 seconds observed downtime. Client compatibility audit, 24-hour hot rollback path, and a written validation report at the end.
The 4-phase migration playbook
Same sequence whether you're on ElastiCache Redis, self-managed Redis 7.2, or a cluster-mode deployment. What changes is the bootstrap path in Phase 2.
Phase 1 — Compatibility Audit
Inventory client SDKs and pinned versions, audit Lua scripts and module dependencies, diff parameter-group config between source and target Valkey 8 defaults.
Deliverable: Compatibility matrix + change list
Phase 2 — Replication Bootstrap
Stand up Valkey 8 replica attached to the source Redis primary. Stream RDB snapshot + tail AOF. Wait for replication lag <100ms sustained over a 30-min window.
Deliverable: Synced replica, monitored
Phase 3 — Cutover
Promote Valkey replica to primary, flip client DNS or connection string, validate first 1k writes land cleanly. Old Redis primary kept hot for 24h as rollback target.
Deliverable: <30s observed downtime
Phase 4 — Validation & Teardown
Run business-traffic validation, compare hit rates / latency / eviction counts pre/post, sign off on KPIs, then tear down the original Redis primary and rollback path.
Deliverable: Validation report + clean teardown
Source platforms we migrate from
AWS ElastiCache Redis 7.2
Approach
In-place engine conversion to ElastiCache Valkey 8 via the modify-cluster API, after a parameter-group diff and TLS/IAM audit.
Zero (online)
Self-managed Redis 7.2.x
Approach
Valkey 8 replica attached via the Redis replication protocol, snapshot stream + AOF tail, then DNS / connection-string cutover.
<30 seconds
Redis Cluster mode (multi-shard)
Approach
Per-shard replica attach, slot-level lag monitoring, coordinated shard-by-shard promotion to minimize client re-discovery storms.
<30s per shard
When NOT to migrate yet
Hold off if any of these apply:
- Your stack hard-depends on Redis Stack modules (RedisJSON, RediSearch, RedisGraph) at versions Valkey 8 hasn't yet reimplemented.
- You're on Redis Enterprise (not OSS) — different commercial license path; migration is a re-platforming, not a fork swap.
- You have an active vendor support contract with Redis Inc. that you're mid-contract on — wait for renewal.
Otherwise the migration is low-risk. We surface these blockers in the Phase 1 audit before any work commits.