The mechanics are dull, which is good. Copy with rclone, verify checksums, dual-write for a window, cut reads over, decommission after a month.
Two details save you pain. Keep your object keys identical, so the migration reduces to an endpoint and a credential change and rolling back is changing them back. And use on-demand migration if the destination supports it, objects copy the first time they're requested, so you flip the read path immediately instead of waiting on a bulk copy of many terabytes.
The one real cost is getting data out of your current provider. A bulk copy out of S3 incurs standard egress, which on a multi-terabyte bucket is a genuine one-off expense, sometimes more than a year of the destination's storage. Check the current terms for transfers to Bandwidth Alliance partners before you start, and consider on-demand migration precisely to avoid paying for objects nobody ever requests.
Before you commit, run your existing integration tests against a bucket at the new provider. Most applications pass unchanged; the ones that don't usually fail on multipart uploads, ETag semantics or lifecycle rules, and it's much better to learn that in CI.