This article contains answers to frequently asked questions about Gmail migrations, as well as basic information on creating and completing a successful migration project. This FAQ is intended to function as a support to the migration guides. To begin the migration process, choose the appropriate migration guide and follow the steps within.

Free Gmail/Google account migrations are not supported.

Migrated Items

There are many items of data contained within a G Suite instance, from mail messages to calendars. The following lists which items will be migrated, and which will not. Some of these items may vary by endpoint, so verify which endpoint you will be using when checking this list. Click below to expand the list of migrated items.

Maximum file size

The maximum file size for migration through MigrationWiz varies by migration type and environment, but may never exceed 60GB.

Migration Speed

Migration speed is not an exact science; it is subject to a number of variables:

• Every mailbox goes over a different connector, different server. It has been proven that two connectors with the same software and same hardware does not receive data at the same speed from Microsoft 365 to G Suite.
• Number of Folders -> Number of Labels can have an influence on the Source and Destination speeds. For example, it has been proven that the more folders you have in Microsoft 365, the longer it takes to reply; it is the same with G Suite.
• Replication strategy on Destination. If we are migrating during a fail-over or replication-cycle of Google (Google replicates to multiple data centers) to deal with their SLAs requirements, this will result in differing migration speeds being reported at the Destination.

 To help alleviate any concerns that you may have regarding migration speeds, we recommend that you follow a pre-stage migration strategy.

Field mappings 

All labels/folders are migrated by default. Inbox is mapped to the Inbox system folder of the Destination. Labeled items are created in each corresponding folder (This is only if Labels to folders is left as enabled). Folders are mapped purely by name (We rename folders with invalid characters by replacing invalid characters).

Gmail labels conversion:

• • Labels to folders – this is the default behavior.
  • Labels to categories – this option can be set instead (under the project Advanced Options).

Labels in G Suite Migrations

G Suite labels transfer automatically in G Suite to G Suite migrations, but if you are migrating from G Suite to another platform, there are a few changes that may occur along the way. 

Google label conversion and migration

Google does not have a folder hierarchy for email, but rather a virtual view called Google Labels. Google Labels cannot be translated properly to other messaging systems. Even Google itself does not represent present Labels consistently. Messages are stored as a single instance within the Google mail store, but shown when enumerating multiple labels within the web interface. When an IMAP client such as Outlook or your mobile device is connected to Google, the Labels are presented as folders and downloaded multiple times, taking up additional storage.

When migrating from Google, there are several choices to convert labels to the new messaging environment. There are pros and cons in each approach, and it is important to understand the implications in order to make an informed decision. The options are: 1) convert Labels to folders or 2) convert Labels to Exchange categories.

Convert Labels to Folders:

The first and most popular approach is to convert Labels to folders. What this means is that the organization and views will be similar to what is already experienced in Google today. The downside is that the mailbox size will increase because the messages are stored in each corresponding folder. There is no concept of single storage for each item when multiplied across folders.

Pros:

• Similar view and structure as Google.
• Consistent experience across web access, desktop clients (i.e., Outlook), and mobile devices.
• Only archived items are migrated into the All Mail folder.

Cons:

• Inflated mailbox size due to storage of multiple copies

If a Label contains a "/" ​​MigrationWiz will create subfolders. For example, for a Label called aaa/bbb/ccc at the Source, MigrationWiz will create a folder aaa, then a folder bbb within aaa, and then a folder ccc within bbb. Also, while the migration is in progress, the user must not rename any of those folders.

Convert Labels to Exchange Categories

This method will migrate the Google All Mail folder only. The All Mail contains all messages within the Google mailbox except Trash/Deleted Items, and results in only one copy of each message being migrated, thus the mailbox size is similar to that of your Google mailbox. 

Pros:

• Single copy all messages are migrated, thus no inflation of mailbox size.
• Labels are converted to Exchange categories and marked on each item.
• Create virtual views in Exchange with search folders based on categories.

Cons:

