Let me qualify that estimate with "best case data pipes and servers" involved. on TB pipes this is nothing, on GB pipes, pretty quick, on anything else it will depend on your speeds.

To handle with caution.

- do not stop your SQL server on your actual host,

- do not start your SQL server at the new host,

- rsync your database folder from the current host to the new one,

At this point, at your new host you will have a "partially corrupted" data base. Because new transactions, writings, deleting would have occurred during the rsync transfer.

- stop your SQL server at your actual host, (=> downtime)

- rsync again your database,

This second rsync should be very fast, because rsync will just copy the differences, which will fix the data which were "partially corrupted". Since it's going to be very fast, it minimizes the downtime.

- start your SQL server on the new host,

Finished.

edit: some will certainly say it's not good practice, so I makes no warranties, I am just saying this is what I am doing when I change server, with a 300 GB MariaDB database (before MySQL), without problem since 15 years, and when changing server, I have less than 5 minutes downtime of the site.

rsync is not going to work with MS SQL data files.

You *could* setup replication and accomplish something similar to what Dimiti posted, although it gets kind of messy.

What type of writes are being done to the DB? (Is it mostly being used for reads, or do you have a lot of writes as well?)

You can use Rsync to copy the binary files from server to server? This is something I had to do some time ago to back up a 100G+ DB.

Mack.

We ended up just shutting down at 11PM and transferred a complete database.
I feared compromising the integrity of the database.