Last weekend I described moving my email hosting from my living room home office out to Microsoft Exchange Online. And Thursday I spent all day at a Microsoft workshop about Windows Azure, the cloud computing platform on which my employer, 10th Magnitude, has developed software for the past two years.
In this post, I'm going to describe the actual process of migrating from an on-site Exchange 2007 server to Exchange Online. If you'd prefer more photos of Parker or discussions about politics, go ahead and skip this one. It's pretty technical and Parker only makes a brief cameo.
About 18 months ago, 10th Magnitude's CTO tried to move us to the predecessor offering now replaced by Exchange Online and Office 365's, Business Productivity Online Suite, AKA "BPOS." He was quite adamant that BPOS was a CPOS, and made just setting up the service a complete PITA. I'd like to assure him and everyone else thinking about cloud-based email that the situation today has improved.
The new migration tools start you with a step-by-step checklist, liked to all the documentation you need, that takes you through the entire process:
Step 1 took fifteen seconds. I called my dad and told him I was moving his email account to a different server, and that he probably wouldn't even notice the change except his password would change. He said fine. That was easy.
Step 2 was to add my domains to Exchange Online. My existing Exchange organization hosted eight domains, which it had acquired over the 12 years or so I'd run development servers in my office. Each domain required going into my DNS registration account at DNS Made Easy and adding a TXT records proving I owned it. Fortunately, my DNS provider and Microsoft communicated in real time about the updates, so I got through 7 of 8 domains in about 10 minutes. The 8th domain, which unfortunately was the Active Directory root domain, had its nameservers pointed at the DNS registrar that I used before switching to DNS Made Easy. Switching nameservers took an entire day, for reasons that pass understanding.
Step 3, mailbox migration, had a few hiccups, and required about more effort than I anticipated. First, using the Remote Connectivity Analyzer, I discovered that the specific combination of DNS records, firewall rules, and mailbox configuration on my Exchange server wouldn't allow migration. It took about two hours of playing whack-a-mole to get just one of the tests in the suite to work. Microsoft provided (generally) comprehensive instructions on how to fix the problems I encountered, however. The test suite itself gave me a good idea of what I was doing wrong on its own, even without the TechNet articles.
The remaining steps in the plan—redirecting mail to the new server, completing the mailbox migration, activating users, and starting to use Exchange Online—took about fifteen minutes. Seriously.
The whole effort took six hours total. Part of this includes the post-move configuration changes I had to make to several services and Web sites, as my Exchange server was also my internal SMTP server. This blog, all of my hosted websites, and the collection of services that support those websites (like Weather Now, for example) all had to have a new SMTP server to send emails out. That was a little tricky, and required using IIS6 tools on a Windows 2008 server. But that's another story.
Also, my RSS feeds didn't fare well in the switch. With Exchange 2007 and Outlook 2010, your RSS feeds are stored on the server, not the client. So I had to add all of them back by hand after the migration.
It's important to note a few things that would make this more difficult for a larger business than mine. I had two active mailboxes for people and a couple for support services, I controlled both the Exchange server and the network, and I had no critical business issues during the switch. Larger organizations will have to handle a migration much more carefully than I did.
In the end, my email experience is exactly the same. And my apartment home office is noticeably quieter with two fewer servers gobbling electricity.