Your In-Memory Data Should Go Where You Want It
BetterDB's migration tooling gives you a complete picture before you move a single key -- and confirms the picture after.
In March 2024, Redis changed its license. The community forked it as Valkey. That was supposed to be the messy part.
Then Redis 7.4 shipped in August 2024 and bumped the RDB persistence format from version 11 to version 12. Anyone running Redis 7.4 or later who tried to migrate to Valkey by copying their data files hit a hard stop: "Can't handle RDB format version 12." Redis 8.0 followed in May 2025 and folded eight previously proprietary modules - JSON, TimeSeries, Search, Bloom filters - directly into core, adding over 150 commands Valkey does not have. The gap that started as a licensing dispute became a technical one.
The tools that were supposed to help people move between the two are gone. RIOT - the only widely-recommended open-source migration utility - was archived in October 2025. Its replacement is closed-source, enterprise-only, and explicitly targets Redis Cloud only. No Valkey support. If you are on Redis 7.4 or later and want to move to Valkey, or vice versa, the tooling ecosystem largely left you on your own.
BetterDB ships migration as a first-class feature inside the monitor. It works across Redis and Valkey, in any direction, between any providers. Here is what it actually does.
The scenario it is built for
The divergence between Redis and Valkey is real and it cuts in both directions. Some teams are on Redis 7.4 or later and want to move to Valkey - either to escape the license terms or because their cloud provider now defaults to it. Others are on older Valkey builds and want to move to Redis for the module ecosystem. Some are consolidating across clouds entirely, with no interest in changing protocols at all.
BetterDB handles all of it:
- Redis to Valkey, any version combination
- Valkey to Redis
- Cloud to self-hosted - ElastiCache, MemoryDB, Redis Cloud, GCP Memorystore to your own instance
- Self-hosted to cloud
- Cloud to cloud, across providers
No other tool covers this matrix today. The ones that did are gone or locked to a single vendor.
Phase 1: Know before you move
Migration starts with analysis, not transfer. You pick a source connection and a target connection, choose a sample size, and BetterDB scans your keyspace across all cluster nodes.
The output covers what actually breaks migrations in practice:
Compatibility checks. Ten rules that flag blocking issues - things like Valkey HFE data moving to Redis (which has no per-field TTL support), module mismatches between source and target, cluster-to-standalone topology changes, multi-database sources going to cluster targets, ACL differences, eviction policy conflicts, and persistence mode gaps. You get a green, amber, or red verdict before touching a single byte of production data.
Data type breakdown. Key counts and estimated memory per type - strings, hashes, lists, sets, sorted sets, streams. Useful for capacity planning on the target side.
TTL distribution. How many keys expire within the next hour, 24 hours, 7 days, or never. Short-lived keys need different handling than persistent ones.
Hash field expiry detection. Valkey 8.1 introduced per-field TTLs on hashes. If your source has them and your target is Redis, that is a hard blocker - and BetterDB will tell you up front.
Top commands. Pulled from the commandlog or slowlog so you understand the actual workload profile before the migration runs.
The report exports as JSON or PDF. You get a green, amber, or red verdict before touching a single byte of production data.
Phase 2: Move the data
Execution offers two modes depending on your situation.
RedisShake mode spawns the RedisShake binary for fast DUMP/RESTORE-based transfer. It is the right choice for same-protocol migrations where speed matters and the versions are compatible.
Command-based mode operates in-process, using the optimal native command per data type - GET/SET for strings, HSCAN/HSET for hashes, LRANGE/RPUSH for lists, and so on. It understands your data structure and picks the right read and write strategy for each type automatically. This is what makes cross-version and cross-protocol migrations possible where binary-level tools fail. Redis 7.4 changed the RDB format in a way that breaks direct file transfer to Valkey. Command-based mode sidesteps that entirely - it speaks both sides' languages at the command level, not the file level.
Both modes calculate and surface real-time progress - transferred key counts, skipped keys, estimated completion, and a live log viewer. A stop button triggers safe cancellation at any point. Credentials are automatically detected and redacted from all log output before it reaches your screen.
Compound types - hashes, lists, sets, sorted sets, and streams - are written to a temporary same-slot staging key first, then atomically renamed to the final key in a single operation. Your target instance is always in a consistent state. Readers never see partial data, even mid-transfer.
Phase 3: Confirm it worked
Validation runs post-migration and checks three things.
Key count comparison. DBSIZE on both sides. Any discrepancy over 1% gets flagged.
Sample spot-check. A configurable number of random keys with binary-safe value comparison - type match, full content match for small keys, element count for large keys.
Baseline metrics. The target's current ops/sec, memory usage, fragmentation ratio, and CPU are compared against the source's pre-migration baseline snapshots. You can see at a glance whether the target is performing as expected or has drifted.
The result is a pass/fail verdict with a breakdown of anything that did not match.
Cluster support throughout
All three phases handle standalone and cluster topologies. Analysis and execution connect to each master node individually to avoid cross-slot errors. Cluster topology is discovered automatically via CLUSTER NODES.
Your historical data makes the decision for you
Because BetterDB continuously monitors both your source and target instances, the performance history of each is already there when you need it. After a migration, you are not guessing whether latency went up or ops/sec dropped - you have the actual before and after, side by side. If something looks wrong, the decision to revert is based on data, not instinct. And if you do need to roll back, you can run the migration in reverse from the same interface, the same way.
Why this matters now
Redis and Valkey are now genuinely different products. The RDB format split means you cannot simply copy a data file between them. The feature gap from Redis 8.0 means your compatibility check needs to catch commands that exist on one side and not the other. The tooling that used to bridge this is gone.
The clouds are not going to build this. AWS and GCP have no incentive to make it easy to leave their managed Redis or Valkey offerings. Redis Inc. has no incentive to make migration to Valkey easy. Valkey's tooling ecosystem is still young.
BetterDB's migration is the only open tool that works in both directions, across both protocols, and across all providers. The analysis phase flags the exact incompatibilities that the Redis/Valkey divergence introduced. The command-based execution mode bridges version gaps that binary-level tools cannot. The validation phase confirms your data arrived intact before you cut over.
BetterDB's migration feature is available now.
Run with Docker or start instantly with npx @betterdb/monitor.
If you run into any issues, or have a too complicated setup, reach out to me directly to discuss and help you — kristiyan@betterdb.com