Migrate from Redis to Valkey: Steps and Compatibility (2026)

Valkey, a recent fork of Redis, aims to continue Redis’s development under a more open governance model, and migrating from Redis to Valkey is surprisingly straightforward for most use cases.

Let’s watch a simple Redis instance serve a GET request and then see how Valkey handles the exact same request.

Here’s a typical Redis setup:

# Start a Redis server
redis-server --port 6379 --save 900 1 --loglevel warning

# In another terminal, connect and set a key
redis-cli
127.0.0.1:6379> SET mykey "hello from redis"
OK
127.0.0.1:6379> GET mykey
"hello from redis"
127.0.0.1:6379> exit

Now, let’s do the same with Valkey. The commands and client interactions are identical.

# Download and build Valkey (example for Linux, adapt as needed)
# git clone https://github.com/valkey-io/valkey.git
# cd valkey
# make
# src/valkey-server --port 6379 --save 900 1 --loglevel warning

# In another terminal, connect and set a key
valkey-cli
127.0.0.1:6379> SET mykey "hello from valkey"
OK
127.0.0.1:6379> GET mykey
"hello from valkey"
127.0.0.1:6379> exit

The core functionality and client-side experience remain the same for basic operations. This is because Valkey’s initial development started from a recent, stable version of Redis, preserving most of its APIs and data structures.

The problem Valkey aims to solve is the perceived shift in Redis’s development and licensing strategy. As Redis moved towards a more restrictive license (RSALv2/SSPLv1) and a centralized development model, the open-source community sought a continuation of Redis under a more permissive license (BSD 3-Clause) and a community-driven approach. Valkey is that continuation.

Internally, Valkey forked from Redis version 7.2.4. This means that all features, commands, and data structures available in that version of Redis are present in Valkey. The primary divergence will occur in new features and development directions that are specific to Valkey’s roadmap. For existing Redis deployments, this fork point is crucial: if your application relies solely on features present in Redis 7.2.4 or earlier and doesn’t depend on any proprietary Redis modules or specific enterprise features, the transition should be seamless.

The migration process typically involves these steps:

Backup your Redis data: Always start with a reliable backup. For Redis, this is usually done via BGSAVE or by copying the RDB/AOF files.
```
# From redis-cli
127.0.0.1:6379> BGSAVE
Background saving scheduled
```
Then locate your dump.rdb file (check redis.conf for dir).
Install Valkey: Download, compile, and install Valkey from its official repositories. Ensure you have the necessary build tools (make, gcc/clang).

Configure Valkey: Create a valkey.conf file, often starting by copying and modifying your existing redis.conf. Most basic directives like port, bind, save, dir, logfile, requirepass are identical.

# Example valkey.conf snippet
port 6379
bind 127.0.0.1
daemonize yes
pidfile /var/run/valkey.pid
logfile /var/log/valkey.log
dir /var/lib/valkey
save 900 1
save 300 10
save 60 10000
appendonly no # or yes, depending on your Redis setup
requirepass your_super_secret_password

Start Valkey: Launch the Valkey server using your new configuration file.
```
valkey-server /path/to/your/valkey.conf
```
Restore data: If you are using RDB snapshots, copy your dump.rdb file to the dir specified in your valkey.conf and restart Valkey. If using AOF, ensure appendonly yes is set in valkey.conf and restart Valkey; it will replay the AOF log.
```
# After copying dump.rdb to /var/lib/valkey/dump.rdb
# And ensuring /var/log/valkey.log is writable
valkey-server /path/to/your/valkey.conf
```
Update client configurations: Modify your application’s connection strings or configuration files to point to the Valkey instance, if it’s on a different host/port, or if you’re using a new client library that specifically mentions Valkey (though most Redis clients work out-of-the-box).
Test thoroughly: Run your application’s test suite and perform manual testing to ensure all functionalities work as expected. Pay attention to any specific Redis commands or modules you might be using.

The most common compatibility concerns arise from:

Redis Enterprise Features: Any features specific to Redis Enterprise (like RediSearch, RedisJSON, RedisGraph, RedisTimeSeries, RedisGears) that are not open-sourced or are under different licensing will not be available in Valkey. If your application depends on these, you’ll need to find open-source alternatives or stick with Redis Enterprise.
Recent Redis Features (Post 7.2.4): If you’re migrating from a very recent Redis version (e.g., 7.4.x or newer) and are using features introduced after the 7.2.4 fork point, those specific features might not be in Valkey yet. Check the Valkey roadmap and release notes for their inclusion.
Client Libraries: While most Redis clients are compatible, some might have hardcoded checks for "redis" or specific versioning. It’s good practice to ensure your chosen client library supports Valkey or is generic enough.

A subtle point often missed is how Valkey’s MODULE_LOAD directive works. While it functions similarly to Redis, the paths to modules might need adjustment if you’re migrating from a Redis Enterprise environment where modules are installed in specific Redis-managed locations. For standard, open-source Redis modules, the path to the .so file is usually the only thing that needs updating in valkey.conf if your installation directory changes.

The next challenge you’ll likely encounter is understanding Valkey’s new module ecosystem and how it diverges from Redis modules.

More Deep Dives in Valkey