Not exactly an SQL database but we were migrating data _constantly_ (dead devices, load balancing, ...) for the data/metadata of an exabyte scale object store..

Not exactly an SQL database but we were migrating data _constantly_ (dead devices, load balancing, ...) for the data/metadata of an exabyte scale object store... Once client code can work with the mixed state (while the migration is in progress) It no longer matters how long it takes. Once the migration is robust enough so it can handle crashes, interrupts, ... it no longer matters how often you trigger the "continue". The migration is using too many iops ? just kill it, schedule a continuance later. Also, your smallest step needs to be an atomic multi-update (you don't want to bother with partial failures)