• Exchange may experience performance issues when enumerating the large folder.
• Unable to view Outlook-created search folders in OWA or mobile device.
• Must browse a single folder containing all items if the mail client does not support Exchange category filtering or search folders.
  
  • This means that no further filtering can be used.  Since this already filters the migration to only the All Mail folder, trying to filter for other labels will not work.
• Trash and Deleted items will not be migrated

Selecting one of the options:

The first option (convert Labels to folders) is the default. If this is chosen, no additional configuration is needed. If the second option (convert Labels to categories) is chosen:

1. Sign in to the MigrationWiz account.
2. Edit the Project.
3. Click on Advanced Options.
4. Select the desired Gmail all mail folder option​.

More messages after migration

Google has a concept called "labels" and has no concept of a folder. "Labels" are essentially tags that categorize messages. You may apply one or more labels to a message.

When migrating from Google, all labels are converted to folders. For every label that is applied to a message, a copy of the item is created in that folder. For example, if you label a message with A, B, and C, we will by default create the same item in three folders /A, /B, and /C.

In addition to labels, Google has a folder called "All Mail" which contains a copy of every message in your mailbox. By default, we will only migrate archived email (i.e., email without any label) to the "All Mail" folder. 

Mapping multiple labels into a single folder

The short answer is that this is not possible. Each user would need to specify which labels take precedence over others, a cumbersome process. Even if it was possible to specify which folder takes preference, one would be missing data.

Utilizing G Suite All Mail label 

The best approach is to filter out the All Mail label until the very last pass. The reason for this is that Google has most items in individual labels, but also keeps a copy of all items in the All Mail label.

Without adding this filter, MigrationWiz will have to index the AllMail items label before it can migrate. This will typically be very large and consequently will take a very long time to index.

We recommend that you first filter out All Mail, and migrate all the other labels during the Pre-Stage and Delta passes. Then, perform one last Delta pass, having removed the All Mail filter, so that it indexes the All Mail label during this pass and migrates any additional non-labeled items.

Here are the steps to follow to add the filter to your MigrationWiz project Advanced Options. This should be left in place for all passes, apart from the very last pass (where it is removed, as detailed at the bottom of this article).

1. Log in to your MSPComplete dashboard.
2. From the list of customers in the left-hand navigation panel, select your customer.
3. From the list of options in the top navigation bar, click on
4. Click on the name of your Project in the list. This will launch the MigrationWiz portal for the selected project.
5. In the top navigation bar, click on the Edit Project
6. From the resulting drop-down list, select Advanced Options.
7. Under Filtering, add the following: (^All Mail$|^All Mail/). This will filter the All Mail folder and any subfolders of All Mail.
8. Click Save. 

You can now perform your migration by following the steps in the migration guide that matches your scenario.

After you have completed all passes, you can perform one additional last pass, but with the filter removed. This pass can be performed after your users have already begun using the Destination account.

Follow these steps to remove this filter for the very last pass:

1. From your MigrationWiz project dashboard, in the top navigation bar, click on the Edit Project 
2. From the resulting drop-down list, select Advanced Options.
3. Under Filtering, remove the previously added filter.
4. Click Save. 
5. Now you can select the items for migration, click Start, select Full Migration,and follow the prompts to start your migration pass. This pass will migrate any additional items that are in the All Mail folder, but not in any other label. This is normally just a few deleted items, and archived items (that have no label). Normally the user is unaware of these items, but it is still best to migrate, for completeness.

CATEGORY_ Labels

The Gmail API connector supports migrating the following labels from the source. Due to number of items these labels can often contain (the majority of the time, it can be found that the items are not business critical), you may want to consider excluding them from the migration. 

• FORUMS
• PROMOTIONS
• SOCIAL
• UPDATES

You can use the following folder filter to exclude all of these labels in the migration:

^(CATEGORY_FORUMS|CATEGORY_PROMOTIONS|CATEGORY_SOCIAL|CATEGORY_UPDATES)

