Copy an Account From Another Server > Express Transfer

[GoWilkes]

So, just how reliable and simple is the "Express Transfer" option, really?

Is it subject to propogation times, or is it going to work immediately for everyone?

I ask because I'm in the middle of a server change. The last time I did this was a nightmare; I had to set up .htaccess proxies for 3 weeks so that people on slow-to-update ISPs would see the site and interact properly. I grew a LOT of gray hair that month, and I'm really not looking forward to the same thing! So if this is the awesome fix that it sounds like (making everyone just magically redirect to the new server seamlessly), it would really make my day.

If it matters, the account I'm transferring has about 100 parked domains, uses about 4G of MySQL data, and about 2G of images (that are uploaded by the user). It also uses PHP and Perl heavily.

 

[cPanelMichael]

Hello

Express transfers are documented here:

cPanel - Express Transfers

The above document includes a list of the actions taken when the express transfer option is enabled. There is no way to guarantee it will work for every domain name unless you verify each domain name uses name servers associated with the source server. The "A" record change in the DNS Zone on the source server is typically reflected right away but you never truly know what type of browser cache settings an end-user might have. It's a good idea to start with a test account and see how it goes before transferring a live account.

Thank you.

 

[Serra]

I've done some testing with this express transfer. It should be called "disable and forward transfer", as there is nothing express about it.

I'm not sold on this transfer method. Here are the changes made to the OLD server:

1. A records (including the A record for ftp) are updated to the new server. This means anyone who goes to the old server after the transfer will end up on the new server magically. Nice.
2. .htaccess is updated to show a site moved message for anyone who is seeing cached DNS.
3. The site is moved from localdomains to remotedomains
4. The site sis added to secondarymx
5. Erases the users email passwords so there is no possible way for the client to login at the old server and verify all mail is move or get mail if they forgot to download it. It also causes errors in the clients email program immediately start issuing password failures.

To undo the move, all of those things must be undone on the old server.

This is very problematic way to move. I can't recommend anyone using this method for any reason. It is simply too ill conceived to be used.

1. It is hard to undo if the move fails, miss one thing and the site is broken.
2. It breaks email for the client if they have a cached DNS (which would be most clients) until their DNS updates. Rather than static routing the mail and letting the client catch up. With a static route, the client checks mail, but on the wrong server. With this method the client gets endless popups that their login is incorrect.

If this method is used and the owner wants to undo this move. Delete the account and restore from a backup!

A better way to do this manually is to do a normal transfer. Then when the transfer is done, edit the DNS entries on the old server and put the A records to the new server. Then setup a static route from the old server to the new server to send mail that arrives at the old server to the new one.

cPanels idea for that also works, but requires another edit, that is move the domain from localdomains to remotedomains. and then set the domain up as a secondarymx. This is a bit safer than a static route.