Migrating Redis OSS to Valkey on AWS: ElastiCache and MemoryDB Runbook

The AWS console offers an "Upgrade to Valkey" button on every ElastiCache for Redis OSS cluster, and the change is one call: aws elasticache modify-replication-group --engine valkey. Endpoints keep their DNS names, and each shard fails over once. The hard part is going back. AWS documents an in-place rollback only from Valkey 7.2 to Redis OSS 7.1, so going straight to Valkey 8.x or 9.x leaves a snapshot restore as the only fallback. The dates add pressure: Redis OSS 4 and 5 caches have paid Extended Support since 1 February 2026, and Redis OSS 6 standard support ends on 31 January 2027. This runbook covers ElastiCache node-based clusters, Serverless, and MemoryDB, plus the client checks to run before the failover.

Scope and review date: November 2026. This post covers Amazon ElastiCache for Redis OSS (node-based and Serverless) and Amazon MemoryDB for Redis OSS moving to Valkey. Commands and version lists were checked against the AWS documentation, and prices against AWS's price list for US East (N. Virginia), on 10 November 2026. The commands were not run in a lab, so rehearse them on staging.

Which Valkey versions can you move to on AWS?

As of November 2026, the ElastiCache engine versions page lists Valkey 7.2, 8.0, 8.1, 8.2, 9.0 and 9.1. ElastiCache 8.2 is Valkey 8.1 plus the valkey-search module. Each major version has its own parameter group family: valkey7, valkey8 (8.0 to 8.2) and valkey9 (9.0 and 9.1). On the Redis OSS side, node-based clusters still run 4.0.10 through 7.1.

MemoryDB is behind. Its engine versions page lists only Valkey 7.2.6 and MemoryDB 7.3, the version that MemoryDB Multi-Region needs. We found no AWS announcement of Valkey 8 or 9 for MemoryDB, so check the live list in your Region:

aws --version   # v2 must be 2.18.2 or later, v1 must be 1.35.2 or later

aws elasticache describe-cache-engine-versions --engine valkey \
  --query 'CacheEngineVersions[].[EngineVersion,CacheParameterGroupFamily]' \
  --output table

aws memorydb describe-engine-versions --engine valkey \
  --query 'EngineVersions[].[EngineVersion,EnginePatchVersion,ParameterGroupFamily]' \
  --output table

Interpretation: older CLIs do not know the cross-engine options. The tables list the versions and parameter group families you can target in this Region; anything missing is not a target here.

Why does the rollback depend on which Valkey version you pick?

The ElastiCache upgrade guide says it "only supports rolling back from Valkey 7.2 to Redis OSS 7.1". It also adds: "This is true even if you upgraded to Valkey 7.2 from an earlier version than Redis OSS 7.1." So a cluster that started on Redis OSS 6.2 rolls back to 7.1, not to 6.2. Plan for that: your rollback target is itself a version change.

A rollback behaves like the upgrade: same DNS endpoints, new node IPs, and a write pause of a few seconds per shard. You can also restore a Valkey 7.2 snapshot as a new Redis OSS 7.1 cache. One condition is easy to miss: every user and user group attached to the cache must have engine type REDIS.

Past 7.2 there is no documented path. The ModifyReplicationGroup API reference states that you "cannot downgrade to an earlier engine version", and AWS documents snapshot restores into Redis OSS 7.1 only for Valkey 7.2 snapshots. AWS does not say why. For background only: open-source Valkey 9.0 and 9.1 write RDB format version 80, a number outside the range Redis ever used.

Do not park on 7.2 for good. The Valkey project's supported versions table ends community maintenance of 7.2 on 16 April 2027.

MemoryDB is stricter still. Its engine versions page says you "can't downgrade to an older engine version", and it describes no Valkey-to-Redis exception.

Two stages cost a second failover per shard and a second change window, usually cheaper than a restore. If even one write pause is unacceptable, use a blue/green copy instead, as MaiCoin did with RedisShake (AWS case study, January 2026).

What has to be true before ElastiCache will change the engine?

Check each point with the cluster still on Redis OSS.

• Single-node clusters. A cluster mode disabled cache with one node must first become a replication group. The documented procedure wraps the existing node as the primary.
• Cluster mode. An engine upgrade cannot switch cluster mode disabled to enabled. That is a separate backup, seed and reshard project.
• Pending scale-ups. A pending scale-up blocks an immediate engine upgrade. Apply it first, or combine both changes in one call with --apply-immediately.
• Global Datastore. Secondary Regions upgrade first; the call is modify-global-replication-group, which also takes --engine.
• No Multi-AZ. Without Multi-AZ, AWS says the primary cannot serve requests during the upgrade. Leave free memory for the sync.

