5. Complete pretransfer tasks

Source and destination environments each have their own tasks that you must complete before a Google Workspace Domain Transfer can be authorized.

After each dry run, results are provided by the Domain Transfer team detailing which pretransfer tasks are outstanding and how they can be resolved.

Complete these tasks before the transfer

Expand all  |  Collapse all

Step 1: Source tasks

1. Upgrade licenses (if applicable)—Licenses are not moved as a part of the transfer process. If the source environment is using a different Google Workspace edition than the destination environment, you need to upgrade the source to match the destination. For more information, review license transfers under Destination tasks.

   Notes:

   • You can use grace or trial licenses in the source environment for temporary license procurement to avoid costs. However, note the following points:
     • These licenses block the process of swapping the placeholder domain with the primary domain. Swap the placeholder domain with the primary domain before you provision any temporary licenses.
     • If the available licenses in the destination environment are full licenses, users are assigned full licenses as a result of the transfer.
   • Users in the source environment who have no licenses assigned to them still transfer.
2. Cancel unsupported license subscriptions—There might be implications to canceling license subscriptions. Source environments with Google Voice must pay extra attention to this step. For details, go to Source licenses.
3. Add a placeholder domain to Google Workspace (if applicable)—Add and verify a new secondary domain name in the source environment that will eventually replace the existing primary domain. If a secondary domain exists and doesn't need to be transferred, you can use it instead. For details, go to Add a user alias domain or secondary domain.
4. Create a placeholder administrator and make it the primary administrator of the account—Create a user account associated with the placeholder domain. If you repurpose an old account, make sure no other transfer domains existing as aliases are attached to the account. Grant this user the super administrator role and make them the primary administrator on the account. For more information, go toSend billing and account notifications to another admin.

   Note: Make sure that Google 2-Step Verification is turned off for this account and that you sign in at least once to verify access.

5. Swap the primary domain with the placeholder domain—Perform a domain swap, promoting the placeholder domain as the new primary domain.

   Before you swap your domain:

   When you're ready to swap, go to Change your primary domain for Google Workspace.

   • Cancel all device subscriptions, including Google Meet hardware, Chrome Enterprise, and Jamboard.
   • Some unsupported licenses might need to be removed before the transfer. For details, go to Source licenses.
   • If the source environment has trial licenses, the swap will be blocked. Make sure the swap occurs before any temporary licenses are provisioned.
   • Changing the primary domain and using secondary domains has known issues. Review Alternatives to changing your primary domain.
   • Do not rename transfer users or groups after changing the primary domain name. Users and groups should be kept on their transfer domains.
   • If you set up SSO using a third-party identity provider and you're using a domain-specific issuer, the SAML assertion changes to reflect the new primary domain. Check your identity provider's configuration to ensure that users can authenticate after the primary domain swap. For details, go to SSO assertion requirements.
6. Establish Google Vault retention rules—Set up indefinite custom retention rules.

   Create one rule for the following applications:

   • Gmail—For Organizational unit, select the root organizational unit.
   • Google Groups—For Groups, select All groups.

   Create 2 rules for the following applications:

   • Chat—Select Organizational unitthe root organizational unit. For the second rule, select All Chat spaces.
   • Drive—Select Organizational unitthe root organizational unit. For the second rule, select All shared drives.
   • Meet—Select Organizational unitthe root organizational unit and turn on Include items from shared drives. For the second rule, select All shared drives.
   • Sites—Select Organizational unitthe root organizational unit and turn on Include items from shared drives. For the second rule, select All shared drives.

   In addition, indefinite custom retention rules are set up in the destination environment before the transfer. For details, go to Indefinite Google Vault retention in the destination environment. For more information about transferring from Vault, go to Transfer your Vault data with domain transfer.

7. Update your Sender Policy Framework (SPF) record (if applicable)—If the destination environment is using an outbound gateway that's different from the source environment, the source should update their SPF record to include the outbound gateway.

   Note: If you're using DomainKeys Identified Mail (DKIM), the transfer shouldn't impact your Domain-based Message Authentication, Reporting, and Conformance (DMARC) policy. The SPF record will continue to align post transfer, even if DKIM temporarily does not. Also, make sure to complete the DKIM post-transfer task in the destination environment.

