Migrating from Redis to Valkey
The license-driven migration of the decade. Aiven moved 15,000 servers in three months. AWS made Valkey the ElastiCache default for new clusters. GCP added a separate Memorystore for Valkey product. The technical path is well-trodden and low-risk for typical workloads.
The license trigger
Redis was BSD-licensed from 2009 to March 2024. The March 2024 announcement that Redis was switching to a dual SSPL plus RSALv2 license created an immediate problem for two groups: cloud providers operating Redis-as-a-service (the SSPL's "if you offer the software as a service you must open-source your management stack" clause), and commercial software vendors embedding Redis in products (the SSPL's broader copyleft reach is uncomfortable for proprietary products).
Within a week of the announcement, the Linux Foundation forked Redis 7.2.4 (the last BSD-licensed version) as Valkey, with AWS, Google Cloud, Oracle, Ericsson, and a coalition of Redis-using companies as founding members. The project shipped Valkey 7.2.5 a few months later as a maintenance release of the BSD fork, then Valkey 8.0 in late 2024 with multi-threading improvements, then Valkey 8.1 in early 2026 with memory optimisations.
In May 2025 Redis added AGPLv3 as a third license option (alongside SSPL and RSALv2), making Redis 8.0+ OSI-compliant open source again. AGPLv3 is more permissive than SSPL but still has the network-copyleft clause: if you run a modified Redis as a service, you must publish the source. Many commercial software shops cannot use AGPLv3, so the Valkey choice remains relevant even with the AGPLv3 addition. See the full timeline on /redis-license-timeline.
The technical migration path
Because Valkey forked from Redis 7.2.4 with no intentional divergence in the RESP protocol or in the baseline command semantics, the client-side migration is nil. Existing redis-py, ioredis, StackExchange.Redis, go-redis, Lettuce, PhpRedis client code connects to Valkey and works without modification. The Valkey project has a hard rule against breaking RESP compatibility for the Redis 7.2 baseline, and as of Valkey 8.1 in May 2026 that compatibility has been maintained.
The data migration paths are equally well-understood. The cleanest is replication-based: configure Valkey as a replica of the running Redis instance via REPLICAOF redis-host port, let it sync (initial bulk transfer then incremental), then promote Valkey to primary and update client connections to point at it. Zero downtime, exact data transfer, rollback by switching clients back to the old Redis (which has been receiving the same writes if you keep it as a replica during transition).
For cloud-managed deployments, both AWS ElastiCache and GCP Memorystore offer in-place engine swaps from Redis to Valkey. The operation is a button-click in the console (or an API call) and the managed service handles the underlying mechanics. AWS describes the swap as "no data loss, no extended downtime, retains the same cluster endpoint." Many teams that migrated in 2024-2025 did so using these built-in tools and reported single-digit-minute downtime windows or none at all.
What does not port
The Redis 8.0 vector set commands (VADD, VSIM, VLINKS, VEMB, VRANDMEMBER, VSETATTR, VGETATTR, VTYPE, VINFO) are the headline incompatibility. Valkey 8.1 does not ship vector sets and the project's roadmap targets vector support in a later release without a firm date. If your application uses vector search via Redis 8.0, you cannot migrate to Valkey without rewriting that part of the system, typically to use either a dedicated vector database (Weaviate, Pinecone, Qdrant) or Redis Cloud where the modules are licensed.
Redis 8.0 hash field TTL (per-field TTL on hash keys) is another incompatibility. Valkey 8.1 does not implement it. The workaround is to use multiple hash keys with their own TTLs, or to encode the TTL as part of the value and check it on read. Several other smaller Redis 8.0 features fall in this category.
The Redis modules (RediSearch, RedisJSON, RedisTimeSeries, RedisBloom, RedisGraph, RedisGears) are Redis Inc. proprietary modules under licenses that prohibit competing managed services. They run on self-hosted Redis (under the appropriate license) and on Redis Cloud / Redis Enterprise, but not on Valkey. Valkey's own search module is RESP-compatible but has API differences. If your app depends on a Redis module, plan the module migration separately from the engine migration; the work is meaningful.
The decision rubric
Migrate to Valkey if: your legal or compliance team has flagged SSPL or AGPLv3 as a problem; your cloud bill for managed Redis is a significant line item; you do not use Redis 8.0 features (vector sets, hash field TTL); you do not use Redis Inc. proprietary modules; you want the OSS posture of being on a BSD-licensed store.
Stay on Redis if: you specifically need vector sets (Redis 8.0) or RediSearch (Redis Cloud module); you are running on Azure Cache for Redis Enterprise (the Redis Inc. licensing handles the SSPL question for you); you have a long-running Redis Enterprise contract; your team has invested in tooling and skills around specific Redis Inc. features. The pragmatic choice in many cases is to migrate the parts of the workload that do not use those features and keep Redis for the parts that do.
For most generic production Redis workloads in 2026 (caching, sessions, rate limiting, queues, leaderboards) the answer points toward Valkey. For specialised workloads (vector search, full-text search, advanced graph) the answer points toward Redis or a dedicated specialist store. The decision is rarely all-or-nothing for large applications; the right answer is often a mixed-store deployment where the engine choice is per-workload.
FAQ
Is Valkey a drop-in for Redis?
For the Redis 7.2.4 baseline and below, yes. Valkey forked from Redis 7.2.4 BSD and maintains protocol-level compatibility (RESP). Client code requires no changes. Redis Cluster, Sentinel, RDB / AOF persistence, pub/sub, all data types: identical behaviour. The drop-in story holds as long as you do not need Redis-only features added in 7.4 or 8.0.
What does not port?
Redis 8.0 features that Valkey has not shipped: vector sets (VADD, VSIM), hash field TTL, and several smaller additions. Redis modules (RediSearch, RedisJSON, RedisTimeSeries, RedisBloom) are Redis Inc. products under restrictive licenses; Valkey ships its own search module but the API differs. If your app depends on any of these, the migration is more involved.
Why did Aiven move 15,000 servers?
Aiven was operating a managed Redis service under Redis OSS BSD terms. The March 2024 switch to SSPL meant continuing to offer the same service required either paying Redis Inc., switching to Valkey, or accepting SSPL terms. Aiven chose Valkey and completed the migration in three months. The published blog describes the technical approach (in-place engine swap, no protocol change) and the customer experience (transparent to users).
Should I migrate?
Depends on three factors. (1) License: if SSPL or AGPLv3 blocks you (most commercial shops have this concern), Valkey is the answer. (2) Cost: cloud-managed Valkey is typically 25-35% cheaper than equivalent Redis OSS. (3) Features: if you need Redis 8.0 vector sets, stay on Redis until Valkey ships them. For most production workloads in 2026 that do not need bleeding-edge Redis features, Valkey is the better default.
How does data migration work?
Several paths. (1) RDB snapshot + restore: stop writes, RDB-save on Redis, copy file to Valkey, RESTORE. Brief downtime but exact data transfer. (2) Replication: configure Valkey as a replica of Redis, let it sync, then promote and switch clients. Zero downtime, the protocol is identical. (3) AWS ElastiCache and GCP Memorystore both offer in-place engine swap (Redis to Valkey) as a managed operation with no data loss.