Email Migration without Downtime

I have been assigned a task by the big boss to do our company’s email migration without any downtime. Downtime in this case is refer to the time when MX record pointing propagates around the world to the new server. It could cause your emails to be sent to the old server, instead of the new server until the client DNS server clear their DNS cache of the host record.

To achieve this, we need to have a server in between to be the store-and-forward mail server aka backup MX server. Point the MX record to this server and then we change the forwarding IP from old server to the new server. So every new email will be sent directly to the new server without any propagation delay. Following picture shows what will be happened when migrating email server:

I am using following variables:

Backup MX Server: 211.44.22.100
Backup MX OS: CentOS 6.2 64bit
Old mail server: 182.22.60.20
New mail server: 60.1.222.100
Domain: mygreek.biz

Backup MX server

1. To eliminate DNS propagation during migration, we will need to setup a backup MX server at least 3 days before the migration been scheduled. We will use Postfix, a mail transfer agent to serve as store-and-forward mail server. Install Postfix via yum, turn off sendmail and SELINUX:

$ setenforce 0
$ service sendmail stop
$ chkconfig sendmail off
$ yum install -y postfix

2. Edit /etc/postfix/main.cf using text editor as below:

myhostname = forwarder.mygreek.biz   #server hostname
mydomain = localhost
myorigin = $mydomain
inet_interfaces = all                #listen to all available IPs
mydestination = $myhostname, localhost.$mydomain, $mydomain
mynetworks_style = host
relay_domains = mygreek.biz
transport_maps = hash:/etc/postfix/transport

3. Open /etc/postfix/transport to setup the forwarding for relayed domain. Point it to the old server:

mygreek.biz smtp:[182.22.60.20]

4. Activate the Postfix map, start the Postfix service and enable the service on boot:

$ postmap /etc/postfix/transport
$ chkconfig postfix on
$ service postfix start

Backup MX should able to receive and forward emails to the old mail server now. Dont forget to allow port 25 via IPtables so Postfix can run smoothly.

MX record in NS

Once the backup MX server ready, we then need to update the MX records in the name server. Login into the name server and update the MX records and point it to this backup MX:

mygreek.biz.    MX    10    mail.mygreek.biz.
mail             A          211.44.22.100

Make sure you are doing this at least 3 days before the migration start to avoid DNS propagation affect the migration.

Migrating Email

1. Before we start the migration, we will need to stop old server mail service. Since the old server is using cPanel, I will need to stop and disable Exim service so backup MX can take over to store the email in queue until the new mail server up:

WHM > Service Configuration > Service Manager > Unchecked “Enabled” and “Monitor” for Exim > Save

2. I will use cPanel migration utility called “Copy an account from another server”. Just follow the wizard and wait until the account copy complete.

3. Once the email migration completed, we then need to update the forwarding IP in the backup MX to the new server. Login into the backup MX server and edit /etc/postfix/transport:

mygreek.biz smtp:[60.1.222.100]

Then, update the Postfix mapping and restart the service to push the emails in queue to the new mail server:

$ postmap /etc/postfix/transport
$ service postfix restart

In new server, you will notice that you will start to receive emails which already in queue from backup MX server. This will guarantee no lost email and eliminate email being sent to the old server.

Completing the Migration

Monitor the email flow for a while and make sure all emails are delivered to the recipient respectively. If everything run smoothly, it is time to update the MX record and point it to the new mail server so we can remove the MX backup server later:

mygreek.biz.    MX    10    mail.mygreek.biz.
mail             A          60.1.222.100

Please allow the MX backup server to run at least 3 days to make sure new MX has propagated around the world. To double confirm on this, you can use this website to check whether your mail host has been propagated or not:

http://www.whatsmydns.net/

If everything run smoothly, you can shut down and remove the backup MX server and migration consider completed.

5 thoughts on “Email Migration without Downtime

  1. Great Post! if i know it before a week i prevent all this issues with MX records from old to new server..

    Anyway.. is on my bookmarks now for the next domain migrate..

    Thanks mate.

    P.S.
    I try to post system with facebook connect option above and print me the error bellow. Maybe you wand to check this out.

    Fatal error: Uncaught exception 'Exception' with message 'Facebook needs the CURL PHP extension.' in /home/seca/public_html/wp-content/plugins/social-connect/facebook/facebook.php:4 Stack trace: #0 /home/seca/public_html/wp-content/plugins/social-connect/facebook/callback.php(3): require_once() #1 {main} thrown in /home/seca/public_html/wp-content/plugins/social-connect/facebook/facebook.php on line 4

    Reply

    1. Thanks for let me know the bugs in this website. I’ll fix it later on the errors.

      Reply

  2. Hi,

    Why not just change the MX record of the old server to point to the new server and then stop the old mail server?

    Would not emails arriving there fail, causing the sender to refresh the MX and get redirected to the new server?

    Is there something I am missing here?

    How is this any different then a sender using an deprecated cached MX, failing and refreshing the MX?

    Only questions? 🙂

    Regards,
    Gabriel

    Reply

    1. In our environment, we are having a large number of email coming in per minute and we are sharing several domains in one mail server. Removing the domain, reconfigure the mail server and restart the service will required several minutes and this can surely cause us to lost some emails. This is some of the best way to migrate email considering any ‘downtime’ associate with it which can be countered.

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *