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.
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.
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.
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.
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)”.
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:
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.
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.
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.
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.
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.
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.
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.
There is a solution to Drive migration using Teamdrive.
My two cents:
Google’s practice is really insane and incredibly stupid. I. just. dont. understand.
Thanks for the great blog posting anyway, I’ll figure out my way through a manual transfer of 100 users.
Thanks for this info. I’m in the process of planning a move from 1 gsuite account to another (the old one will be going away).
So the details / steps you listed will be a great help. (no offense to the white papers from google, but they’re not always “clear”)
Unless you know of a 3rd service that can do this ? (as I have 60+ users that have to move)
This is a service that I provide! I’ll email you privately so we can discuss.
It’s not a complete solution, but you could at least automate the down/up loading of Google Drive files with GAM.
I would need your help regarding this migration. Could you please contact me privately?
I was planning on migrating email and files before moving the domain to the new account, because I thought I’d lose access to the data on the original G Suite account after the domain is moved — is this not the case if I change the user to a different domain on that account — I’d still be able to access the email and Drive docs for the original email? Does this help to reduce email downtime? Thanks for the helpful tutorial, Ann
Regarding losing access, so long as you move the old accounts to a new domain name, they can remain as-is for as long as you want to pay for them. Therefore, you can retain access for as long as you want – you would just need to log in via [email protected] instead of [email protected]
PS – the domain I am moving is not the primary domain of the original account. That domain is staying, so maybe that’s the difference?
Any idea what happens if the email is used for a Google Play account? I can’t get help from G Suite or Google Play support, because it’s kind of between the two!
To be honest, I have no idea – it seems to me, based on interactions with G Suite support staff, that the main focuses of G Suite are basically integration with existing login services (things like Active Directory), and Gmail. The other services appear to be secondary – to the degree that there is no migrator service for Google Drive, only Gmail. Unfortunately, with all other services being secondary, I really have no idea how Google Play would work!
Just wanted to say thanks for the guide. I tested this successfully and verified that you CAN use a subdomain as a placeholder for the source accounts. It didn’t require anything beyond the standard domain verification and separate MX records.
I’ve done several migrations over the years but I’m in the process of a migration from G Suite to G Suite of one user with a domain @example.com out of an account with several domains. The destination account needs to have the same @example.com domain name.
A migration between G Suite seems to be more complex than a migration coming from another provider!
I have two remarks about your otherwise excellent article:
(1) When you enable less secure apps globally, this should enable IMAP email migration for all the users. But the change can take up to 24 hours. So step 3 shouldn’t be necessary when you enable the less secure apps way in advance.
(2) I’m not certain you need all the passwords of all the users (when migrating between G Suite accounts). In a first step of the migration process, you need to give a password of a Role account. I guess this password should give access to the other accounts. But I’m not certain about this statement.
Thank you for the kind words about the article!
Regarding point 1, unfortunately this is not true. According to https://support.google.com/a/answer/105694?hl=en, “If you uncheck the box, POP and IMAP using modern security standards is enabled for your users, but IMAP for use with less secure apps remains disabled.” It then continues by telling you that “…users need to enable IMAP in their Gmail settings…” – meaning, you need to do it on an account-level basis, because your global changes don’t work.
Regarding point 2, when performing the migration and adding users, G Suite specifically asks you for the user-level passwords (even though you already provided an administrative password). I couldn’t believe it, either – I’m 100% sure that that is not how large organizations migrate thousands of users, but those are the tools that G Suite support gave me!
Excellent article here, thanks very much for putting this out there! This saved me a ton of research and gave me the confidence to take on this gigantic headache.
Best article on the web on this topic!
In my scenario – I will be migrating between two different customers and to a new domain name completely.
1 I Assume my scenario is easier as I don’t need to do the first steps of moving users from originaldomain to tempdomain (or a subdomain) first?
2 Where will the migrated mail end up in at the newdomain user’s Inbox, will it be lumped in with their targetdomain email Inbox, or will it [and it’s folders] be tagged somehow as from the originaldomain ?
3 I’ll definitely be blogging on this with documented screenshots to assist the knowledge!
1) That’s true – you’ll just make the new users on your new domain to map from your old email
2) The emails moved over won’t be tagged at all – items that were in the old Inbox will now be in the new Inbox, and all folders will be (or, should be!) moved over identically as well.
Hey Jake, great article mate.
I have done few of these migrations and there are always a very focused task.
To answer some of your questions in regards as to why it is like this, mostly has to do with the technology.
The reality is emails are still using IMAP protocols which are not new (IMAP has been around for over 10 years) and perhaps not designed to do batch migrations between servers at faster speeds. IMAP protocols have limited commands and ways to read and write email messages hence why the migration tool takes so long to move the files.
I have discovered there are quicker ways to migrate emails between accounts than using the Migration tool. For example I have used tools to backup gmail mailboxes and once backed up I can then restore these mailboxes into the “Destination” mailbox, which to the eyes of the software is the same user and same password, that works very well. (Although still takes time)
I have also done manual migrations when the mailboxes are not large using Outlook, simply connect one mailbox, create a PST and then after you migrate the mailbox to the new account then upload the messages.
In terms of your second point about having to wait to between removing the domain and adding it into the new account, this is simply because DNS services take some time to propagate information and the Google servers may take time to update worldwide to make sure the domain has been removed.
In some instances I have waited over 24 Hours for this change to become effective, most of the time is between 15 and 60 minutes. There is nothing you can do about it because you are waiting for the information to propagate.
As I mentioned before this is a task that requires focus and takes time (perhaps think of moving a house to a different location, there is probably one way: lift it, place in a truck and slowly move it), specially when doing multiple users and should be done by a specialist who understands what’s going on.
Well done on your tutorial, I hope you have managed to help few people with it and I hope my comments give some better understanding in regards to time lines and complexity of the task.
Preparation is key for a task like this.
Hi Jake, thanks for your writeup. I’ve recently done a migration and here are my takeaways:
* Enable IMAP on BOTH the source and destination account. This is not explicitly stated in the documentation, but Google support confirmed this to me. If you don’t, only mails from cca. past month were migrated in my case. As of end of 2020./Jan 2021. Google still doesn’t have a switch to enable IMAP globally for all users (only an option to allow the option for IMAP, if you understand what I mean), you have to go into each users account, which is insane if you have hundreds of users. Luckily we are a small shop so this wasn’t a major problem.
* “Folder size limits” in Gmail Settings must be set to “Do not limit the number of messages in an IMAP folder (default)”. This is the default.
* when migrating from multiple domains you must add MX records for them
* on the migration assistant screen, when you are done with emails from one domain, exit the Migration Assistant (More > Exit migration) then start the migration again for the users with new domains. If you don’t do this you’ll get an error “Failed estimating mailbox size”.
* domain can only be removed once the user’s email and email aliases are removed (check each user > User information > Alternate email addresses (email alias)). Remove the domain you are transferring from here.
Hope this update helps someone else.
Something to take note of in the guide. Creating an alias domain differs from creating a suborganization.
You cannot delete your primary domain by creating a sub-organization; instead, you must create an alias domain and make it primary.
Really great guide – all worked as intended. Thank you for putting this together!! 😀