Migrate Email from One Google Workspace Account to Another (Tutorial)

Looking for help migrating your email? Please feel free to contact me for a free consultation!

Contents

• Introduction
• Goals and Description
• Things You’ll Need
• Steps
  • 1. Move Accounts Around
    • Optional – Move Users to Sub-Organization
    • Swap Domains
  • 2. Low Security Is Best Security
  • 3. Enable IMAP for Every Account
  • 4. Deleting Domain from Source Account
  • 5. Adding Domain to Destination Account
  • 6. Immediately Recreate the Users on the Destination Account
  • 7. Start Email Migration Service
• Caveats
  • Google Drive
• Conclusion

Introduction

I was recently given the task of migrating users and emails from one Google Workspace (formerly GSuite) account to another. Not between two users, mind you – between two completely separate administrative accounts. There was a domain name on one account (I’ll call it the “Source account” for simplicity and anonymity) to a new account (the “Destination account”). I found that although there are a bunch of articles online that mention Google’s email migrator service, and even an article with the same title as mine, I didn’t find much in the way of a step-by-step tutorial for moving everything over. Below is my attempt at one.

Having done this several dozen times at this point, I’ve developed my own set of best practices. That being said, Google doesn’t really provide any of their own, so take what I’m saying with a grain of salt and see what works for you and what won’t. Although this sounds like the best way to go about things, I have a number of concerns that I cover in my Conclusion section.

Two notes – First, I was actually moving data from a Google Workspace for Nonprofits account into a Google Workspace for Business account, but that doesn’t seem to have mattered much – it worked the same as it would had they both been the same account type.

Second, I mention various tools and wait times in this tutorial. I happen to think that if you’re one of Google’s larger customers, there may be more tools or support available to you, or your wait times may be significantly reduced. I don’t have proof of that, I just can’t believe that it takes them 1.5 weeks to move 6GB for their enterprise-level customers.

Goals and Description

In my example, my Source account has a domain name, say example.com. We need that domain, and all users @example.com moved to the Destination account.

To do this, we’re going to move all of the users on the Source account to instead use a different domain, @example-two.com. We’ll enforce less secure apps on these accounts. We’ll log in to each account and make sure they have IMAP enabled. We’ll remove the domain from the Source account and add it to the Destination account, and immediately recreate the users on the Destination accounts so they can begin receiving email again. Finally, we’ll use Google’s email migrator service to move the old email over from the @example-two.com accounts to their new, corresponding @example.com accounts.

Things You’ll Need

• Access to the administrative accounts of BOTH the Source and Destination accounts.
• An alternate domain tied to the Source account.
• The ability to have some downtime between when you remove the domain from the Source account and add it to the Destination account.
• A significant amount of time. Took about 1.5 weeks to get a user with 6GB of email migrated.
• Users that don’t need access to their historical email for that significant amount of time.
• The ability to sign in to every users’ email. On the technical level, you can just reset their passwords as an admin, but that doesn’t mean users will like that you can read their email.

Steps

1. Move Accounts Around

Optional – Move Users to Sub-Organization

If you have a lot of users and are only moving a subset of those users, it can be helpful both from an organizational perspective as well as from a security perspective to move the users to a sub-organization. Note that this does not have a direct effect on the users until you make a global change to that sub-organization – the names of the organizations don’t actually matter, but I’ve named them by their domain name for simplicity.