# Engine, cluster mode, Multi-AZ and state of every replication group
aws elasticache describe-replication-groups \
  --query 'ReplicationGroups[].[ReplicationGroupId,Engine,ClusterMode,MultiAZ,Status]' \
  --output table

# Engine version and parameter group per node
aws elasticache describe-cache-clusters \
  --query 'CacheClusters[].[CacheClusterId,ReplicationGroupId,EngineVersion,CacheParameterGroup.CacheParameterGroupName]' \
  --output table

Interpretation: an empty ReplicationGroupId marks a standalone node that needs wrapping first. A parameter group not named default.* needs a Valkey copy. Note the current engine version, because a rollback lands on 7.1 regardless.

# Wrap a standalone node (redis01) as the primary of a new replication group
aws elasticache create-replication-group \
  --replication-group-id app-cache \
  --replication-group-description "app cache, pre-Valkey" \
  --num-cache-clusters 3 \
  --primary-cluster-id redis01

Interpretation: the existing node becomes the primary and the new replicas inherit its settings. Wait for available before going further.

# Which user groups (RBAC) are attached, and with which engine type?
aws elasticache describe-user-groups \
  --query 'UserGroups[].[UserGroupId,Engine,Status]' --output table

Interpretation: keep user groups on REDIS during the burn-in. Valkey clusters accept both REDIS and VALKEY groups, but a rollback needs every attached user and group to be REDIS. Move to VALKEY user groups, which need password or IAM authentication, only after the final hop.

How do you recreate a custom parameter group for Valkey?

With a default parameter group, the engine flags are enough. With a custom one, AWS requires a custom Valkey group in the same call, and it "must have the same Redis OSS static parameter values as the existing Redis OSS custom parameter group". Static parameters are the ones with ChangeType set to requires-reboot. There is no copy-across-families command, so you diff and recreate.

# Only the parameters someone changed from the family default
aws elasticache describe-cache-parameters \
  --cache-parameter-group-name app-redis7 --source user \
  --query 'Parameters[].[ParameterName,ParameterValue,ChangeType]' --output table

Interpretation: this is your whole migration list. Each requires-reboot row must be set to the same value in the Valkey group. The immediate rows should match too, unless you mean to change them.

aws elasticache create-cache-parameter-group \
  --cache-parameter-group-name app-valkey7 \
  --cache-parameter-group-family valkey7 \
  --description "app-redis7 values on Valkey 7.2"

aws elasticache modify-cache-parameter-group \
  --cache-parameter-group-name app-valkey7 \
  --parameter-name-values \
    "ParameterName=maxmemory-policy,ParameterValue=allkeys-lru" \
    "ParameterName=notify-keyspace-events,ParameterValue=Ex"

# Diff the two groups' user-set values before the upgrade call
diff <(aws elasticache describe-cache-parameters --cache-parameter-group-name app-redis7 \
         --source user --query 'Parameters[].[ParameterName,ParameterValue]' --output text) \
     <(aws elasticache describe-cache-parameters --cache-parameter-group-name app-valkey7 \
         --source user --query 'Parameters[].[ParameterName,ParameterValue]' --output text)

Interpretation: an empty diff means the groups match. The values are examples; copy yours. Keep app-redis7 until you are past the rollback point.

Plan the second hop now. Per the engine parameter reference, valkey9 groups are incompatible with Valkey 8.x and Redis OSS, so each hop needs a new group. The valkey8 family drops the lazyfree-lazy-* parameters, raises the repl-backlog-size default to 10 MB, and adds extended-redis-compatibility (AWS lists its default as yes), which makes HELLO report redis 7.2.4.

Will your applications notice the switch?

Mostly through the failover. ElastiCache closes connections during the change, so clients need retries with backoff and must rediscover the new node IPs. A few behaviour changes also reach applications, listed on AWS's Valkey behaviour differences page:

The 9.1 change has already broken one client. Valkey issue #3909 reports that go-redis rejects the new CLUSTER SHARDS field. It was still open in November 2026. The fix shipped in go-redis v9.20.1 on 11 June 2026, and it skips unknown shard and node fields.

# Every Go service that talks to the cache
go list -m github.com/redis/go-redis/v9

# Code that matches on error text or on the server name
grep -rnE "UNBLOCKED|ERR unknown command|\"redis_version\"|Redis is loading" ./src

