Nobody wants to be the person who signed off the cutover that took the business offline on a Monday morning. The simplest way to avoid that is to not have one big cutover at all.
Lower your DNS TTL a few days early
Every DNS record has a time-to-live (TTL) that tells the rest of the internet how long to cache it. Plenty are set to a day or more. Switch servers with a 24-hour TTL and some customers will keep landing on the old server for a day. Rolling back is just as slow.
Drop the TTL to five minutes a few days before the move. Once the new environment has been stable for a while, put it back up.
Copy the data first, then keep it in sync
Set up the new database as a replica of the old one and let them run side by side. Most mainstream databases support this, either through built-in replication or a managed migration service from your cloud provider.
That gives you days or weeks to test against real data while nothing changes for users. On the day, the final sync takes minutes.
Decide where the data lives
POPIA doesn't ban storing personal information outside South Africa, but it does put conditions on cross-border transfers. AWS (Cape Town), Microsoft Azure (Johannesburg and Cape Town) and Google Cloud (Johannesburg) all run local regions now, so keeping data in the country is usually easy. Your local users get faster response times as a bonus.
Write the rollback plan before you need it
Agree in writing what would make you roll back, and who makes that call. Then keep the old server running, untouched, for at least two weeks.
Switching it off early to save a month of hosting is a false economy.