"Starred", "Important", "High Importance" labels

Any items designated with a 'Starred', 'Important', or items that have a 'High Importance' tag that was set by an email client that supports a 'High Importance' designation have unique behaviors when being migrated from Google to Exchange.

• Starred Items: Items marked as 'Starred' have a red flag designation in the destination mailbox, indicating that this item was marked for follow-up.

• High Importance Items: Items sent with 'High Importance' through an email client maintain their status during the migration.

• Important Items: Items marked as 'Important' are migrated as “High Importance” items.
  

  Workaround

  To avoid this behavior, change all the emails' status to Not Important before migration. Otherwise, you can change their status in bulk after migration.

When migrating items from Google, if there are any tags associated with the item, those tags will supersede any other labels that may be associated with it.

Mapping to /inbox/foldername labels 

By default, when migrating to G Suite, folders that are under the Inbox folder will be mapped to the inbox/foldername label.

To change this behavior, add a project Advanced Option, Folder Mapping, located under "Support/support options".

A common one that is added is: 

FolderMapping="^INBOX/->" This will map folders to the root label on the Destination mailboxes, rather than under inbox/labelname.

Here are the steps to add this:

• From your MigrationWiz dashboard, click on the Edit Project.
• From the drop-down list, select Advanced Options.
• At the bottom right-hand of the page is the Support field.
• Under Support Option enter: FolderMapping="^INBOX/->"
• Click on the "+" button.
• Click on the Save Options.
• Click on the Save Project button to return to the project dashboard.

When this folder mapping is applied, if a user has a folder named "test" at the root of their mailbox, and also a folder named "test" under their Inbox folder, then these will be merged into the same label on G Suite, which will appear under the root label.

In G Suite, you have labels instead of folders. Labels can make it easier to organize things, because one message can have multiple labels, rather like tagging in social networks and photo-sharing sites.

G Suite Endpoints

MigrationWiz now has two available endpoints for G Suite migrations. For more information, see Set Up Google API. This process will walk you through setting up the Google API endpoint. This endpoint migrates more items than the IMAP endpoint. This endpoint is more stable than IMAP, and functions when a tenant does not allow IMAP connections. 

Migrating Calendars

G Suite supports calendar sharing. For each mailbox, we only migrate calendars owned by the user (i.e., not calendars owned by other users). In most cases, conference room calendars will not be migrated. In order for the primary Calendar of a source G Suite mailbox to be migrated, the address entered in MigrationWiz must match that assigned to the source G Suite Calendar.

Sometimes a calendar event from a secondary calendar will migrate into a primary calendar. When migrating calendar events, the destination user must be the organizer of the event that is being migrated. Otherwise, Google will only allow the event to be created in the user's main calendar.

From a technical standpoint, calendars that will be migrated are those for which the migrated user has:

• Permission level "make changes" or "make changes & manage sharing", or
• Permission level of root, and
  1. The author is either not specified, or
  2. The author is the migrated user, i.e., is not a different user.

For a technical reference of calendar sharing permissions, click this link. To filter specific folders including calendar folders, click this link.

You may add the Support option MigrateGmailAllCalendar=1 which will migrate all calendars for a user. The default without this flag is to migrate only calendars owned by the user.

Calendar Reminders & Notifications

Google Calendar reminders

• Reminders remain in your Google Calendar until the task is accomplished.
• More information about Google reminders can be found in the official Google blog post. You will find it here.
• Google Calendar reminders do not get migrated.

 Google Calendar notifications

• Events and their corresponding notifications are deleted irrespective of whether the event was attended or not.
• Google Calendar notifications do get migrated.

Migrating Resource Calendars

Migrating resource calendars from G Suite to On-Premises Exchange or Microsoft 365 (Exchange Online) requires the use of Advanced Options because the email addresses for resource calendars in G Suite don't map to the email addresses for resource mailboxes in Exchange. Additionally, G Suite doesn't allow programmatic login to resource calendars, even when using OAuth, whereas Exchange does.