Interpretation: a go-redis version below v9.20.1 must be upgraded before any cluster goes to 9.1. Each grep hit is code that matches error text that changes across these versions, or that reads redis_version, which Valkey reports as the fixed compatibility value 7.2.4. Test each one on staging.

# On the staging copy after its upgrade (cluster mode enabled, TLS on)
valkey-cli -h clustercfg.app-cache-stg.xxxxxx.use1.cache.amazonaws.com \
  -p 6379 --tls CLUSTER SHARDS

Interpretation: on 9.1, each node map includes availability-zone. Point your real services at this endpoint too, because the parser that breaks lives in the client library.

What does the rehearsal, cutover and rollback runbook look like?

Rehearse on a staging copy restored from a production snapshot, with the same node type and shard count. Time the upgrade and the rollback, and run your client tests between them.

Step 7 is the upgrade call with the target swapped. AWS describes the rollback ("the same console, API, or CLI steps as an engine upgrade") but prints no command, so confirm it on staging. Without --apply-immediately, the change waits for the next maintenance window, because ApplyImmediately defaults to false.

# Events for the last two hours: node replacements and failovers per shard
aws elasticache describe-events --source-type replication-group \
  --source-identifier app-cache --duration 120

Interpretation: line each shard's failover event up against your client error graphs. AWS warns that old and new nodes are briefly both visible during each swap, so errors from replicas still loading data are expected then and should stop when the swap ends.

How do ElastiCache Serverless and MemoryDB differ?

ElastiCache Serverless

Serverless takes a major version rather than a full version. AWS says major version upgrades on Serverless run without downtime to the application. The rollback requirements in the upgrade guide also name serverless caches, which suggests the 7.2 rule applies there too. Rehearse that before you rely on it.

aws elasticache modify-serverless-cache \
  --serverless-cache-name app-sessions \
  --engine valkey --major-engine-version 7

Interpretation: AWS's own example uses --major-engine-version 9. Choosing 7, if your Region still offers it for Serverless, keeps you on the rollback-capable stage. In the console, AWS also tells you to pick a Valkey parameter group, such as default.valkey8, when the serverless cache moves.

MemoryDB

MemoryDB uses update-cluster, with the same rule about custom parameter groups. The MemoryDB modify guide shows Valkey 7.2 as the target.

aws memorydb update-cluster \
  --cluster-name orders-db \
  --engine valkey --engine-version 7.2 \
  --parameter-group-name orders-valkey7

Interpretation: MemoryDB has no rollback. It is often the system of record, so take a snapshot and test its restore into a new Redis OSS cluster first; that is your only fallback.

What happens to reserved nodes and the bill?

AWS's launch note of 8 October 2024 put ElastiCache for Valkey at 20% lower for node-based clusters and 33% lower for Serverless, and the US East prices in the comparison card match. MemoryDB for Valkey is 30% lower per node hour. In the us-east-1 price list, the first 10 TB of data written each month costs $0 on Valkey and $0.04 per GB after that, against $0.20 per GB on Redis OSS.

Reserved nodes carry over. The ElastiCache reserved nodes guide says Redis OSS reservations apply to Valkey nodes in the same family and Region. A cache.r7g.4xlarge counts as 32 units on Redis OSS and 25.6 units on Valkey. The freed 6.4 units cover, for example, one cache.r7g.xlarge Valkey node. The reverse does not hold: "Valkey reserved nodes apply only to running Valkey nodes". If you buy Valkey reservations during the burn-in and then roll back, they cover nothing.

aws elasticache describe-reserved-cache-nodes \
  --query 'ReservedCacheNodes[].[ReservedCacheNodeId,CacheNodeType,ProductDescription,CacheNodeCount,State]' \
  --output table

Interpretation: ProductDescription shows each reservation's engine. Redis OSS reservations survive a rollback, so renew them as Valkey only after the one-way hop.

Frequently asked questions

Key takeaways

Plan your ElastiCache or MemoryDB move to Valkey with JusDB

JusDB's Valkey migration team can review your ElastiCache and MemoryDB estate, recreate and diff parameter groups, check client libraries against each Valkey version's behaviour changes, and write a rehearsed upgrade and rollback runbook for each cluster.

Bring your cluster inventory, client libraries, reserved node list, and change windows. Your team approves every production change. For the product comparison, see Redis vs Valkey.

Related reading

• Redis 8 vs Valkey 8 in production
• Valkey 9.1: database ACLs, Lua and I/O threading
• Valkey performance tuning: memory, persistence, and cluster config
• AWS documentation: Upgrading engine versions, including cross-engine upgrades