Email migration, nice, controllable and relaxed
- you own source.com
- your new host will be hostedexch.com
- 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 hostedexch.source.com
I know this doesn’t really make sense, but might be useful to some people
2) Create an MX record for hostedexch.source.com that mirrors the MX for hostedexch.com.
This info is usually given to you by your vendor as what you should change the MX for source.com to.
nslookup -type=mx hostedexch.com
noting it’s the same as:
nslookup -type=mx hostedexch.source.com
3) Create an MX record for oldmail.source.com that mirrors the (existing) MX records for source.com
nslookup -type=mx source.com
noting it’s the same as:
nslookup -type=mx oldmail.source.com
4) Create all the mailboxes for all of your users on hostedexch.source.com
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 firstname.lastname@example.org, 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 email@example.com, implemented: source.com (old/existing) server user-based incoming routing rule to firstname.lastname@example.org, 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) email@example.com.
The reason we do this is because when a source.com user has been migrated to hostedexch and attempts to send email to another source.com 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 source.com, since source.com is hosted on hostedexch.
Let me translate to something more tangible and use my man <ol>:
- UserA@source.com has been migrated to hostedexch
- UserB@source.com’s mailbox exists on hostedexch, but they are not migrated fully.
- UserA@source.com sends an email to UserB@source.com
- hostedexch knows that all email addresses that are @source.com live on itself, that megolomaniac. So hostedexch routes the email destined for UserB@source.com to itself.
- little does hostedexch know, you’ve created a user-based routing rule that any email destined for UserB@source.com will route to UserB@oldmail.source.com
- hostedexch, saddened by the news, looks up the MX record for oldmail.source.com (which are the old/existing source.com mail server), and then sends the same email destined for UserB@oldmail.source.com.
- The To: in the header doesn’t change, so UserB@source.com doesn’t even noticed that it was sent to UserB@oldmail.source.com. 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 (source.com) 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!
- Tell the user you are going to migrate them.
- 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).
- 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.
- Synchronize the two mailboxes again
- Configure their client to hop into the new server.
- Verify that all mail is on the new server.
- Remove the “keep a copy” flag on the incoming mail routing rule on the old server.
Emails to UserA@source.com will be directed to your old/existing server until you change you MX records for source.com 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.