Cut over: migrate from Azure Cache for Redis 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. On Basic, or with an exported file, plan a write freeze that covers the copy.
  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 Azure: stop the writers or put the application in maintenance.
  5. Let the last changes arrive, stop the copy tool, and run the verify script: the counts should match exactly.
  6. Rebuild search indexes and time series settings if you have them.
  7. Switch the application to KiviDB and start it. Watch errors and latency.
  8. Turn keyspace notifications back to what they were.

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

  • the Azure cache 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 the Azure cache current until you are sure: have the application write to both for a while after the switch (reads from KiviDB), then stop writing to the Azure cache once you no longer need the way back. For a cache the application can rebuild, there is nothing to copy back: point it at the Azure cache again and let it fill.