Complete the steps listed below to migrate resource calendars from G Suite to On-Premises Exchange or Exchange Online.

These instructions focus on the migration steps for resource calendars. For the full set of steps to migrate user mailboxes, refer to the G Suite to On-Premises Exchange Migration Guide or the G Suite to Office 365 Migration Guide.

1. In G Suite, complete these steps:
   • Get the email addresses for the resource calendars. Sign in to the G Suite admin console and go to Apps> G Suite > Calendar > Resources. Select a resource to view its email address. The email addresses for resource calendars contain a combination of the account's domain name and a GUID (e.g., bitrepro.com_3213265465461321@resource.calendar.google.com). Save the list of email addresses to a file (Word, Excel, etc.) that you can access later when creating the mailbox migration project in MigrationWiz.
   • Create a new user account. Sign in to the G Suite admin console and go to Users> Add user. Make note of the user account information because you will need it for step 6 below.
   • Add the resource calendars to the user account. Sign in to G Suite as the user, go to Calendars, click the down arrow by Other Calendars, and select Browse Interesting Calendars. Click the More tab, click Resources for <your domain>, and click Subscribe next to each resource calendar that is listed.
   • Get the name of all the resource calendars exactly as they appear in the user's calendar list. Click the down arrow by Other Calendars and select Settings. Save the list of names to a file (Word, Excel, etc.) that you can access later when creating the mailbox migration project in MigrationWiz.
2. Get the names and email addresses of the resource mailboxes in the Destination On-Premises Exchange or Exchange Online environment. Save the list of email addresses to a file (Word, Excel, etc.) that you can access later when creating the mailbox migration project in MigrationWiz.
3. Create the mailbox migration project in MigrationWiz.
4. Add the support options listed below at the project level. 
   • MigrateGmailAllCalendar=1
     • This support option ensures that all calendars are migrated.
   • RecipientMapping="resource calendar email address->resource mailbox email address"
     
     Example:
     RecipientMapping="com_123456789@resource.calendar.google.com->ConfRoom1@bitrepro.com"
     
     
     • This support option maps the email address for the resource calendar from G Suite to the email address for the resource mailbox in On-Premises Exchange or Exchange Online.
     • For resource calendar email address, enter the email address of the resource calendar from G Suite obtained in step 1.
     • For resource mailbox email address, enter the email address of the resource mailbox from On-Premises Exchange or Exchange Online.
     • Add this support option for each of the resource calendars that you want to migrate. Click the +button next to each support option text box to add more support options.
     • If you create multiple mailbox migration projects for the same Source G Suite account, the recipient mapping support options for the resource calendars need to be added across all of the projects.

5. Click Save.
6. Add the resource calendar items to the mailbox migration project.
   • For the Source, enter the email address of the G Suite user account created in step 1 above. Use the same Source email address for all the resource calendars that will be migrated.
   • For the Destination, enter the email address of the resource mailbox at the Destination On-Premises Exchange or Exchange Online environment.
7. For each of the resource calendar items you added, click the pencil icon on the right and add the folder filter and support options listed below.
   • ^(?!Calendar/resource calendar name)
     
     Example:
     
     ^(?!Calendar/Conf Room 1)
     • This folder filter ensures that only the resource calendar is migrated.
     • For the resource calendar name, enter the name of the resource calendar exactly as it appears in the user’s calendar list from Step 1.
   • FolderMapping="Calendar/resource calendar name->Calendar"
     
     Example:
     
     FolderMapping="Calendar/Conf Room 1->Calendar"
     • This support option ensures that the resource calendar is migrated into the root calendar for the resource mailbox in On-Premises Exchange or Exchange Online.
     • For the resource calendar name, enter the name of the resource calendar exactly as it appears in the user’s calendar list from Step 1.
     • The spelling of the Destination calendar must reflect the system language of the Destination resource mailbox, for example, the folder mapping should be FolderMapping="Calendar/Conf Room 1->予定表" when migrating to a Japanese destination resource mailbox.
       
       Care should be taken when using resource calendar names that contain special characters in folder filters or support options. Special characters need to be prefixed with a "\" character. For example, if the name of a resource calendar is Room (1234), the folder filter needs to be entered as ^(?!Calendar/Room \(1234\)) and the support option needs to be entered as FolderMapping="Calendar/ Room \(1234\)->Calendar". Read the Special characters section of the RegEx documentation for more information. In cases where the calendar name includes the character /, an {%escape%} must be used in place of "\" that would normally be needed for special characters like ()  in the folder mapping. This needs to be added before every / in the folder name:
     • For example: 

                   FolderMapping="Calendar/Bob (4) - Tom / Jane (4)->Calendar"

                   would need to be entered as

                  FolderMapping="Calendar/Bob \(4\) - Tom {%escape%}/ Jane \(4\)->Calendar"

