Watchpoints for Domain Transfer

Before you begin a Google Workspace Domain Transfer, make sure you familiarize yourself with the following points.

Feature	Watchpoints
Alpha and beta programs	Google Workspace Domain Transfer will not transfer alpha and beta program enrollments. If there are specific programs either the source or destination environment is enrolled in that the other environment is not, the unenrolled environment needs to apply to and be accepted into those programs. If the destination is enrolled in domain-specific programs, any new source domains need to be admitted. It's recommended enrollment is done pre-transfer so the experience and available features for transfer users is the same throughout the transfer process.
Google Cloud	Once transferred, users and groups from the source environment are considered external to the Google Cloud organization associated with the source environment or placeholder domain. Migration of Google Cloud projects might be a complex process, depending on the nature of the projects. If a migration is required, it can happen before or after the transfer process. However, we do not recommend coupling the 2 projects together. Your Google Cloud contact can connect you with a team at Google that manages Google Cloud project migration. Google Cloud projects attached to Apps Script files remain in the source environment. Learn more about how Domain Transfer interacts with Google Cloud.
Users	Deleted users don't transfer. You shouldn't delete or restore users from the source environment within the 48-hour period before the transfer. Deleting or restoring can delay the transfer. Tip: We recommend that you restore any deleted users and suspend or archive them instead. You must complete the process at least 48 hours prior to the transfer so users are transferred to the destination environment. Then, you can restore or delete them when the transfer process completes. You can't restore deleted users in the source environment after the transfer completes, as the source domain associated with the users no longer exists.
Google Groups	All groups with the domain name of a transfer domain will transfer to the destination environment. If a group includes "all users in the source," it will include all destination users posttransfer. Other services might be impacted (such as a Calendar event with a group attendee). Learn more about how Domain Transfer interacts with the Groups.
Google Workspace issues	Visitor accounts (used for PIN code sharing) might cause transfer user renames to be unsuccessful in the destination
Identity	Identity merge or deduplication is not supported during the transfer process. Learn more Provisioning systems and third-party identity providers (such as Okta) need to be updated to account for transfer users within the destination environment. Configuration of third-party systems by Google is outside the scope of the transfer process.
Licenses	Unsupported licenses, such as Google Meet hardware and Jamboard, will block the swap between the primary domain and the placeholder domain. Procuring new licenses, resolving offline arrangements, and avoiding extra licensing costs are outside the scope of the transfer process.
Policies & settings	Most policies or settings from the source environment are not included in the transfer. This includes items like service and feature enablement by organizational unit or group, mail routing, compliance and DLP rules, Google Drive or OAuth access lists, passwords, trusted applications, SSO for SAML, and data countries/regions.
Transfer options	If the stripped transfer option for Google Drive link sharing was selected, users will lose access to documents if the documents were not directly shared with them. Learn more Upgrading licenses might cause Google Vault to be turned on and require the addition of source environment Vault rules, even if the environment does not currently use Vault.

License implications

There are also some license connotations to using Google Workspace Domain Transfer.

Partial Domain Licensing

Partial Domain Licensing (PDL) lets administrators license only some of their active users. There are several items to consider though:

• Not all Google Workspace or G Suite licenses support the ability to coexist with other licenses.
  • Google Workspace licenses cannot coexist with legacy G Suite licenses.
  • Enterprise Plus and Enterprise Standard cannot coexist with Business Plus and Business Standard.
  • Essentials Starter, Essentials, Enterprise Essentials, and Enterprise Essentials Plus cannot coexist with other Google Workspace or G Suite licenses.
• Generally, non-primary licenses (for example, Chrome Enterprise, Google Meet, Jamboard, Vault Former Employee, etc.) are designed to coexist with a primary license.

Service wipeout process

The service wipeout process (SWP) might be triggered when a Google Workspace account license is downgraded.

The SWP removes all customer data associated with the turned off Google services on the downgraded Google Workspace edition. It’s a necessary legal requirement in circumstances where General Data Protection Regulation (GDPR) must be met.

Google identifies when an account must undergo the SWP. The customer starts the SWP when they downgrade. Google confirms both the downgrade and the SWP action before continuing with the transfer process.

The SWP takes up to 90 days to complete and cannot be expedited. If a downgrade is required, it must be started and completed before the domain transfer continues (they cannot run in parallel). Running the SWP will delay the start of the domain transfer process.