Menu

BLOG

Oct
2017

Migrate Email from One G Suite Account to Another (Tutorial)

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

Contents

Introduction

I was recently given the task of migrating users and emails from one G Suite 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 only done this once, I don’t know what the best practices are for migrating between G Suite accounts (so please feel free to comment at the bottom of the page if you have advice or corrections!). Instead, I only know what I’ve gleaned from Official Google documentation, as well as from chats with Google Support. 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 G Suite for Nonprofits account into a G Suite 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).

2. Low Security is Best Security

For some reason, I was encouraged to enforce less secure apps for users. It appears that Google’s own migrator service is considered “less secure” by Google’s own standards.
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 G Suite servers, you don’t have to change your MX records – they’ll be pointing to G Suite the whole time.

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 G Suite 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 “G Suite”. 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

According to the three G Suite chat support engineers I spoke to, there is no way to migrate Google Drive documents between different G Suite 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.
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 G Suite 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.

17 Comments

    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.

    Hi Jacob,

    I would need your help regarding this migration. Could you please contact me privately?

    BR,
    Soko

    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.

    Two questions
    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!

    TIA

      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.

Leave a Comment

Your email address will not be published. Required fields are marked *

*

*


SEND A MESSAGE