Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Our web site and email is currently hosted by a shared hosting service. We'll be moving both of those to a VPS soon, and I'd like to make sure that we experience as few delays as possible, and no lost email while we do so. I'm a developer playing server admin, so I have basic knowledge of this stuff, but not much more than that.

Our old server is on shared hosting, which we access via a cpanel account, and the new server is running WHM, under which we can create as many cpanel accounts as we want. Here's what I'm currently thinking will be the simplest way of doing it:

  1. On the new server, set up a subdomain specifically for email, or similar. Set up A records in the DNS so that domain is completely handled by the new server, and wait for the TTL to expire.
  2. On the new server, set up duplicate email accounts for all our users on
  3. On the old server, set the MX record for to indicate that email for this domain is handled by, and set it to be a "remote mail exchanger" so it won't save the email locally.
  4. Tell all our users that they should now use for their email. As soon as the new MX records are picked up, email should start being delivered to the new accounts.
  5. Before we fully transition to the new server, ensure that its MX records are set up to use for email as well. That way, regardless of whether you access the old or new server during the transition, you're always sending mail to the new server.

Are there any fundamental misunderstandings in the above? Is there a better way to ensure we don't lose emails and mitigate delivery time issues?

Thanks for your help.

share|improve this question
up vote 2 down vote accepted
  1. Set up the new server to handle email for your existing domain name. There's no need to set up a sub-domain.

  2. Lower the TTL on your MX record to 1 hour.

  3. At a time of your choosing, change the MX record to "point" to the new server. During the next hour, email will arrive at both servers.

  4. Wait several hours then export the email from the old server and import it to the new server.

  5. During the transition, your users can check email at both servers. My suggestion would be that they configure their email client for the new server and use webmail to check the old server (assuming webmail is an available service at the old server).

A. You're not going to lose email. Email will be received at both servers during the transition.

B. Email servers don't generate NDR's after a single failed attempt to deliver an email. Furthermore, since neither your old server or new server will be offline during the transition, there should be no failures to send email to your users. Email will arrive at one server or the other.

C. There are no "delivery time" issues. Email will be received at both servers during the transition.

share|improve this answer
Regarding #3 - unfortunately the new server doesn't have a hostname (or rather, the hostname is going to be the hostname currently used by the new server). I don't believe MX records can point to an IP address, correct? – Colen Nov 20 '13 at 23:21
Then the same steps would apply except you would modify the A record instead of the MX record. Step 2 becomes "Lower the TTL on your A record to 1 hour". Step 3 becomes "At a time of your choosing, change the A record to "point" to the new server". – joeqwerty Nov 20 '13 at 23:35
Changing the A record would mean that web access goes to the new server too, right? Rather than the old one? – Colen Nov 21 '13 at 16:46
Possibly. How about giving us the domain name so that we can take a look at the existing DNS records. – joeqwerty Nov 21 '13 at 16:50
Based on how the MX and A records for the domain is set up, changing the A record would also affect the web site. – joeqwerty Nov 21 '13 at 20:25

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.