There are around a dozen email users at Sustaining Dunbar. Staff and volunteers have been using a variety of email clients and email providers to keep in touch. Some were already users of consumer Gmail accounts, Google Calendars and Google Docs, while others used a range of email applications or just webmail.
Each migration presented new problems and issues, uncovering some of the idiosyncrasies of Google Apps.
The Jekyll and Hyde problem occurs when existing users are already using their new Google Apps email address to access consumer Google services like Gmail. On setting up the new Google Apps accounts, we learnt quickly that it was best to first decouple such user’s current email address from the old Google account.
Then their was the problem of migrating web only email users to their Google Apps. We used the handy IMAP gmail-backup tool for this, as this is supported by consumer Gmail. Thousands of emails and complex labels were transferred with minimum errors and fuss.
Then there were Windows Mail users, which we transferred by first exporting the emls and underlying folder structure to Thunderbird. Then we flattened the hierarchy and reduced the number of items in each folder – some had several thousands of emails. We then created an IMAP connection with Google Apps and then simply copied the folders over (remembering to be online or the copy won’t do anything at all!). This is slow, so it might be easier to swap the settings in prefs.js to make a POP account IMAP, though synchronisation speed is unlikely to be improved.
For migrating Google Docs, we used Gladinet’s handy tool to link up to Gmail and Google Apps and simply dragged and dropped, not the fastest transfer – but it worked without error.
For small uncomplicated (few folders, few emails) email accounts based on Outlook or Thunderbird, the the Google Email Uploader is quite handy. In the past this has worked well on larger accounts, but it doesn’t match the IMAP job which clusters conversations well and creates labels to boot, without errors.