8. Resolve calendar resource conflicts—If there are any calendar resource conflicts, resolve them before proceeding:
   • Building IDs—A building ID in the source environment cannot be the same as a building ID in the destination environment. To bypass the transfer block, you have 2 options. You can delete the building in the source environment. Or, you can make the 2 buildings' details identical to merge the source and destination buildings. To make the 2 buildings identical, make the ID, name, all address fields, description, and floor exactly the same for both buildings.
   • Building names—If a building resource in the source environment has the same name as a building resource in the destination environment, you must change the name of one of the resources to resolve the conflict. After the transfer process completes, you can merge the 2 building resources.
   • Resource IDs—A resource in the source environment that has the same Resource ID as a resource in the destination creates a conflict that can't be resolved by the transfer process, and the resource won't transfer. Delete one of the conflicting resources and re-create it with a non-conflicting ID. It takes 30 days for a deleted resource to be completely cleared from the system. You can either wait for the resource to be completely deleted, or the Domain Transfer team can submit a request to manually delete it.
9. Evaluate impact to the associated Google Cloud organization (if applicable)—If Google Cloud is being used, notify the administrators of that environment regarding the potential impacts. Google Workspace Domain Transfer might have on Google Cloud. If necessary, involve your Google Cloud partner or contacts at Google Cloud for help with evaluating impacts and remediation steps. The Google Workspace Domain Transfer team doesn't offer assistance with Google Cloud during a domain transfer engagement.
10. Notify your Google Workspace reseller (if applicable)—Let them know of the planned domain transfer time and request that they do not change the account (for example, update subscriptions) during the transfer period.
11. Enroll in any alpha or beta programs the source or destination environment is participating in (if applicable)—Google Workspace Domain Transfer doesn't transfer alpha and beta program enrollments in the source environment. Likewise, the destination environment might have enrollments in which the source environment depends. The unenrolled environment needs to apply to and be accepted into those programs to continue to use them.

    We recommend that you enroll for alpha or beta programs before you transfer so that your transfer users have the same features available throughout the transfer process. However, the enrollment process might take some time and success isn't guaranteed. Therefore, it's recommended but not required.

12. To transfer Chrome zero-touch enrolled devices:
    1. In the source environment, revoke the existing preprovisioning token and deprovision all devices. Reset the devices back to the factory default.
    2. In the destination environment, create a new preprovisioning token.
    3. Provide the new token to your authorized preprovisioning partner. Your partner uses the token to preprovision the devices in the destination environment.

       The devices enroll themselves once they're connected to the internet. The device state changes to Provisioned.

    For more information on zero-touch devices, go to Zero-touch enrollment.

Step 2: Destination tasks

1. Licenses are not moved as a part of the transfer process so you must provision enough spare Google Workspace licenses to support all transfer users—When you transfer users, they’re assigned the same set of licenses in the destination environment they had in the source environment. Therefore, there must be enough spare licenses of the same type in the destination environment at the time of the transfer.

   If the destination environment is using a different Google Workspace edition than the source environment, make sure the licenses match by upgrading the licenses either in the source or destination environment.

   Notes:

   • Google recommends upgrading licenses to prevent triggering the service wipeout process (SWP).
   • Provision any missing licenses so multiple subscriptions exist in the destination environment. You can optionally upgrade or downgrade individual user licenses after the transfer. Note that not all license types support Partial Domain Licensing (PDL).
   • Make sure enough spare licenses are available in the destination environment. Consider if more users are added (for example, new hires) to each source environment between the start and end of the transfer process. If there’s multiple transfers, you must also account for the total number of source users across all transfers.
   • Users in the source environment who have no licenses assigned to them still transfer. Monitor how licenses are autoassigned in the destination environment to make sure these users do not get licenses.
   • Google Workspace Domain Transfer does not offer special Google Workspace billing plans to accommodate the purchase of spare licenses during the transfer. If the source environment licenses are under an annual billing plan, they remain active and are billed until the end of your annual plan contract. The use of grace and trial licenses are supported in the source environment only, which may aid this process. Consult your sales representative or account manager if you have more questions regarding Google Workspace billing plans. 
2. Ensure licenses are correctly applied to transfer users when multiple licenses exist—Some configurations within the destination environment might impact the way transfer users are assigned licenses. This situation might result in transfer users ending up with a different license than expected. These configurations include automatic licensing and overriding automatic licensing for specific organizations.

   To make sure there are no unexpected licensing changes during the transfer, you must apply the following actions:

   • If the destination environment’s automatic licensing configuration is "Off for everyone" or if the destination environment only has a single license type, then no changes are required.
   • If the destination environment’s automatic licensing configuration is "On for everyone" (for example, Google Workspace licenses), then make sure overriding is on for specific organizational units. Set the transfer root organizational unit to "Off" with no further overrides for its child organizational units.
