When to migrate Redis and which method to choose
Redis gets migrated when you switch hosting providers, upgrade a server, or move from a shared plan to a VDS. The right method depends on whether you can pause the application for a few minutes and how much data the database holds.
There are three working options: an RDB snapshot, an AOF log, and live replication via replicaof. For a database under 1 GB, an RDB snapshot works fine. For databases with stricter durability requirements, use AOF. If downtime is not acceptable, migrate through replication.
Migrating with an RDB snapshot
RDB is a binary dump of the entire database into a single file, dump.rdb. This method works if you can pause writes for 1-2 minutes.
On the old server, force a snapshot save and copy the file:
redis-cli -h 127.0.0.1 -p 6379 SAVE
scp /var/lib/redis/dump.rdb root@newserver:/var/lib/redis/dump.rdb
Redis on the new server must be stopped while the file is being copied, otherwise the process will overwrite it with its own snapshot on the next save. The file path is set by the dir and dbfilename directives in redis.conf.
Migrating with the AOF log
AOF logs every data-changing command to a file, appendonly.aof. Migrating through AOF loses less data than RDB, because the log can be synced to disk every second.
Enable AOF on the old server in advance, wait for a rewrite, and copy the data directory:
redis-cli CONFIG SET appendonly yes
redis-cli BGREWRITEAOF
rsync -avz /var/lib/redis/appendonlydir/ root@newserver:/var/lib/redis/appendonlydir/
After copying, set appendonly yes in redis.conf on the new server and start the service — Redis will rebuild its state by replaying the log.
Live migration with replicaof
The replicaof command (called slaveof in older versions) turns the new server into a replica of the old one. Data copies automatically, with no application downtime.
redis-cli -h newserver -p 6379 REPLICAOF oldserver 6379
redis-cli -h newserver -p 6379 INFO replication
Wait for the master_link_status:up line and matching master_repl_offset values on both sides. Then switch the application to the new address and disable replication with REPLICAOF NO ONE.
Migrating a Redis Cluster
In cluster mode, you cannot simply copy a single dump.rdb — data is split across 16384 hash slots between nodes. Add new nodes to the cluster with redis-cli --cluster add-node, then redistribute slots with redis-cli --cluster reshard.
| Parameter | RDB | AOF | replicaof |
|---|---|---|---|
| Downtime | 1-2 minutes | 1-2 minutes | near-zero |
| Data loss risk | medium | low | minimal |
| Suitable for a cluster | no | no | yes |
Verifying data after migration
Compare key counts and control values on both servers:
redis-cli -h oldserver DBSIZE
redis-cli -h newserver DBSIZE
redis-cli -h newserver INFO keyspace
Check the TTL of expiring keys — when migrating through RDB or AOF, the relative time-to-live of a key is preserved correctly. The full procedure for a final site check is described in the post-migration checklist.
Summary: Redis migration checklist
- Decide on the acceptable downtime and choose RDB, AOF, or replicaof.
- Record the Redis version — migrating between 6.x and 7.x works fine, but check capabilities in advance.
- Migrate the
redis.conffile separately instead of relying on default values. - Compare DBSIZE and key counters on the old and new server.
- Update the connection address in the application and take the old server out of the load only after verification.
If you are also migrating a MySQL database or a document store like MongoDB alongside Redis, plan the migration window around the slowest component.