Should I Migrate from Redis to Valkey?

Valkey emerged as a Linux Foundation-backed fork of Redis after Redis Ltd.'s 2024 license change moved Redis away from a fully open-source license. Valkey markets itself as a drop-in replacement — same protocol, same commands, same client libraries. But "drop-in" is a claim to test, not a claim to trust blindly, especially if you're running modules, custom configurations, or non-trivial memory management tuning.

This post covers how to actually evaluate the migration, based on a real production team's parallel Valkey compatibility testing.

For core commands and the standard protocol, yes — this is the entire premise of the fork, and it holds for the majority of typical Redis usage. But "compatible" needs to be validated specifically for your deployment, not assumed from the marketing claim, particularly if you use:

• Redis modules (RediSearch, RedisJSON, RedisTimeSeries, or similar) — module compatibility with Valkey is not guaranteed to be 1:1 and needs explicit testing
• Client libraries with Redis-specific version detection or feature negotiation logic
• Non-default configuration parameters that may have different names, defaults, or behavior in Valkey

The right approach is to test in parallel against your actual workload rather than migrating on faith. In a real production evaluation, a team was specifically tasked with configuring and testing ElastiCache Valkey mode compatibility and performance against their current Redis setup locally, running it through the same CI environment used for Redis validation — while simultaneously working through unrelated Redis stability issues. Running the Valkey evaluation in parallel with, rather than instead of, ongoing Redis operations let the team validate compatibility without betting production stability on an unproven migration.

Structure your evaluation around these dimensions, mirroring what a real production test covered:

Protocol and command compatibility. Run your actual application test suite against Valkey instead of Redis and confirm nothing breaks. Pay particular attention to any commands your application uses beyond the common GET/SET/HGET set — especially if you use Lua scripting, transactions, or pub/sub patterns.

Performance under your actual load profile. Don't rely on generic Valkey vs. Redis benchmarks published elsewhere — they reflect someone else's workload. Run your own load test (JMeter, redis-benchmark, or your existing load-testing tooling) against both systems with representative traffic.

Cost implications. If you're on a managed service, compare the pricing model directly — AWS ElastiCache's Valkey mode, for example, has its own pricing structure that should be evaluated against your current Redis Enterprise or self-managed cost baseline, not assumed to be cheaper by default. Evaluating cost implications was an explicit part of the real production test scope.

Module dependency check. If you rely on RediSearch, RedisJSON, or other modules, confirm Valkey's module ecosystem covers your specific usage before committing — this is the area most likely to have gaps relative to Redis.

Two separate motivations tend to show up, and it's worth being clear about which one applies to you because they lead to different evaluation priorities:

Licensing concerns. Organizations uncomfortable with Redis Ltd.'s post-2024 licensing terms, particularly those building products that redistribute or embed Redis, may have a structural reason to move regardless of technical parity.

Instability on their current Redis deployment. Teams actively debugging Redis stability issues sometimes evaluate Valkey as part of a broader remediation effort — not necessarily because Valkey is expected to be more stable inherently, but because a migration is already on the table as one possible path forward, and it's efficient to test compatibility while other root-cause work is underway. This was exactly the pattern in the real case referenced above: the Valkey evaluation happened in parallel with an active Redis memory-leak investigation, not as a direct response to the leak itself.

If your motivation is licensing, your evaluation should prioritize legal/compliance sign-off and long-term protocol compatibility guarantees. If your motivation is stability, be honest with yourself about whether the instability is actually a Redis-versus-Valkey issue, or an architecture/configuration issue that would follow you to either platform — a memory leak caused by a badly-tuned search index, for example, isn't automatically fixed by changing which fork you run.

Valkey maintains the same core HA architecture concepts as Redis — Sentinel-style monitoring and failover, and cluster-mode sharding — since it forked from the same codebase. If your current HA design relies on standard Redis Sentinel or Redis Cluster patterns, that architectural knowledge transfers directly.

That said, validate this the same way you'd validate anything else in the migration: test your actual failover procedure against Valkey rather than assuming behavioral parity, particularly around split-brain handling and quorum behavior during network partitions.

A phased approach reduces risk:

1. Parallel testing in a non-production environment — exactly as done in the referenced case, run Valkey alongside your existing Redis setup using the same test harness and traffic patterns
2. Shadow/dual-write validation if your architecture supports it — write to both systems and compare results before cutting over reads
3. Staged cutover starting with lower-criticality workloads — don't migrate your most business-critical Redis instance first
4. Full cutover with a documented rollback plan — since Valkey and Redis diverge further with each release, have a clear point past which rollback becomes impractical, and make that decision deliberately rather than by default

Valkey has strong backing (Linux Foundation, with major cloud providers including AWS offering managed Valkey services) and is being actively evaluated and adopted by production teams as of this writing. It's not an experimental or unproven fork — but "backed by credible organizations" and "validated for your specific workload" are different claims, and only the second one should drive your migration timeline.

