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 |
|
| 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.
