I started to write this post in September 2008, when it was titled “Importing legacy e-mail to my Google Apps account”. A few years on and I’m in the process of dumping Google Apps in favour of Microsoft Office 365 (if only Microsoft had a suitable offering back then, I might not have had to go through this) but I never did manage to bring all my mail across from my old Exchange server onto Google.
The draft blog post that I was writing back then (which was never published) said:
First of all, I backed up my Exchange mailbox. I also backed up my Google Mail and, whilst there are various methods of doing this, I used Outlook again, this time to connect to my Google Apps account via IMAP and take a copy into a PST file. With everything safe in a format I knew how to access if necessary, I set about the import, using the Google Email Uploader to import my Outlook mailbox into my Google Apps account.
Rather than import into my live mailbox straightaway, I brought the legacy messages into a new mailbox to test the process. Then I did the same again into my real e-mail
With many years worth of e-mail to import (29097 messages), this took a long while to run (about 20 hours) but gradually I saw all the old messages appear in Google Mail, with labels used to represent the original folder names. There were a few false starts but, thankfully the Google Email Uploader picks up where it left off. It also encountered a few errors along the way but these were all messages with suspect attachments or with malformed e-mail addresses and could be safely disregarded (I still have the .PST as a backup anyway) .
Except that I never did get my mailbox to a state where I was happy it was completely migrated. Uploading mail to GMail was just too flaky; too many timeouts; not enough confidence in the integrity of my data.
In the end, I committed email suicide and started again in Google Apps Mail. I could do the same now in Office 365 but this time I don’t have an archive of the messages in a nice handy format (.PST files do have their advantages!) and anyway, I wanted to be able to bring all of my mail and contacts across into my nice new 25GB mailbox (I’ve written previously about synchronising my various calendars – although I should probably revisit that too some time)
Migrating my contacts was pretty straightforward. I’m using a small business subscription on Office 365 so I don’t have the option of Active Directory integration – the enterprise plans have this but I exported my contacts from GMail in .CSV format and brought them back into Office 365 through the Outlook web app.
One thing that’s worth noting – Google Mail has an option to merge duplicate contacts – I used this before I exported, just to keep things clean (e.g. I had some contacts with just a phone number and others with an e-mail address – now they are combined).
Microsoft seems to have thought the mail migration process for Office 365 though pretty thoroughly. I don’t have space to go into the full details here, but it supports migrations from Exchange 2007 and later (using autodiscover), Exchange 2003 (manually specified settings) and IMAP servers. After a migration batch is initiated, Office 365 attempts to take a copy of the mailbox and then synchronise any changes every 24 hours until the administrator marks the migration as complete (during the migration period they should also switch over the DNS MX records for the DNS domain).
For GMail, IMAP migration is the option that’s required, together with the following settings:
(I only had one mailbox to migrate.)
Because GMail uses labels instead of Folders, I excluded a number of “folders” in the migration too to avoid duplicates. Unfortunately, this didn’t seem to take any effect (I guess I can always delete the offending folders from the imported data, which is all in a subfolder of [Google Mail]).
Finally, I provided a CSV file with the email address, username and password for each mailbox that I wanted to migrate.
Unfortunately, I’ve had a few migration failures – and the reports seem to suggest connectivity issues with Google (the Migration Error report includes messages like “Data migration for this mailbox failed because of delays on the remote server.” and “E-Mail Migration failed for this user because no e-mail could be downloaded for 1 hours, 20 minutes.“. Thankfully, I was able to restart the migration each time.
Monitoring the migration
Monitoring the migration is pretty straightforward as the Exchange Online portion of Office 365 gives details of current migrations. It’s also possible to control the migration from the command line. I didn’t attempt this, but I did use two commands to test connectivity and to monitor progress:
Test-MigrationServerAvailability -imap -remoteserver imap.gmail.com -port 993
Details of how to connect to Office365 using PowerShell can be found in my post about changing the primary email address for Office 365 users.
Points of note
I found that, whilst a migration batch was in process, I needed to wait for that batch to finish before I could load another batch of mailboxes. Also, once a particular type of migration (Exchange 2003, 2007 or IMAP) has been started, it’s not possible to creat batches of another type until the migration has been completed. Finally, completing a migration can take some time (including clean up) before it’s possible to start a new migration.
It’s worth noting that Office 365 is still in beta and that any of this information could change. 24 hours seems a long while to wait between mailbox synchronisations (it would be good if this was customisable) but the most significant concern for me is the timeouts on mailbox migrations. I can rule out any local connectivity issues as I’m migrating between two cloud services (Google Apps Mail and Office 365) – but I had enough issues on my (single mailbox) migration to concern me – I wouldn’t want to be migrating hundreds of mailboxes this way. Perhaps we’ll see third party tools (e.g. from Quest Software) to assist in the migration, comparing mailboxes to see that all data has indeed been transferred.