To add a new organization (called an “organizational unit” or “org unit” in some Google documentation), go to the Users section from the Admin Console. On the left, there should be a Filters sidebar (click on the small filter icon if you don’t see it.

Hover over your main organization and click the three dots on the right-hand size, then click “Add sub organization”. I named the organization “example-two.com”, after the secondary domain I’ve added to the Source account.

Swap Domains

Our Source account has the example.com domain name, and also has a number of users with @example.com emails. We need the Destination account to have this domain name, but we can’t remove the domain name from the Source account while it still has users tied to it. So, we’re going to have to migrate all the users to a different domain name.

As mentioned in the Things You’ll Need section, you’re going to need to have a second domain name added to this account so you’ll have somewhere to move these users. It’s possible that a subdomain will work here if it has different MX records, I’m not completely sure.

From the Admin Console of the Source account, click on Users. Select a given user, then click on “Account”.

Click the Edit button under Basic Information.

You’ll see an “Update User” modal, which will have the current user’s email address. There should be a dropdown for the domain name. Select the alternate domain name, and then click “Update User”.

You’re going to need to do this for every user on the domain, so that no user is tied to example.com anymore. This will allow you to remove example.com as a domain from your Source account without deleting any of the users (or their precious data).

An additional wrinkle – when you rename a user, Google “helpfully” adds their old email address as an alias. You’ll have to delete that alias.

2. Low Security is Best Security

Google thinks that only their OAuth login flow is secure, and therefore entering the user’s credentials in any other form is insecure. The weird part is that it’s Google themselves offering the migrator tool, and the tool doesn’t use their OAuth flow…so they’re providing their own insecure tool. In any case, we’ll need to enable “less secure apps” on each account to allow for the migrator tool’s use.

From the Admin Console, click on Security. From the Security page, click on “Basic Settings”.

At the very bottom, there’s a link called “Go to settings for less secure apps”

Here, choose your organization. If you skipped the step above for making a sub-organization, your only choice will be to enforce less secure apps for the entire main organization (which, if you’re moving all of the users, is fine). Select the appropriate organization and click on “Enforce access to less secure apps for all users (Not Recommended)”.

3. Enable IMAP for Every Account

This is one of the steps that I just can’t believe is necessary for large organizations. Apparently, you need to log in as every user on the Source account (and you’ll need to reset their password, since you likely don’t know their password) and make sure their IMAP setting is on so that data can be migrated. Record this password for the Start Email Migration Service step.

Google has an easy list of steps here once you’re logged in as the user – I’ve repeated them below:

1. On your computer, open Gmail.
2. In the top right, click Settings .
3. Click Settings.
4. Click the Forwarding and POP/IMAP tab.
5. In the “IMAP Access” section, select Enable IMAP.
6. Click Save Changes.

Now we can finally remove the domain from the Source account and add it to the Destination account. Note that since we’re moving it to and from the same Google Workspace servers, you don’t have to change your MX records – they’ll be pointing to Google Workspace the whole time.

If you get an error saying the domain name is in use, it might be a user’s alias, and it might also be a Google Group. If you don’t see anything for either of those, contact support and they can try to find it for you.

4. Deleting Domain from Source Account

To delete the domain from the Source account, click on the Domains section of the Admin Console, and then click on Add/remove domains.

Make your secondary domain, in my case example-two.com, the primary domain by clicking on the “MAKE PRIMARY” button. Once it’s the primary domain, refresh the page, and you should see the two domain names reversed. Now that your main domain, in my case example.com, is not the primary domain, you can click the “Remove” button next to it.

5. Adding Domain to Destination Account

Now that the domain name is “unclaimed” as far as Google Workspace is concerned, go to the Destination account and add the domain, basically the reverse process of deleting from the Source account. Note of course that you would need a previously created Destination account at this stage in order to add the account. If you don’t have one (because this would be the only domain involved), you can now create a new account and supply this domain name as your primary one in the sign-up form.

There will be a period of time between when you remove the domain from one account and when the system realizes that the domain has been released. Between those two events, you will not be able to add the domain name to your new account. My Google Chat representative told me there was nothing he could do to speed up this process. This, once again, can’t be the way that large organizations do things – they must be able to do a quick cutover between old and new systems – but such is the state of the tools I was able to use. I kept checking roughly once every 5 minutes, and was finally able to add the new domain after roughly 45 minutes.

6. Immediately Recreate the Users on the Destination Account

Previously, we moved all @example.com users to @example-two.com on the Source account. Now that the domain name is set up on the Destination account, it’s time to create the new @example.com users again. The steps are fairly simple – you can either add users individually (https://support.google.com/a/answer/33310?hl=en), or make a CSV and create all the users at once (https://support.google.com/a/answer/40057).

I opted for the CSV way because it’s faster – the goal is to allow these new users to begin receiving email as quickly as possible. I would suggest logging in as one of these users and sending/receiving a test email or two to confirm that the accounts are working as expected before moving on to the migration step, which takes a long time and you probably don’t want to stop it in order to diagnose a problem.

7. Start Email Migration Service

In the current state, we have the example.com on our Destination account, and all of the @example.com users created and ready to send and receive email. We also have corresponding @example-two.com users on the Source account, which have all of the historical email. We’ll need to migrate the email from the @example-two.com users to their corresponding @example.com users.

From the Admin Console of the Destination account, click on Data Migration. On the first form page, choose “Email”.

On the second form page, set Migration Source to “Google Workspace”. For Connection Protocol, leave it as “Auto select (Recommended)”. Finally, for Role Account, you need to put in the admin login information for the Source account. This gives the Destination account the ability to reach in to the Source account and pull out the email data.

In the third step, you can choose the migration start date. For some reason, there is no “all email” option here, you actually have to choose a date. Because Gmail officially launched in April of 2004 (source: https://en.wikipedia.org/wiki/Gmail), I chose a Custom Date and entered April 1st of 2003.

Under Migration Options, I chose to migrate deleted and junk mail – the main reason to not do this is that it could reduce the amount of data that needs to be transferred, thus speeding up the transfer. However, I decided it was just better to try to hand users an inbox with all the data in exactly the same place they left it. You can also exclude certain top-level folders (for example, the Sent folder) if you so chose.

Finally, you reach the migration stage. You can click the “+” icon to add a new user pair, in order to migrate data from the Source @example-two.com account to the Destination @example.com account. Note that there is also an option for “Select multiple users”, but I was told by a chat representative that this tends to be buggy.

Now you enter the Source @example-two.com information in the “Migrate From” section, and the Destination @example.com information in the “Migrate To” section.

Note here that you actually need the password for the user once more – I comment on this in my Conclusion section.

Add each user pair, and you’ll start to see them populate the Data Migration screen. You’ll get used to checking this screen multiple times a day. At this stage, you can send your users their new passwords (for security purposes, I always check off the “force user to change their password on next login” button). They can begin using their new email addresses now, and all new mail will show up in their otherwise empty inbox. Only after the migration is complete will they see their historical email.

Caveats

Google Drive/Calendar/Contacts

According to the three Google Workspace chat support engineers I spoke to, there is no way to migrate Google Drive or other Google services between different Google Workspace Accounts. If you try, you’ll get an error like this one:

The solution provided to me by the chat representatives was literally to log in to every @example-two.com account, download all of the documents they own. Share all the documents shared with them to the new @example.com domain. Then, log in to the new @example.com account and upload all the documents. Similarly for Contacts and Calendar, log in to each account and export/import.

This is incredibly cumbersome, and really seems like a large oversight on the part of Google. I refuse to believe that this is the official way to move documents between users’ Google Drive documents for a large organization. As I mentioned in the intro, I’m sure that there are better tools available for higher-paying customers – but I was not able to access any such tool.

Conclusion

In conclusion, besides all the time trying to get an exact list of steps for how to do this from Google Chat representatives (who were incredibly helpful, but I don’t quite understand why a document detailing this in the support docs doesn’t exist already), this process took about two hours of real work time (including downloading and re-uploading all of the Google Drive documents for ~10 users), and then 1.5 weeks of waiting for the migration percentage to hit 100%.

It wasn’t too bad, although I did get a number of questions from users about where their email is – they don’t get access to their old emails piecemeal, they get them all at once when it finishes, so that’s 1.5 weeks where they can’t get to their old emails. That’s potentially a big problem for large organizations, though they may get preferential treatment in terms of transfer speed.

Finally, I’m a little disturbed by the fact that in order to move data between two Google Workspace accounts, you need the username and password for both accounts (perfectly acceptable), but also the username and password for every user that you want to move. It seems like far too much manual work to have to reset all of the passwords for all of the accounts, in order to enable IMAP for each account, download their Google Drive documents, and later re-enter their account information when starting the transfer. There simply must be another way to do it, to which us standard (but still paying!) users do not get access.