Moving to a new instance of ought to be trivial -- send writes to both for a while, once the latest ttl is hit move reads. This does assume you're doing something same like setting short ttls (no more than a day, maybe a week).
Redis isn’t used exclusively as a cache. It’s used a lot as a job queue, as an event bus, for session storage, etc. Some even use it as a core source of truth database, though this is rarely a good idea IMO.
I think each of those is nearly as easy to update, except the source of truth. Probably shouldn't ever go on vacation if redis is your source of truth!
Yeah, agreed, though if you’re using Redis as central pub/sub infra in an environment with tonnes of different services who produce and consume events, a migration can get tedious. Certainly not as bad as traditional DB migrations, but doing it under a short timespan could still be a pain.
Data loss, particularly under high write volume. Partitioning can help. There are a few ways to enable persistence, but you should still treat it like a cache, like you would Memcache or Elasticsearch.