3. Create the transfer root organizational unit and, optionally, re-create the source environment organizational unit structure—Create an organizational unit to serve as the parent organizational unit for all transfer users. Once created, you have 2 options:
   • Do nothing—The Google Workspace Domain Transfer process re-creates the organizational unit structure from the source environment under the new transfer root organizational unit. To do this step, set the transfer option "recreate the organizational unit structure in advance" to No. All incoming transfer users inherit policies you apply at the transfer root organizational unit level.
   • Manually re-create the source environment organizational unit structure under the transfer root organizational unit—Google Workspace Domain Transfer ensures that the source environment's entire organizational unit structure is properly replicated before proceeding with the transfer. To do this step, set the transfer option "recreate the organizational unit structure in advance" to Yes. This option is useful if you want to set distinct policies on different child organizational units.

     Note: Google Workspace Domain Transfer only validates the organizational unit structure. It’s your responsibility to make sure the appropriate policies are set on the organizational units.

4. Establish the appropriate policies and settings to reflect the source and destination environment requirements—Policies and settings in the source environment do not transfer to the destination environment. Additionally, after the transfer process completes, only the policies and settings in the destination environment apply to transfer users and their data.

   You must review your policies and settings in the destination environment and compare them with the source environment. This action includes both general and specific settings for the transfer root organizational unit to make sure that they cover all incoming transfer entities and users.

   The following is a non-exhaustive list of policies and settings you should verify as part of the setup process. Also, perform a full audit of both environments to make sure all relevant sections are analyzed:

   • Service Enablement (On/Off)—Verify that the services you use in the source environment are turned on in the destination environment, and the transfer root organizational unit behaves as expected. It’s especially important when using Google Vault, because Vault rules might not apply if the service is off.
   • Gmail, advanced settings, and MX records—Review settings such as mail routing, compliance rules, IMAP enablement, delegation, and Google Sync. For details, go to Activate Gmail with Google Workspace.
   • Password management—Review your password policies to make sure they’re aligned with your organization’s procedures. Once transfer users are moved to the destination environment, they inherit the password management policies in the destination environment.
   • 2-Step Verification—Controls whether users are allowed to add a 2-Step Verification configuration to their account, whether it’s allowed or it’s enforced. If transfer users with 2-Step Verification turned on are transferred into a destination environment or organizational unit where 2-Step Verification is turned off, destination administrators will be unable to manage them. Instead, admins can either move these users to a different organizational unit where 2-Step Verification is turned on to make changes, or they can remove 2-Step Verification from accounts before the transfer.
   • Sharing settings—Controls whether users can share their content outside the organization. If the source environment blocks sharing and the destination environment does not, then transfer content might be accessible outside your organization. If the source environment has open sharing by default and the destination environment does not, then transfer content might be inaccessible to users in your organization. Learn more about sharing options for Google Drive, classic Google Sites, and Google Calendar.
   • Data loss prevention (DLP) rules—Monitors and prevents users from sharing sensitive information outside your organization. When DLP prevents users from sharing information in the source environment, and content is transferred into a destination environment without DLP setup, users in the destination environment can share information outside your organization. Learn more about Gmail DLP rules and Drive DLP rules.
   • Chat history—Controls whether chat history is on or off the record, and whether users can set enforcement on all chats or make it the default. If the source environment allows for chat history to be turned on, but the destination environment forces it to be off, then chat history is lost. While Google Chat is listed as unsupported for the transfer, direct messages (DMs) will transfer.
   • Data countries/regions—Controls which specific geographic location to store your migrated data. Transfer users that need to stay in a specific geographic location must have this policy set appropriately in the destination environment to make sure their data does not unexpectedly leave their required data country/region. For details, go to Data regions: Choose a geographic location for your data.
   • Less secure apps (also known as App Passwords)—If less secure apps are turned on in the source environment and are turned off in the destination environment, the connection with the application using less secure apps time out and close. Timeout periods vary by application, but usually expire within 60 minutes. Future access requests made by the insecure application are blocked. For details, go to Control access to less secure apps.
   • OAuth scopes, single sign-on (SSO) for SAML, trusted apps, and Chrome extensions—OAuth controls determine the level of API access allowed to users and third-party applications. SSO for SAML, whether supplied by Google Workspace or implemented as a custom application, allows users to leverage their Google Workspace credentials to access other applications or services. Trusted apps determine the applications users can install from the Google Workspace Marketplace or Chrome Web Store and which apps are allowed to bypass OAuth restrictions. Learn more about how to control third-party & internal apps, SAML SSO, Google Workspace Marketplace apps, and Chrome apps and extensions.
   • Domain-wide delegation—Allows apps to access users' Google Workspace data. To ensure the clients and scopes are working correctly, set up domain-wide delegation in the destination environment before the transfer.

   Important: Being unable to properly establish policies and settings might result in:

   • Inadvertent exposure of your data outside your organization (for example, the destination environment has more open settings than the source environment)
   • Restricted access to previously accessible data (for example, the destination environment has more restrictive settings than the source environment)
