01
Licence and Decision Review
Which Redis versions you run, which licence each falls under, what your legal and compliance teams actually require, and whether Redis 8 under AGPLv3 or Valkey under BSD fits.
Redis to Valkey Migration
Redis to Valkey Migration: Decide, Test, Cut Over, Roll Back
A Redis to Valkey migration is a licensing and compatibility decision before it is a data move. AceMQ reviews whether you should move at all, tests your real clients, modules and commands against Valkey, then runs the migration with a rehearsed cutover and a rollback you can trust. If Redis 8 is the better answer for you, we say so.
- migration methods: replica, RDB or AOF restore, dual-write
- 3
- highest Redis version Valkey documents full data compatibility with
- 7.2
- min emergency SLA through cutover on a support plan
- 15
Trusted for Mission-Critical Redis by Teams in Finance, Healthcare, Defense, Telecom, and More
Customers
Partners
Is This You?
You probably need this if…
- 01
A licence review flagged Redis 7.4 or later (RSALv2 and SSPL) and someone wants an answer
- 02
You run Redis 7.2 or earlier and the next upgrade would force a licence decision
- 03
Your managed Redis service is changing and a Valkey engine is on the menu
- 04
You depend on Redis search, JSON or time series modules and do not know the Valkey equivalent
- 05
Client libraries, Helm charts, parameter groups and monitoring all say redis, and nobody knows what that touches
- 06
You want to move once, not twice, and you need a rollback your change board will sign
- 07
You want an independent view, from a team that supports Redis Software, Redis Community Edition and Valkey
Outcomes
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.
Before
The question is argued from licence headlines and forum threads.
After
A written decision for your estate: stay on Redis, move to Valkey, or split by cluster, with the reasons.
Before
Compatibility is assumed because Valkey forked from Redis.
After
Your clients, commands, modules and configuration tested against Valkey, with every incompatibility listed and an owner for each.
Before
The cutover plan is a diagram with a hopeful arrow.
After
A method chosen per cluster, a staged cutover, and a rollback that has been rehearsed.
Before
After the move, nobody owns the new platform.
After
Valkey in production with monitoring, runbooks and, if you want it, 24/7 support from the team that did the migration.
Scope
What's covered
- 02
Compatibility Inventory
Data file format by source version, command usage from your own traffic, modules, client libraries, configuration, ACLs, TLS and the tooling that mentions redis by name.
- 03
Method Selection
Replica-based, RDB or AOF restore, or dual-write, chosen per cluster from the source version, size, downtime tolerance and topology (standalone, Sentinel or Cluster).
- 04
Test and Soak
Your application test suite and a replayed load profile run against Valkey in staging, with latency, memory and failover behaviour compared to the Redis baseline.
- 05
Cutover and Rollback
A staged cutover starting with the lowest-risk workloads, with a pre-cutover snapshot and a rollback decision point agreed in advance.
- 06
Handover and Support
Runbooks, dashboards and alert thresholds for the new platform, and optional Valkey support from the engineers who ran the move.
The Engagement
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.
- Phase 1Days
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.
You receive
- Redis estate inventory by version, licence and topology
- Written stay-or-move recommendation
- Scope for the compatibility test
- Phase 21–2 weeks
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.
You receive
- Compatibility report with every issue and its fix
- Performance and memory comparison
- Module decisions: move, replace or keep on Redis
- Phase 3Within a week
Migration Plan
The method per cluster, the order of clusters, the cutover steps and the rollback, written so your change board can approve them.
You receive
- Method and sequence per cluster
- Cutover runbook
- Rollback criteria and procedure
- Phase 4Per cluster
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.
You receive
- 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.
How to migrate Redis to Valkey: 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.
Rule we hold
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.
Customer Success
Real Redis Results
See how enterprises trust AceMQ for their most critical Redis workloads.
Clearing a Redis Memory Leak Without Taking Production Down
Real-Time Screen-Sharing SaaS Platform
Six live sessions over fourteen hours to find why a Redis cluster kept growing past its ceiling, and to stop it without a maintenance window.
RedisRedis SentinelContainersObservability
Middleware Architecture Assessment for Financial Trading
European Online Trading Platform
Independent architecture and performance review of RabbitMQ, Kafka, and Redis for an online trading platform.
RabbitMQ
KafkaRedisRedis Timeout Remediation for Fintech Microservices
Emsyne Technologies
AceMQ diagnosed Redis connection timeout issues causing service disruptions in a legacy fintech platform being modernized, identifying client-side resource exhaustion as the root cause and delivering a remediation plan for high-concurrency caching.
RedisRedis Enterprise Licensing and Architecture on OpenShift
UK Infrastructure Technology Firm
AceMQ advised a UK-based technology firm on Redis Enterprise licensing compliance and architecture validation as they migrated high-volume messaging infrastructure to OpenShift, handling millions of messages daily alongside RabbitMQ.
RedisRabbitMQ
OpenShiftMulti-Technology Support Including Redis for Global Trading Firm
DRW (Global Trading Firm)
AceMQ expanded its enterprise support agreement with global quantitative trading firm DRW to include Redis caching alongside RabbitMQ, providing L3 escalation support across the full messaging and caching technology stack.
RedisRabbitMQRedis Cluster Health and Architecture Assessment
Enterprise Technology Organizations
AceMQ's Redis Health and Architecture Assessment identifies cluster vulnerabilities, performance bottlenecks, and optimization opportunities before they become production incidents — delivering a prioritized remediation roadmap.
RedisRedis as Enterprise Data Layer for High-Throughput Fintech
Financial Services Provider
AceMQ helped a financial services provider architect Redis as a reusable enterprise data layer supporting session management, caching, and real-time data processing across millions of daily transactions.
RedisRedis Integration During Legacy .NET Application Modernization
Banking Technology Services Firm
AceMQ supported the integration of Redis as a modern caching layer during the migration of a legacy banking application from monolithic architecture to microservices, resolving concurrency and timeout issues during the transition.
Redis
FAQ
Questions about Redis to Valkey migration
How do I migrate from Redis to Valkey?
Pick the method by source version. For Redis 7.2 and earlier, either replicate from Redis to a Valkey node with REPLICAOF and promote it, or restore an RDB or AOF file into Valkey. Redis Community Edition 7.4 and later write data files Valkey cannot read, so for those sources we plan on dual-write and a key backfill, and treat replica sync as something to test, not assume. Whatever the method, anyone migrating from Redis to Valkey should test clients and modules in staging and keep a pre-cutover snapshot as the rollback.
Is Valkey compatible with Redis 7.4?
Not at the data-file level. Valkey documents compatibility with Redis OSS 7.2 and all earlier releases, and states that Redis Community Edition 7.4 and later produce data files that are not compatible with Valkey. Commands and clients are a separate question and are tested on your workload. The data move from 7.4 and later needs a different method from a snapshot copy.
Should we stay on Redis 8 or move to Valkey?
It depends on licence requirements and on which Redis 8 features you use. Redis 8 is available under RSALv2, SSPLv1 or AGPLv3, and integrates JSON, time series, probabilistic types and the query engine. Valkey is BSD 3-clause and a Linux Foundation project. Teams that need a permissive licence lean to Valkey, and teams that depend on the integrated modules lean to Redis 8. We review both against your estate.
Do Redis modules work on Valkey?
Modules written to the Redis OSS module API are documented to work in Valkey, but the Redis search, JSON, time series and Bloom modules have no guaranteed drop-in equivalent. Run MODULE LIST on every node, then decide per module whether to move, replace it or keep that cluster on Redis.
What do Valkey migration services from AceMQ include?
A stay-or-move review, a compatibility test of your clients, commands, modules and configuration, a migration method per cluster, a cutover runbook with a rehearsed rollback, and hypercare through the soak period. We work remotely with your engineers. Redis and Valkey support is available afterwards from the same team.
Can we roll back from Valkey to Redis?
Yes, if the rollback is planned. Keep Redis available read-only through the soak period and take a snapshot before cutover. Replication is one-way, so the rollback is a restore from that snapshot plus replay of writes since, not a reversal of replication.
How long does a Redis to Valkey migration take, and what does it cost?
The decision review takes days and the compatibility test one to two weeks. Cutover time depends on cluster count and size. We scope on clusters and complexity rather than data volume, and reply within 1 hour of receiving your cluster count and Redis versions, with a written quote to follow.
Let's talk
Scope Your Redis to Valkey Migration
Tell us which Redis versions and clusters you run, and whether you use modules. We will reply within 1 hour and follow with a stay-or-move view and a written quote.
Get in Touch
Talk to a Redis Expert
Send us a message and we'll follow up within 1 hour — or book a free 30-min consultation directly.
305-204-2607info@acemq.com66 W. Flagler St. 9th Floor
Miami, FL 33130
Miami, FL 33130
Prefer to talk now? Call us directly or use the consultation tab to find a time that works.