For a while I tried to live with domain aliasing by having all my users manually change their default email alias on their clients (e.g. browser, iPhone, iPad). While this worked for email, unfortunately there is no workaround for calendar invites coming from your default domain (!). In addition, it became a burden as users forgot to follow the instructions, resulting in mail being sent from the wrong domain.
So yesterday I decided to eliminate the confusion and create a new Google Apps account with our new domain as the default. Below are the steps for anyone in a similar situation:
1. Arrange Downtime
In our case we had myolddomain.com as our primary domain, and mynewdomain.com as an alias on the same Google Apps account. In order to create a new Google Apps account with mynewdomain.com as the default, I needed to disassociate it from our current Google Apps account. For the short period of time it was disassociated (< 10 minutes), mail would have no way to be delivered to mynewdomain.com, and so would bounce back to sender. While there are ways to do this without risking bounced email, this was not a big concern for us as long as it was done off hours during planned downtime.
I recommend asking users to not login during the downtime to avoid the potential of them making changes after data has already been migrated. You should also have a list of alternative email contacts for all users (e.g. their home email), so you can send them email with their new login information without requiring them to login to the old account. Another tip: reduce the TTLs on your DNS provider MX records to allow for a more rapid cutover.
2. Create New Account
In order to sign up for the new account, I first had to remove the mynewdomain.com alias from my current account. Doing this will have no effect on your documents, but it will result in emails sent to mynewdomain.com being bounced back to the sender. At this point you probably want to work quickly in setting up your new Google Apps account for mynewdomain.com. The account setup will only take a few minutes, and will require that you authenticate your ownership of the mynewdomain.com with your registrar. Upon completion of this step, you can rest easy that your mail sent to mynewdomain.com will no longer bounce.
3. Create Users & Groups
You should now go ahead and re-create the users in your new account. This can be done manually or using the CSV import feature. To save time, you can choose to add the groups after step 5 with no harm.
4. Forward Email
Upon completing step 2, emails going to myolddomain.dom will go into your old Google Apps account, and emails going to mynewdomain.com will go to the new account. To minimize confusion for your users, you should enable email forwarding from the old account to the new one. This will ensure that any email sent to joe@myolddomain.com will be in the inbox of the new account. You can do this by setting up receive routing setting in your old account that forwards all mail to myolddomain.com to the equivalent user at mynewdomain.com.
5. Migrate Data
Google offers a variety of tools to support migrating data between accounts, each with different limitations. I decided instead to use one of the available marketplace tools to migrate the data. The two I considered were from Backupify and SysCloudSoft. I decided to use the Backupify Migrator, in large part due to the fact they offered a full backup of a single user as a trial (...and I know several people there ;) ).
The migration of the data took about two hours, came over with high integrity, and the overall user experience of the tool was excellent. We did identify one issue we worked around: the tool put labels on all of our migrated mail / documents, which was a minor visual annoyance. This issue did not take away from fact the Backupify Migrator saved me hours of manual labor at a great price. Feature request: allow users to pay extra to have Backupify retain a copy of the documents for a fixed period of time.
6. Complete New Account Setup
While the migrator tool is working step 5 for you, you can go back and put the finishing touches on your account. For example you can setup forwarding URLs, upload a custom logo, add marketplace apps, and anything else that you personalized in the previous account. I also took the time to upload a custom logo to the old account with big red letters saying “WRONG ACCOUNT!”, in hope this minimized confusion for the few days I ran the two accounts in parallel.
7. Send Users Welcome Email
At this point I sent emails to my users using the alternative contacts I collected (although in my case I forgot to collect these alternative contacts in advance). I provided each user with the new custom URLs to login - i.e. mail.mynewdomain.com, calendar.mynewdomain.com, docs.mynewdomain.com - and asked them to perform the following steps:
-
Verify email, calendar and documents are migrated - Although I had spot checked the migration, I figured the extra validation couldn't hurt.
-
Setup a new signature - Since signatures are not automatically migrated, now is a good time to have users set them up.
-
Setup mobile devices - Users should remove their previous and setup their new account.
-
Update Google Drive - Users should remove their Google Drive account from clients (e.g. laptop), rename the folder as a backup, and add the new account to Google Drive.
-
Verify important email addresses & groups - Test sending email to themselves at all relevant domains / groups to ensure everything is working properly.
8. Delete Old Account
After you and your users have verified data has been migrated and the new account is working properly, you can delete your old Google Apps account, and add the old domain (e.g. myolddomain.com) as an alias to the new account. The account delete typically takes five days, but if you call Google support, you can arrange to accelerate this so you can make it an alias immediately.
Final Notes
The overall process took about three hours of elapsed time. I’ll post updates as I find additional issues resulting from the migration. Nothing is ever this easy. ;)
Update June 11: We have encountered various permission issues in the migration. The issues are not related to the Backupify Migrator, which did its job well, but due to the fact some users had set permissions using myolddomain.com, and so there was no way to carry them forward to the new domain. Not sure though how we could have better handled this. We have manually managed through it now though.
Update June 12: Had great support from Backupify working through post-migration questions. Another reason to use Backupify Migrator.