5. Accept agreements that govern transferred data—Review the Data Processing Amendment (DPA), model contract clause, and HIPAA Business Associate Amendment (BAA) in the destination environment. For details, go to Privacy compliance and records for Google Workspace and Cloud Identity.
6. Turn on Vault if it's used in the source environment—If the destination environment is not using Vault but the source environment is, the destination environment must turn on Vault.
7. Notify your Google Workspace reseller (if applicable)—Let them know of the planned domain transfer time and request that they do not change the account (for example, update subscriptions) during the transfer period.
8. Enroll in any alpha or beta programs the source or destination environment is participating in (if applicable)—Google Workspace Domain Transfer doesn't transfer alpha and beta program enrollments in the source environment. Likewise, the destination environment might have enrollments in which the source environment depends. The unenrolled environment needs to apply to and be accepted into those programs to continue to use them.

   We recommend that you enroll for alpha or beta programs before you transfer so that your transfer users have the same features available throughout the transfer process. However, the enrollment process might take some time and success isn't guaranteed. Therefore, it's recommended but not required.

Important:

• Downgrading licenses might cause a loss in Google Workspace services and functionality. Carefully review the differences between Google Workspace editions and the impact of both upgrading and downgrading before making any changes. Learn more about Google Workspace editions.
• Downgrading licenses might trigger the SWP, which can delay a transfer for up to 90 days.

Step 3: Other tasks & considerations

• Change management—Both the Google Workspace Domain Transfer team or the transfer process do not automatically provide users with information on the transfer's execution during the transfer process. It's highly recommended that source and destination environment representatives inform users of the transfer process, and its potential impacts, in advance.

  All admin actions in both the source and destination environment are blocked during the transfer, including API and Google Admin console access. It's highly recommended that source and destination environment representatives notify all domain super admins and delegated admins before the transfer and once it completes.

• External dependencies—If you use Google Cloud Directory Sync (GCDS), GAM (a third-party command-line tool for Google Workspace administrators to manage domain and user settings), or a third-party single sign-on (SSO) provider, make sure to analyze the effect of the transfer. Also examine how having the source and destination environments coexisting in a single environment affects your system and the timing of your transfer execution.

Indefinite Google Vault retention in the destination environment

Google Workspace Domain Transfer sets up indefinite custom retention rules in the destination environment. No action is required by destination environment admins. 

The Vault archive for transfer users is moved, but Vault retention rules from the source environment are not. To make sure no Vault data is in jeopardy during and after the transfer, the transfer process creates the following Vault retention rules in the destination environment before it executes any transfer actions:

• Gmail—Indefinite custom retention rule (scope: transfer root organizational unit).
• Google Calendar—Indefinite custom retention rule (scope: transfer root organizational unit).
• Google Chat—Indefinite custom retention rule (scope: direct messages with transfer users in the transfer root organizational unit, but not Spaces).
• Google Drive—Indefinite custom retention rule, not including shared drives (scope: transfer root organizational unit).
• Google Groups—Indefinite custom retention rule (scope: root organizational unit). Retains data for all groups in the destination environment, including those not included in the transfer process.
• Google Meet—Requires 2 indefinite custom retention rules:
  1. Not including shared drives (scope: transfer root organizational unit).
  2. Including all shared drives (scope: root organizational unit).

     Retains data for all shared drives in the destination environment, including those not included in the transfer process.

• Google Sites—Requires 2 indefinite custom retention rules.
  1. Not including shared drives (scope: transfer root organizational unit).
  2. Including all shared drives (scope: root organizational unit).

     Retains data for all shared drives in the destination environment, including those not included in the transfer process.

• Shared drives—Indefinite custom retention rule on all shared drives (scope: root organizational unit). Retains data for all shared drives in the destination environment, including those not included in the transfer process.

Important: Vault retention rules in the destination environment are not removed or modified during the transfer process, as doing so could potentially cause irreversible data loss.