Click Save. You should now add all of the user mailbox items to the migration project and configure the project according to your scenario. 

Duplicate Calendar Items

Duplicate calendar items can be created when the Source is G Suite, and the resource or location of calendar items is changed while a migration is occurring.

This is because when the location of an event is updated, Google will create another item with another ID. The updated item will have a new ID, where, for example, "_R2014……” is appended to the original one. This is the item that will then be migrated - as a duplicate.

Color Management in Calendar Migrations

By default, calendar items will be migrated from GoogleApps to Microsoft 365, as part of the full migration pass.

However, if the source calendars on GoogleApps have additional colors, from those supported on Microsoft 365, then those colors will converted to the default color assigned to the calendar on Microsoft 365 when migrated.

 In order to ensure that all colors assigned to calendars on GoogleApps are converted over to Microsoft 365 properly, when the calendars are migrated, the steps below need to be followed:

On destination Office 365 tenant:

• Before a customer plans to migrate their Google calendar with those five colors to Office 365, every user needs to manually set up their Microsoft 365 calendar by creating new categories to match those five colors, using the exact category name: 
  • "Turquoise category"
  • "Gray category"
  • "Bold blue category"
  • "Bold green category"
  • "Bold red category" 
• Manually assign a matching color to the category.

If the above steps are not followed:

• If the user does not pick a specific color (in their Google calendar) for an appointment, then that appointment displays as the default color (light red). 
• When migrating this calendar item, MigrationWiz will not be able to match the color in the Destination (Microsoft 365)
• Therefore, the appointment color will be converted to the default color of Microsoft 365 calendar appointments.

Google Resources

In Google, if you are not the event organizer, you can only create that event in another user's primary calendar. Since a resource in Google is not anybody's primary calendar, MigrationWiz cannot migrate other users' events into the resource calendar.

Migrating Contacts

Contacts may behave differently between environments. More specific details are provided in the migration guides for each scenario if necessary, but there are a few general cases.

Contacts API sunsetting and adoption of People API

Google is shutting down the Contacts API on June 15, 2021. Click here to read the official announcement from Google. As per guidelines from Google, MigrationWiz is switching over to using People API.

• Effective June 3rd, 2021, all new mailbox migration projects set up with Google as source or destination will use People API. Please refer to the respective migration guide to capture the relevant details required for project setup.

  • All existing projects that are set up before the People API change is implemented on June 1st will continue to use Contacts API by default.  We would recommend completing such projects before June 15th. After June 15th, such projects may encounter errors while migrating contacts.

Here is the summary of new changes required during the project setup:

• • If you are using your own Google service account, please make note of the following:

    1. Enable People API for your service account project.

    2. Add new OAuth scope for source tenant: https://www.googleapis.com/auth/contacts.other.readonly

    3. Add new OAuth scope to the list of existing scopes for destination tenant:
       https://www.googleapis.com/auth/contacts

  • If you are using the BitTitan service account, please make note of following:

    1. Add new OAuth scope for source tenant: https://www.googleapis.com/auth/contacts.other.readonly

    2. Add new OAuth scope to the list of existing scopes for destination tenant:
       https://www.googleapis.com/auth/contacts

