Server migration is a problem common to all network services–not just virtual hosting. And the solution is the same across all of them. And you’re probably not going to like some aspects of the process (because they take time, and I know you’re in a hurry to get migrated). That said, see the steps at the end of this message for the “fast and painless” migration process you were looking for–but read the rest of this for why it probably won’t actually be painless for everybody.
First thing necessary is to plan ahead (d’oh! Nobody ever does…I’ve forgotten to do this step too.)
Before a server migration takes place, if you want to insure zero downtime and be able to make a “hard” switch between the two servers (i.e. one goes down, the other comes up), you have to shorten your DNS TTL times. 30 or 60 seconds is the norm when preparing for a migration. This needs to happen a few days before the actual move. Why, you ask? Because DNS is a caching protocol, and the vast majority of DNS servers on the internet that have queried your domains already have cached the old IP address and won’t be checking it again for some period of time. This is, of course, assuming that all name servers on the internet are configured according to RFCs and will actually obey TTL when caching addresses–some do not.
Ok, so assume we don’t have the luxury of a few days to make this change, and we want those users stuck behind misbehaving name servers to get the new server too…What next? Actually, we simply need those few days if service isn’t to be interrupted. There’s no way to avoid it. But we can get everyones mail and web requests going to the right place, even before all of the DNS info propogates.
We can proxy all web requests to the new server and relay all mail to the new server. However, it also requires your old server to keep running for a few days until DNS caches refresh with the new data. D’oh! We just keep coming back to that planning ahead thing, don’t we?
In reality, if you update your registrar(s) for your domains to point to your new name server, the majority of requests and messages will find the new server within 24 hours (and quite a few will begin within 8 hours or less–so things need to be working right before you make the change, even if you know it’s going to take a while to propogate).
If you can stand 8 hours of downtime for some users and 24 hours of downtime for the majority of users, and no more than three or four days of downtime for all users, then just moving the registrar pointer to your new server will work fine. If these times aren’t acceptable (and in most cases they aren’t), you’ll have to setup proxying for the web requests and relaying for email on the old machine, and then update your DNS on the old machine to point to the new server, and then update your registrar(s) to point to your new name server(s).
Proxying is done in Apache using the ProxyPass and ProxyPassReverse options:
ProxyPass "/" "http://new.domain.com/"
ProxyPassReverse "/" "http://new.domain.com/"
Where new.domain.com is simply and alias you’ve created on the new server for this purpose–the tricky bit here is that this DNS information needs to be configured on the old DNS server (probably your old hosting server)…Because Apache on the local machine will get its information from the local name server (you could alter it, but things get scary when you start changing a lot of stuff).
Relays are similar. You’ve already created new.domain.com DNS records, which points to the new server. You can use it for relaying explicitly, or you can modify your MX host entries on the old machine to point to this new address. This will, if configured correctly, relay all mail to the new machine.
Migrations aren’t easy, and there’s very little Virtualmin can to do ease the task, beyond bring the data over (and we’re working with you make sure your old cPanel server data has made it over OK)–all of the work happens on your old machine and at your registrar(s).
Documentation would be good. I don’t know of any good source for this information–it is specific to the mail server and web server on the old machine, not to Virtualmin. But it’s probably worth spending some time on, as soon as I find some to spare, as it would make it easier for folks to know what the steps are.
Anyway, if you want easy and to hell with those poor slobs behind badly configured name servers, here’s what you do:
Lower the TTL for all domains on your old machine to 30 seconds.[/]
Wait two days.[/]
Point the old name server entries–all of the records for all of the domains–to the new machine.[/]
Wait another few hours.[/]
Update your registrar(s) with the new machine IP.[/]
Wait until this update actually takes place (check using "whois domain.name").[/]
Shutdown the old machine. Field two or three queries from the aforementioned poor slobs explaining that their ISP sucks, but they can get to you by querying a new name, like new.domain.com (which you create before-hand on the new server, or on an as-needed basis, your call).[/]
You’re done. Mostly painless, and it only took two days plus a few hours. Everyone except those with bad ISPs (more than you think, but few enough to where most folks can live with it) will not notice any downtime.