Email migration, nice, controllable and relaxed


  • you own
  • your new host will be
  • you will have to be able to authenticate with credentials that allow you access to the users’ mailboxes to grab their mail items (whether this be through each of their users, or your user)

1) Create “a DNS sub-domain name” for the new host

I know this doesn’t really make sense, but might be useful to some people

2) Create an MX record for that mirrors the MX for

This info is usually given to you by your vendor as what you should change the MX for to.

nslookup -type=mx

noting it’s the same as:

nslookup -type=mx

3) Create an MX record for that mirrors the (existing) MX records for

nslookup -type=mx

noting it’s the same as:

nslookup -type=mx

4) Create all the mailboxes for all of your users on

5) Create a spreadsheet with the following info to help you track and get organized.

user, password, implemented: hostedexch user-based incoming routing rule to, started: first imap sync, finished: first imap sync, scheduled to move at..., user is ready? you've communicated?, removed: hostedexch user-based incoming routing rule to, implemented: (old/existing) server user-based incoming routing rule to, started:second imap sync, client(s) configured

This is quite a good way to track your progress throughout the migration. It is also a brief list of the following steps.

6) Collect users and passwords or grant yourself access to the users email.

Many organizations allow their users to set their own passwords, and keep this data as secure as any other secure information. There is no way to perform a migration of the mail items in a centralized, controlled way unless you can authenticate to the mail server and access the target user’s mailbox. Considering an exchange-to-exchange migration or alternates, there may be tools that are best equiped to deal with this situation.

For me, I had all of the user’s email passwords (no complicated ACL system here), and was able to use imapsync.exe.

7) Implement the user-based incoming routing rule on the new server (hostedexch )

For each mailbox (not domain-wide), create an incoming routing rule to “forward” (really route to)

The reason we do this is because when a user has been migrated to hostedexch and attempts to send email to another user that hasn’t yet been migrated; the email will be routed internally by hostedexch to the mailbox in hostedexch, not referring to the MX record for, since is hosted on hostedexch.

Let me translate to something more tangible and use my man <ol>:

  1. has been migrated to hostedexch
  2.’s mailbox exists on hostedexch, but they are not migrated fully.
  3. sends an email to
  4. hostedexch knows that all email addresses that are live on itself, that megolomaniac. So hostedexch routes the email destined for to itself.
  5. little does hostedexch know, you’ve created a user-based routing rule that any email destined for will route to
  6. hostedexch, saddened by the news, looks up the MX record for (which are the old/existing mail server), and then sends the same email destined for
  7. The To: in the header doesn’t change, so doesn’t even noticed that it was sent to They read it and are happy.

The megalomaniacal action of hostedexch is pretty standard for mail servers. Why waste the bandwidth?

8) Note the routing rule in your spreadsheet

9) Start a sync of the mail items from the source server ( to the destination server (hostedexch)

I used imapsync.exe which is pretty solid once tested and tweaked.

10) Note the time the first sync has finished, or just look at the mailbox on hostedexch to see the last mail item.

11) Schedule the move with yourself and add it to the spreadsheet. Tomorrow seems like a good day.

12) Ready? Finish all these steps as quickly as you can!

  1. Tell the user you are going to migrate them.
  2. Remove the user-based incoming routing rule on their mailbox on the new server (since it’s okay for that sociopath hostedexch to put email into their mailbox now, since that’s what the user sees).
  3. Set up the user-based incoming routing rule on the old/existing server. Allow it to keep a copy of new emails. The reason you do this is because the MX records haven’t been changed. So the internet thinks all your domain’s mailboxes live on this old/existing server.
  4. Synchronize the two mailboxes again
  5. Configure their client to hop into the new server.
  6. Verify that all mail is on the new server.
  7. Remove the “keep a copy” flag on the incoming mail routing rule on the old server.

Emails to will be directed to your old/existing server until you change you MX records for in public DNS.

Just kidding about that “as quickly as you can thing.” You can always reconcile the new mail after the user is on their new box.

13) Rinse. Repeat.

14) All done, spreadsheet populated? Change your MX record on public DNS to direct to hostedexch. Delete all the other MX records.

  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: