IT Decision Maker

Blog archive

Our Office 365 Experience: Part 2, The Migration

To migrate from Google Apps to Office 365, we decided to try a third-party migration tool. We'd been asked to write a competitive analysis of the available migration options, including the built-in one (which is mainly suitable for migrating from an Exchange Server), so this seemed like a good time to try the options. The process went off perfectly, using a self-service option that cost just $10/mailbox and let our users handle their own migrations simply by entering their old and new passwords into a Web page. Mailbox migrations can take a long, long time. Had we been smarter, we might have opted for an admin-controlled migration rather than the user self-service, because the tool would have enabled us to filter out all the old trash content that Google was hanging on to. As-is, we discovered that Office 365 starts applying bandwidth throttles after a few thousand messages are added to your inbox, meaning each mailbox took almost a full day to migrate. We later learned that office 365 support can suspend those throttles during a migration if you give them a call.

Once migrated, we started the process of adding our custom domain name (ConcentratedTech.com) to Office 365. This is where the process becomes slightly less-awesome. Right now, you can add the domain name easily enough, but it won't become your users' default send-as domain, meaning we were still sending e-mail from the "onmicrosoft.com" domain name associated with our account. Changing that default involves downloading the Office Live PowerShell cmdlets, opening a PowerShell Remoting session to our Office 365 server pod and running a couple of PowerShell cmdlets. This is something you should be aware of if you're considering an O365 move; frankly, given that O365 is largely targeted to SMBs who don't have a large IT staff, I think Microsoft should make this a bit easier and Web-based.

PowerShell cropped up again when we needed to mass-import contacts into the Global Address List (GAL) as external contacts. We used Excel to create a consolidated contact list, and then a couple of PowerShell commands brought that information into the GAL. Again, as big a PowerShell fan as I am, I think this is something that needs to have a Web front-end on it. O365 simply isn't being sold with the "by the way, hope you know how to use PowerShell" message as part of its marketing.

With the migration over, we settled in to using O365.

Up next: The Verdict

In case you missed it:

Posted by Don Jones on 01/20/2012 at 1:14 PM


Featured

comments powered by Disqus

Subscribe on YouTube