You probably need this if…
Where you are now, and where you end up
Concrete state changes, not deliverable counts. This is what actually differs about your Redis estate when the engagement closes.
The question is argued from licence headlines and forum threads.
A written decision for your estate: stay on Redis, move to Valkey, or split by cluster, with the reasons.
Compatibility is assumed because Valkey forked from Redis.
Your clients, commands, modules and configuration tested against Valkey, with every incompatibility listed and an owner for each.
The cutover plan is a diagram with a hopeful arrow.
A method chosen per cluster, a staged cutover, and a rollback that has been rehearsed.
After the move, nobody owns the new platform.
Valkey in production with monitoring, runbooks and, if you want it, 24/7 support from the team that did the migration.
What's covered
How it actually runs
Every phase has a defined duration and a concrete artifact handed over at the end of it. You always know what stage you're in and what you've received.
Decision Review
We inventory what you run and walk the stay-or-move decision with your engineering and legal contacts. Delivery is remote and guided by your engineers. We take no access to your systems or code.
- Redis estate inventory by version, licence and topology
- Written stay-or-move recommendation
- Scope for the compatibility test
Compatibility Test
Staging runs against Valkey with your clients and a replayed workload. Modules, client version checks, configuration and monitoring are tested one by one rather than assumed.
- Compatibility report with every issue and its fix
- Performance and memory comparison
- Module decisions: move, replace or keep on Redis
Migration Plan
The method per cluster, the order of clusters, the cutover steps and the rollback, written so your change board can approve them.
- Method and sequence per cluster
- Cutover runbook
- Rollback criteria and procedure
Cutover and Hypercare
Clusters move lowest-risk first. Redis stays available read-only through the soak period, and we stay engaged until the new platform is stable.
- Executed cutover per cluster
- Soak-period review
- Handover pack: runbooks, dashboards, alerts
Stay on Redis 8 or move to Valkey: the licence history in brief
The question exists because the Redis licence changed twice in about 14 months. The facts below are from the projects' own announcements, and they are the starting point for the decision, not the whole of it.
| Project and release | Licence | Source |
|---|---|---|
| Redis 7.2 and earlier (Redis OSS) | BSD 3-clause | Redis announcement, March 2024: releases before the change stay BSD. |
| Redis 7.4 and later (Redis Community Edition) | RSALv2 or SSPLv1 | Redis announcement, March 2024. |
| Redis 8 | RSALv2, SSPLv1 or AGPLv3, your choice | Redis announcement, 1 May 2025: AGPLv3 added as an option starting with Redis 8. |
| Valkey | BSD 3-clause | Linux Foundation, 28 March 2024: Valkey continues from Redis 7.2.4. |
| Situation | Points toward | Why |
|---|---|---|
| Policy requires a permissive licence, and AGPLv3 obligations are not acceptable | Valkey | Valkey stays BSD 3-clause under a foundation. Redis 8 under AGPLv3 is OSI-approved, but its terms need your legal team's review. |
| Production relies on Redis 8's integrated JSON, time series, probabilistic types, query engine or vector sets | Stay on Redis 8, or test first | Redis 8 builds these into the core. Valkey's module ecosystem covers some of the same ground, but each module has to be checked individually. |
| Running Redis 7.2 or earlier, or a managed service offering a Valkey engine | Valkey is low risk | This is the path Valkey documents as compatible, with replica-based and file-based methods. |
| Running Redis 7.4 or later and wanting Valkey | Valkey, with a different method | Redis 7.4 and later write data files Valkey cannot read, so replica and snapshot shortcuts do not apply. |
| Under contract for Redis Software features or vendor support | Stay, review at renewal | A migration changes the support relationship as well as the engine. |
Redis to Valkey compatibility checklist
Redis 7.4 to Valkey compatibility, and every other version pairing, comes down to six checks. Most failures we see are at the edges of the application, not in the commands themselves.
| Area | What to check | What goes wrong |
|---|---|---|
| Data files | Source Redis version. Valkey is documented as compatible with Redis OSS 7.2 and earlier. | Redis CE 7.4 and later produce data files Valkey cannot read, which rules out snapshot copy. Do not assume replica sync works from those sources either: test it first. |
| Commands | Command usage from INFO commandstats on production and the commands your application test suite exercises. | Rarely a core command. More often a rarely used or newer command found only by testing. |
| Modules | MODULE LIST on every node. Modules written to the RedisModule_ API are documented to work in Valkey. | Redis search, JSON, time series and Bloom modules are not guaranteed drop-in. Decide per module: move, replace or keep that cluster on Redis. |
| Client libraries | Whether the client checks the server name or version, or relies on Redis-only features. | A client refuses to connect or silently drops features because it does not recognise the server. |
| Persistence and replication | RDB and AOF settings, replication backlog size, Sentinel or Cluster topology and failover behaviour. | Failover tuned for Redis behaves differently under your real load. Test it rather than assume parity. |
| Operations | Service units, file paths, container images, Helm charts, managed-service parameter groups, monitoring filters on the redis-server process or redis_version. | The application works and the monitoring goes dark, or a deployment still points at the old binary. |
In production migrations we have run, the application layer almost never broke. The failures came from this operational edge, and every one of them is detectable in staging with a proper inventory.
Migration methods, cutover and rollback
| Method | How it works | Best for | Limits |
|---|---|---|---|
| Replica-based | Point a Valkey node at the Redis primary with REPLICAOF, wait for sync, then promote it. | Redis 7.2 and earlier where downtime must be minutes. | One direction only. It is a migration window with a defined end, not a standing link. |
| RDB or AOF restore | Copy a Redis snapshot or append-only file into the Valkey data directory and start it. | Redis 7.2 and earlier where a short write freeze is acceptable. | Writes after the snapshot must be frozen or replayed. Not usable from Redis CE 7.4 and later. |
| Dual-write and backfill | The application writes to both systems while existing keys are copied across, then reads move. | Redis 7.4 and later, cross-service moves, and cases where no snapshot method applies. | Needs application change and a plan for keys that expire or change during the copy. |
Cutover runs from the lowest-risk workload to the highest. Redis stays available, read-only, through the soak period. The rollback decision point is agreed in advance, and a pre-cutover Redis snapshot is the rollback. Once Valkey has written its own newer data format, a Redis node cannot rejoin as its replica, so the rollback is a restore, not a replication reversal.
Never combine a platform migration with a version upgrade in the same production window. If your Redis version has to change first, that is its own change.
Real Redis Results
See how enterprises trust AceMQ for their most critical Redis workloads.
Questions about Redis to Valkey migration
Talk to a RabbitMQ Expert
Send us a message and we'll follow up within one business day — or book a free 30-min consultation directly.
305-204-2607info@acemq.comMiami, FL 33130
Prefer to talk now? Call us directly or use the consultation tab to find a time that works.