Ronald is right, you can do this migration with barely any downtime actually.
The only things that should change in active domains on a regular basis is database contents, and maybe home directory contents (mostly emails, possibly web files if people/admins upload stuff).
You can install and prepare the new server with Virtualmin like ronald explained, and ship it to the datacenter without taking the old server offline. Then you make Virtualmin backups of the old server (excluding home directories), again without taking it down. Restore those backups to the new server.
Then you do an rsync of all home directories, still without taking the old server down. Rsync can be done on a live system without problems. If files change during the sync, a subsequent run will pick those up.
Then, and also during previous steps, you check if config and restore on the new server are okay.
Only then you take down the old server, and do another Virtualmin backup all of the databases only, and restore those to the new server. Should not take more than a few minutes, since DB contents are usually small compared to home directory.
Then, with the old server down, you do another home directory rsync to pick up files that were changed during the “big sync”. No need to fiddle with home directory names like “/home2” there to not confuse VM.
You can even “rehearse” those steps that mean actual downtime, by doing them with the old server still online. The process will work regardless, only with the distinct danger that DB contents or files change during the transfer.
Check if everything is okay on the new server, then redirect nameserver entries to point to the new server. Oh by the way, one day before the migration you should set the TTL of your domains to like a minute, so that DNS propagation delay won’t spoil your nice almost-no-downtime scheme.