Yes, it simply looped over shards, we already had a tool to do that. The app handled it by proxying calls to the new implementation if the shard was marked as

Yes, it simply looped over shards, we already had a tool to do that. The app handled it by proxying calls to the new implementation if the shard was marked as "post-migration", the API stayed the same. If it was "in migration", all write operations returned an error. If the state was "pre-migration", it worked as before. I don't already remember the details but it was something about the event queue or the notification queue which made me prefer this approach over the others. When a shard was in migration, queue processing was also temporarily halted. Knowing that a shard is completely "frozen" during migration made it much easier to reason about the whole process.