The realistic answer: if your compatibility and performance testing comes back clean for your actual usage pattern, Valkey is a legitimate production option today. If you have significant module dependencies or highly customized configurations, budget real testing time before committing either direction.

Most migrations we have run were quieter than the teams expected, and application code did not change. Where things broke, they broke in the same handful of places, all findable before cutover.

Client libraries that inspect the server. Symptom: a service that worked against Redis refuses to connect to Valkey, or connects and silently disables a feature such as client-side caching. Cause: some clients parse the INFO or HELLO response, match on the string "redis" or a version number, and gate behaviour on the result. Valkey reports its own name and version, so the check fails. Clients negotiating RESP3 through HELLO can also fall back to RESP2 silently, which changes the shape of some replies. Fix: upgrade to a client release that recognises Valkey and test the handshake against a throwaway Valkey container first.

Modules with no Valkey equivalent. Symptom: a command returns an unknown-command error only on Valkey. Cause: the Redis search, JSON, time series or Bloom modules were loaded on the Redis nodes and nobody had listed them. Valkey has its own module ecosystem, but it is not a one-to-one mapping, and a module built for Redis will not load into Valkey. Fix: run MODULE LIST on every Redis node before planning anything, then decide per module whether a compatible Valkey module exists, the workload can move to core data types, or that cluster stays on Redis for now.

Persistence and replication format. Symptom: a replica refuses to sync, or a restored snapshot fails to load. Cause: the RDB version moved between Redis 7.x and Valkey 8.x. A Valkey replica can load the snapshot a Redis 7.x primary sends it, which is what makes the replica-of migration work. The reverse is not true: once Valkey has written its newer RDB format, a Redis node cannot load it. Fix: treat replication as one direction only, Redis to Valkey, for the length of the migration window, and keep a Redis-format snapshot from before cutover as the rollback artefact.

Configuration and file paths. Symptom: the service starts with defaults, or does not start at all. Cause: config files copied across still reference /etc/redis and /var/lib/redis, service units point at the old binary, and a few directives were renamed or deprecated between versions. Fix: diff CONFIG GET * from both running servers rather than the files on disk, and resolve every difference deliberately.

Monitoring that keys on the old name. Symptom: dashboards go blank and alerts stop firing right after cutover. Cause: exporters filter on the redis-server process name and panels select on INFO fields such as redis_version. Fix: update process matchers and field names before cutover and confirm panels populate from the staging Valkey node. Our guide to Redis high availability covers what those panels should show.

AWS managed services. ElastiCache and MemoryDB both offer a Valkey engine, and the in-place engine upgrade from a Redis OSS cluster is the least eventful path we have used. Two things catch teams: parameter groups are engine-specific, so a custom Redis parameter group must be recreated as a Valkey group and reviewed line by line, and the endpoint stays the same while the reported engine name changes, which trips the client and monitoring checks above.

Muscle memory. The binary is valkey-server, the CLI is valkey-cli, and the packages and service unit carry the new name. Update runbooks and on-call notes, or the first incident after migration starts with a command that does not exist.

1. Inventory. Capture MODULE LIST, INFO server and CONFIG GET * from every Redis node. List every client library and pinned version across every service that connects, including batch jobs and sidecars.
2. Fix clients first. Upgrade or patch anything that fails the server-name check, and test the HELLO handshake against Valkey.
3. Run a Valkey replica in staging. Point it at a copy of the Redis primary with REPLICAOF and soak it under production-shaped traffic for at least one full business cycle. Compare memory, latency and slowlog with the Redis baseline.
4. Switch reads, then writes. Move read traffic to Valkey and hold. Then promote Valkey and move writes. Keep the Redis node alive and unchanged for a defined rollback window.
5. Validate persistence and failover on Valkey. Confirm RDB and AOF write and reload cleanly. Then drill: kill the Valkey primary, confirm promotion, confirm clients reconnect without manual intervention, and time it. Client timeouts during the drill are usually a client setting rather than a server fault; see Redis client timeouts when the server is healthy.
6. Update monitoring. Process names, INFO fields, alert thresholds. Trigger a real alert before trusting the dashboards.
7. Decommission only after the rollback window closes.

There are two rollback boundaries. The first is the moment you start using Valkey-only features or commands. The second is the moment Valkey writes its newer RDB version. After either one, replicating back to Redis is not supported, and rollback means restoring the pre-cutover Redis snapshot and accepting data loss for the interval. Decide in advance when you will cross each one and write the date into the runbook.

We cover the whole path: Redis consulting for the inventory and cutover, Valkey support with 24/7 coverage and a 15-minute P1 response afterwards, and a comparison of Valkey support options if you are still deciding on cover.

Considering a Redis-to-Valkey migration, or want help structuring the compatibility evaluation? AceMQ supports both platforms and can help you make the decision based on your actual workload, not generic benchmarks. We provide enterprise Redis support and Valkey support. Talk to an AceMQ engineer.