With the implementation of People API to migrate contacts, please make note of the following limitations/known behaviors:

1. 1. We are unable to update "Other Contacts" at destination (Google). 

      1. When you select the advanced option to migrate 'Other Contacts', Contacts appearing under the ‘Other Contacts’ label in the source will be migrated to the destination with the label 'Suggested contacts'. 

      2. Please note that the contact information for 'Other Contacts' migrated to the destination will only support name, email, and phone numbers. Other fields are not supported.

   2. Hidden contacts from source (Google) will not retain the 'hidden' property when migrated to the destination. These contacts will show up under the main contact lists as well as with associated labels.

Suggested Contacts

Suggested contacts are placeholder contacts that Gmail creates automatically, based on the email addresses you send emails to and receive emails from. Creating these contacts enables recipient auto-completion when you compose a new email. By default, we do not migrate suggested contacts. However, if you wish, MigrationWiz can migrate suggested contacts.

To enable migration of suggested contacts:

1. Sign in to your MigrationWiz account.
2. Edit your Project.
3. Click on Advanced Options.
4. Under Contact Handling, click on Migrate Suggested Contacts.
5. Click on Save Options.

File Location

Because Exchange does not identify suggested contacts as a system folder, we will always migrate content to a root folder called Suggested Contacts.

Extra Contacts Advanced Option

When migrating from Google to an alternative Destination email platform, there are some differences between the field formats on each platform.

If you have users that have many additional contacts that are not migrated, by default, to the Destination, then you can add this Advanced Option to your project. This needs to be added within the Support section, under Support Options.

The Advanced Option is: StoreOverflowGooglePropertiesInNotes=1

With this Advanced Option flag set, when contacts are migrated for the mailbox, the additional contact properties (that cannot be mapped) will be added to the end of the contact notes.

These include the following:

• Unmapped email addresses
• Unmapped instant messenger addresses
• Unmapped phone numbers
• Unmapped physical addresses
• Unmapped data-based events (like anniversary)
• Unmapped relationships (like brother)

You can also add an additional Advanced Option whereby you can define your "header" that will appear above these additional contact properties:

The Advanced Option is:

StoreOverflowGooglePropertiesInNotesPrefix="---- The following properties could not be mapped ---"

If you have already performed a migration for the user, then in order to map these additional contact properties, you will need to follow these steps:

1. Delete the contacts from the Destination.
2. Reset statistics. Click on the Reset Items icon on MigrationWiz dashboard. All migration statistics (speed, number/size of items migrated, etc.) and errors details (number/size of failed items, etc.) will be deleted for all selected items. Click Reset Items.
3. Add the Advanced Option: StoreOverflowGooglePropertiesInNotes=1
4. From the MigrationWiz dashboard, click on Edit Project, and then select Advanced Options.
5. Within the Support section, under Support Options, add the following:
   1. StoreOverflowGooglePropertiesInNotes=1
   2. Click the +
   3. Click Save Options.
   4. Click  Save Project.
   5. Select one or more mailboxes that you want to remigrate.
   6. Click Start.
   7. From the drop-down list, select Full Migration.
   8. Deselect all items except Contacts.
   9. Click Start Migration.

Migrating Google Contact Groups

When you click on a G Suite group, the same contact record is displayed. If you make a change to the contact under one group, changes are visible when you click on the other group.

Exchange works differently. We map G Suite contact groups to Exchange folders. There is no way to place the same contact record under both folders. Changes made to the contact under one folder are not visible when you click on the other folder because the two records are different.

Contacts Field Mappings

Contacts handling – the default behavior is to skip suggested contacts.

• An Advanced Option can be set to migrate suggested contacts instead.
• All contacts are migrated to the contacts system folder of the Destination.
• Folders from the Source are recreated on the Destination to match the Source.

Migration of all properties with the following exceptions (these exceptions are due to Exchange limits):

