MigrateRedis to Valkey
Move data between Redis, Valkey, KeyDB, and Dragonfly - cloud to self-hosted, self-hosted to cloud, or cloud to cloud - with pre-migration analysis, live replication, and post-migration validation.
Four stages, and nothing moves until you approve
Configure both endpoints, analyse the source read-only, approve the copy, and verify the result - the same four stages you run in BetterDB Monitor.
Analysis samples keys with SCAN and never writes to either instance. The copy starts only after you review the findings and approve it.
Pre-migration analysis
A read-only readiness report that tells you what will happen before you start. Keys are sampled with SCAN - nothing is modified on either instance.
Data-type and memory breakdown
Key counts by type (string, hash, list, set, sorted set, stream), memory distribution, and total dataset size. Know what you are moving and how much space the target needs.
TTL distribution
Breakdown of keys by remaining TTL, including keys expiring within the next hour. Helps you decide whether to migrate volatile data or let it expire before cutover.
COMMANDLOG behavioral analysis
Scans command history for engine-specific commands that may behave differently on the target. Surfaces usage patterns that could break after migration.
HFE detection
Detects Hash Field Expiry usage on the source instance and flags it in the report. Per-field TTLs are not preserved in command mode, so the report warns you when HFE is present so you can plan accordingly.
Compatibility findings, ranked by severity
Every difference between source and target is reported as blocking, warning, or info - missing modules, cluster to standalone moves, multi-database keyspaces headed to a cluster, server-side functions, eviction-policy and ACL differences. Blocking issues stop the migration before it starts.
Cluster-aware analysis
On clustered sources the analysis connects to every master and sums key counts and memory across shards, so the report covers the whole keyspace - standalone, Sentinel, and Cluster alike.
The report ends with a safety verdict - blocking issues and warnings counted - and recommends the migration mode (snapshot or continuous replication) based on what the analysis found.
Live migration with continuous replication
Snapshot, continuous sync, or cross-engine command replay - writes continue on the source, and nothing is copied until you review the findings and approve.
Snapshot (RDB) mode
Full dataset transfer via RDB dump. Suitable when you can accept a brief window where the target may lag behind the source.
Continuous replication (PSYNC)
Initial snapshot followed by ongoing replication of writes. The source stays live during sync. Cut over when the replication lag is acceptably low, and roll back if needed.
Command mode (cross-engine)
In-process replay of keys and values over plain commands - no dump-format compatibility required between source and target. The mode that works when engines disagree. Per-key TTLs are preserved atomically, and the readiness report flags what this mode can't preserve (like per-field hash TTLs) before you commit.
Topology support
Standalone, Sentinel, and Cluster topologies on both source and target.
Older engines and forks
Redis versions before 7 and KeyDB are supported as sources - BetterDB probes INFO section-by-section so older engines that predate modern INFO behavior still analyze and migrate cleanly.
Cutover and rollback
When replication is caught up, cut traffic to the target. If something is wrong, roll back to the source while it is still live.
Post-migration validation
Verify the target matches the source after cutover.
Key counts and sampled values
Compares key counts between source and target, then spot-checks a random sample of keys - types and values compared byte-for-byte, element counts for very large keys. The check passes only with zero issues and under 1% count discrepancy.
Health verification in Monitor
After cutover, BetterDB Monitor tracks the target instance the same way it tracked the source - slowlog, latency, memory, and client metrics - so you can confirm the new instance is healthy under production load.
Why not RIOT?
RIOT (Redis Input/Output Tools) was the standard open-source migration path for years. It was archived and replaced by RIOT-X, which is closed-source, enterprise-only, and has no Valkey support. BetterDB Monitor is the open-source alternative - browser-based, no binary to install, no license key.
In March 2024 Redis Ltd. changed the Redis license from BSD to a dual SSPL/RSAL model, which is why teams are evaluating Valkey - the BSD-3-Clause fork maintained by the Linux Foundation.