Outlook: Cloudy (with a chance of email)

I've spent much of the last week moving our mail from our own Exchange server, up to Microsoft's Office 365 service. It's been an interesting process, and one that threw up a couple of interesting challenges.

It's a little sad moving away from running my own mail server – and a little disconcerting giving up the control we'd had. After all, the server had done sterling service over the years, passing through several incarnations – first as a Small Business Server box (both SBS 2000 and SBS 2003), before moving to Windows 2008 and Exchange Server 2007, and its final local incarnation as Exchange 2010 in Windows Server 2008 R2 virtual machine. It didn't take much management work, it just sat there at the end of our DSL line, taking in SMTP mail and spitting it out in copies of Outlook on our desktops and via Exchange Active Sync to phones and tablets. I even ran a small BES Express installation in another VM to feed various BlackBerrys.

But problems with our DSL line (due to the way BT installed our initial connection way back in the first tranche of DSL tests) have made our connection increasingly unreliable at today's higher speeds, and it's a little embarrassing getting a friend round to reboot our router while we're at a conference in the US. So while I've been reviewing Office 365 for ZDNet UK, I've been considering it as a replacement for our mailserver – with the aim of giving us reliable mail service from anywhere.

The actual migration process hasn't been as easy as it could have been, as we've tended to be something of an edge case. With just a couple of users with fairly demanding needs, I've tweaked and tuned the server, turning off most of its quotas and building up large mailboxes with gigabytes of messages in some folders. That's not quite the business email scenario Microsoft considered when it designed its service, and I shouldn't have been surprised when my first attempt at moving mail failed.

At first glance the process is simple. Just log on to Office 365, give it the details of an Internet-facing Exchange ActiveSync server, and let it slurp the mailboxes into the cloud. We were planning on a hard-switch over, turning off the local Exchange server once the migration was complete – and then moving the MX records for our domain to point to Office 365. We set up the migration, clicked go, and watched a couple of unattended system mailboxes upload in an hour or so, before it started on our much large mailboxes. And that's where it all went wrong.

It turns out that there's a hard limit on message size on Office 365. If you've got messages over 25MB in size they won't be accepted by the server – and you won't be able to migrate a mailbox that's got large message sin it. The error message you get isn’t as helpful as it might be, but there's plenty of online information that'll help you debug Office 365's response and find the appropriate fix. The remainder of the mailboxes will continue uploading, giving you time to remediate the problems with failed mailboxes.

Possibly the easiest way to deal with the large message problem is to use Outlook's Search Folders to build a dynamic query that will find all messages over a set size. You can sort the resulting virtual folder by size, and remove all the messages (or attachments) that are blocking the migration. If you're concerned about possible corrupt messages in your Exchange database you can create a new store and database and move the offending mailboxes to the new store.

It turned out that we had quite a lot of large messages – most of which were attachments in the sent items folder. Back in the days before tools like Dropbox we'd been attaching screenshots and photostories to email and those attachments were still there, and still large! Once you've made the appropriate fixes and you're able to restart the migration, you can just sit back and let the mail upload. It can take a couple of days to upload a large mailbox over a DSL line, but the process isn't intrusive and you can carry on using your local Exchange servers while mailboxes migrate.

Once it's done you're able to cut over the DNS settings. Microsoft publishes custom details as part of its web process. If you're using your own domain you'll have had to verify it beforehand by setting up a TXT record, so all you need to do is change the records associated with your mail server.

You'll need to set up an autodiscover CNAME for your domain that most Exchange Active Sync clients use to automatically set up connections (including Outlook 2010), as well as a SPF record to take advantage of the spam control features from Office 365, and of course, the all-important MX record. When that's setup and tested you'll just need to wait for mail to flow into your cloud Exchange server, before finalising the migration process. Office 365 will upload any mail that's come in during the migration from your mailboxes, and you can finally turn off your old Exchange server.

So now our mail is in the cloud, and I won't need a friend with a key on speed dial next time I'm at a conference in the US. It'll also save a few pennies on the electricity bill…

Simon Bisson