• Migration of up to three email addresses
• Migration of up to one of each phone category
• Migration of up to one of each address category
• Migration of up to one anniversary
• Migration of up to one birthday
• Migration of up to three instant messaging categories. Technically, Exchange supports up to three IMs without category; however, the most recent UI displays only one.
• Migration of up to one person in each of the following categories: spouse, partner, manager, domestic partner, child, assistant
• Migration of photos appear as attachments to Exchange 2007. Technically, a photo is an attachment, but after the migration it shows up as the contact’s photo.
• Do not migrate custom fields
• Do not migrate groups

G Suite contact fields that are populated by Google Directory services are not migrated.

Forwarding

For more information on how to set up a forwarding address in G Suite, read the Automatically forward emails to another account article from Google.

Troubleshooting

This section covers issues that are not errors. For cause and resolution information on G Suite migration errors, visit our Error Lookup.

Google throttling limits 

Google has strict throttling limits. If these limits are reached, it could result in the account being locked out for 24 hours, which may negatively impact your migration plan.

When migrating from G Suite, you should refer to the migration guide that matches your scenario. Migration guides can be found by selecting the type of migration from the main Help Center page, then selecting your Source environment.  On the next page, click on Migration Guides, then select the appropriate guide for your migration. Each guide includes steps to filter out the All Mail folder until the last pass. By following the steps in the guides, you will not be affected by the issues below.

The main limit to be aware of when performing migrations from G Suite is of folders in a mailbox containing too many items.

• Issues can occur when you are migrating folders that contain over 100,000 items. Note that the All Mail folder can reach this size.
• If you try to migrate the All Mail folder in one pass, you may hit Google throttling limits. The best way to avoid this issue is to migrate in stages, as directed in the migration guides.

G Suite uses throttling both when retrieving and pushing data. Throttling limits are different for retrieving data vs. pushing data.

Google may lock your account for 24 hours if they consider that too much data has been retrieved from their servers in a given amount of time.

If that occurs, we recommend pausing the migration and submitting a delayed migration (after 24 hours).

Also, G Suite imposes a hard limit of one (1) item per second when migrating to G Suite. MigrationWiz adjusts migration throughput accordingly, but remains subject to those limits.

IMAP

These topics relate only to IMAP access and settings, not the IMAP endpoint in G Suite migrations. 

IMAP access for desktop clients

You can either enable or disable POP and IMAP for your users via the simple process below. POP access is automatically enabled for your users. However, note that this action will apply to all users in your domain. If IMAP is disabled, users can no longer access their POP/IMAP settings in the Gmail interface, nor will they be able to access their mail via POP/IMAP (such as through Google Desktop), even if previously enabled.

1. Sign in to the Google Admin console.
2. From the dashboard, go to Apps > G Suite > Gmail > Advanced settings.
3. In the Organizations section, select the organizational unit for which you want to configure settings.
4. Under POP and IMAP Access, select or clear the checkbox for Disable POP and IMAP access for all users in the domain.

It may take 15-30 minutes for IMAP and POP changes to take effect. As long as the box is cleared, users can configure POP and IMAP access for a host of clients.

Removing size limits on IMAP folders

G Suite has a setting that can limit the number of messages in an IMAP folder. If this is configured, this will restrict MigrationWiz so that it can only retrieve and migrate that number of messages from each folder.

Follow these steps to see if this has been set by a user, and how to change it so that there is no limit set:

1. Log in to the account.
2. Click on the gear icon in the upper right-hand side of the window, and choose Settings.
3. Click on the Forwarding and POP/IMAP tab.
4. Under the IMAP Access heading, look for Folder Size Limits.
5. Ensure that Do not limit the number of messages in an IMAP folder (default) is selected.

To further clarify the implications of this setting: If the limit has been set (e.g., to 1,000 as per the default suggestion), then if folders contain more than 1,000 items, they will be truncated at 1,000 items. This means that MigrationWiz will only be able to migrate 1,000 emails from each folder.