Cut over: migrate from Redis Cloud to KiviDB

Cut over. Migrate to KiviDB: Move from Redis, Valkey, ElastiCache, Redis Cloud, Aiven, Aerospike, Hazelcast and more: getting the data out, loading it, cuttin

  1. Rehearse a full copy into a test KiviDB; run your tests and the verify script. Time it.
  2. Start the long copy with keyspace notifications on: RedisShake with ksn = true, or RIOT with --mode LIVE. Leave it running.
  3. Check it has caught up: run the verify script while it runs. Only keys being written at that moment should differ.
  4. Stop writes to Redis Cloud: stop the writers or put the application in maintenance. To enforce it, give the application's role a read-only Redis ACL rule (+@read ~*) under Data Access Control.
  5. Let the last changes arrive, stop the copy tool, run the verify script: the counts should match exactly.
  6. Rebuild search indexes (FT.CREATE) and time series labels if you have them.
  7. Switch the application to KiviDB and start it. Watch errors and latency.

Rolling back. Decide how you would go back before you switch, because copying data from KiviDB back to Redis Cloud is limited today:

  • Redis Cloud refuses KiviDB's DUMP payloads, so RedisShake and RIOT's default mode copy nothing in that direction.
  • RIOT with --struct does work, but only from a KiviDB database with Lua turned on (RIOT reads through Lua scripts; on KiviDB Cloud, Lua is chosen when the database is created). It leaves stream consumer groups and per-field hash TTLs behind, and its exit code is 0 even when it fails, so read its output.

The dependable rollback is to keep Redis Cloud current until you are sure: have the application write to both for a while after the switch (reads from KiviDB), then stop writing to Redis Cloud once you no longer need the way back. For a cache the application can rebuild, there is nothing to copy back: point it at Redis Cloud again and let it fill.