This document describes how you can migrate consumer accounts to managed user accounts controlled by Cloud Identity or Google Workspace.
If your organization hasn't used Cloud Identity or
Google Workspace before, it's possible that some of your employees are
using consumer accounts to access Google services. Some of these consumer
accounts might use a corporate email address such as [email protected] as
their primary email address.
Consumer accounts are owned and managed by the individuals who created them. Your organization therefore has no control over the configuration, security, and lifecycle of these accounts.
Before you begin
To migrate consumer accounts to Cloud Identity or Google Workspace, you must meet the following prerequisites:
- You have identified a suitable onboarding plan and have completed all prerequisites for consolidating your existing user accounts.
- You have created a Cloud Identity or Google Workspace account and have prepared the default organization unit (OU) to grant appropriate access to migrated user accounts.
Each consumer account that you plan to migrate must meet the following criteria:
- It can't be a Gmail account.
- It must use a primary email address that corresponds to the primary or a secondary domain of your Cloud Identity or Google Workspace account. In the context of a consumer account migration, alternate email addresses and alias domains are ignored.
- Its owner must be able to receive email on the account's primary email address.
Converting a consumer account to a managed account implies that the user who registered the consumer account passes control of the account and its associated data to your organization. Your organization might require employees to sign and adhere to an acceptable-email-use policy that disallows the use of corporate email addresses for private purposes. In this case, you can safely assume that the consumer account has been used only for business purposes. However, if your organization doesn't have such a policy or the policy allows certain personal use, the consumer account might be associated with a mixture of corporate and personal data. Given this uncertainty, you can't force the migration of a consumer account to a managed account—a migration therefore always requires the user's consent.
Process
Migrating consumer accounts to managed accounts is a multi-step process that you must plan carefully. The following sections walk you through the process.
Process overview
The goal of migrating is to convert a consumer account into a managed user account while maintaining both the identity of the account as reflected by its email address, and any data associated with the account.
During a migration like this, an account can be in one of four states, as the following state machine diagram shows.
When you add and verify a domain in Cloud Identity or Google Workspace, any consumer account that uses an email address with this domain becomes an unmanaged account. For the user, this has no impact; they can sign in and access their data as normal.
Adding a domain in Google Workspace or Cloud Identity affects
only users whose email address matches this exact domain. For example, if you
add example.com, the account [email protected] is identified as an
unmanaged account, while [email protected] is not unless you also add
corp.example.com to the Cloud Identity or Google Workspace
account.
The existence of unmanaged accounts is surfaced to you as the Cloud Identity or Google Workspace administrator. You can then ask the user to transfer their account into a managed account.
In the preceding diagram, if the user johndoe consents to a transfer, the
unmanaged account is converted to a managed account. The identity remains the
same, but now Cloud Identity or Google Workspace controls the
account, including all of its data.
If the user johndoe doesn't consent to a data transfer, but you create an
account in Cloud Identity or Google Workspace using the same email
address, the result is a conflicting account. A conflicting account is
actually two accounts—one consumer, one managed—that are associated with the
same identity, as in the following diagram.
A user who signs in by using a conflicting account sees a screen prompting them to select either the managed account or the consumer account to resume the sign-on process.
To avoid ending up with conflicting accounts, it's helpful to understand account states in more detail.
Process in detail
The following state machine diagram illustrates account states in more detail. Rectangular boxes on the left denote actions a Cloud Identity or Google Workspace administrator can take; rectangular boxes on the right denote the activities only the owner of a consumer account can perform.
Find unmanaged user accounts
When signing up for Cloud Identity or Google Workspace, you must provide a domain name, which you're then asked to verify ownership for. When you've completed the sign-up process, you can add and verify secondary domains.
By verifying a domain, you automatically initiate a search for consumer accounts that use this domain in their email address. Within about 12 hours, these accounts will be surfaced as unmanaged user accounts in the transfer tool for unmanaged users.
The search for consumer accounts considers the primary domain registered in Cloud Identity or Google Workspace as well as any secondary domain that has been verified. The search tries to match these domains to the primary email address of any consumer accounts. In contrast, alias domains registered in Cloud Identity or Google Workspace as well as alternate email addresses of consumer accounts aren't considered.
Users of affected consumer accounts aren't made aware that you verified a domain or that you identified their account as an unmanaged account. They can continue to use their accounts as normal.
Initiate a transfer
In addition to showing you all unmanaged accounts, the transfer tool for unmanaged users lets you initiate an account transfer by sending an account transfer request. Initially, an account is listed as Not yet invited, indicating that no transfer request has been sent.
If you select a user and send an account transfer request, the user receives an email similar to the following. Meanwhile, the account switches to being listed as Invited.
Accept or decline a transfer
Having received the transfer request, an affected user might simply ignore it and continue to use the account as normal. In this case, you can send another request, repeating the procedure.
Alternatively, the user might follow up on the email, but decline the transfer. This causes the user to be listed as Declined in the transfer tool. If you suspect that declining was unintentional, you can repeat the procedure by sending another request.
In both cases, the functionality of the unmanaged account is unimpaired—users are able to sign in and access their data. However, the process of migrating account data to Google Workspace or Cloud Identity is impeded as long as a user keeps ignoring or declining a transfer request. To prevent this from happening, make sure that you communicate your migration plan to employees before you send the first transfer requests. Also make sure that employees are fully aware of the reasons and consequences of accepting or declining a transfer request.
Rather than declining the request, a user might also change the email address of the account. If the user changes the primary email address to use a domain that hasn't been verified by any Cloud Identity or Google Workspace account, this causes the account to become a consumer account again. Although the transfer tool might still temporarily list the user as an unmanaged account, you can no longer initiate an account transfer for such a renamed account.
Create a conflicting account
If at any point you create a user account in Cloud Identity or Google Workspace with the same email address as an unmanaged user account, the Admin Console warns you about an impending conflict:
If you ignore this warning and create a user account anyway, this new account, together with the unmanaged account, becomes a conflicting account. Creating a conflicting account is useful if you want to evict an unwanted consumer account, but it's better to avoid it if your goal is to migrate a consumer account to Cloud Identity or Google Workspace.
Creating a conflicting account can happen unintentionally. After signing up for Cloud Identity or Google Workspace, you might decide to set up single sign-on with an external identity provider (IdP) such as Azure Active Directory (AD) or Active Directory. When configured, the external IdP might automatically create accounts in Cloud Identity or Google Workspace for all users that you enabled single sign-on for, inadvertently creating conflicting accounts.
Use a conflicting account
Each time the user signs in using a conflicting account, they see a ballot screen like the following.
When they select the first option, the sign-in process continues using the managed part of the conflicting account. They are asked to provide the password that you set for the managed account, or if you configured single sign-on, they are redirected to an external IdP to authenticate. After they are authenticated, they can use the account like any other managed account—however, because none of the data has been transferred from the original consumer account, it's effectively a new account.
When choosing the second option in the ballot screen, the user is prompted to change the email address of the consumer part of the conflicting account.
By changing the email address, the user resolves the conflict by ensuring that the managed account and consumer account have different identities again. The result remains that they have one consumer account that has all their original data, and one managed account that doesn't have access to the original data.
The user can postpone renaming the account by clicking Do this later. This
action turns the account into an Evicted state. In this state, the user sees
the same ballot screen every time they sign in, and the account is assigned a
temporary gtempaccount.com email address until renamed.
Another way to resolve the conflict is to delete the managed account in Cloud Identity or Google Workspace, or if they use single sign-on, in the external IdP. This causes the ballot screen to not be shown the next time they sign in using the account, but the user still needs to change the email address of the account.
If the user changes the email address to a private email address, the account remains a consumer account. If the user decides to change the email address back to the original corporate email address, the account becomes an unmanaged account again.
Complete a transfer
If a user accepts the transfer, the account is surfaced in Cloud Identity or Google Workspace. The account is now considered a managed account, and all data associated with the original consumer account is transferred to the managed account.
If Cloud Identity or Google Workspace is not set up to use an external IdP for single sign-on, the user can sign in using their original password and continue to use the account as normal.
If you do use single sign-on, the user won't be able to sign in with their existing password anymore. Instead, they're sent to the sign-in page of your external IdP when attempting to sign in. For this to succeed, the external IdP must recognize the user and permit single sign-on. Otherwise, the account becomes locked out.
Best practices
If you intend to migrate existing consumer accounts to either Cloud Identity or Google Workspace, plan and coordinate the migration steps in advance. Good planning avoids disrupting your users and minimizes the risk of inadvertently creating conflicting accounts.
Consider the following best practices when planning a consumer account migration:
- If you use an external IdP, make sure that you configure user account provisioning and single sign-on in a way that does not impede consumer account migration.
Inform affected users ahead of a migration. Migrating consumer accounts to managed accounts requires users' consent and might also affect them personally if they have used accounts for private purposes. Therefore, it's crucial that you inform affected users about your migration plans.
Convey the following information to users before starting the migration:
- Rationale and importance of the account migration
- Impact on personal data associated with existing accounts
- Timeframe in which users can expect to receive a transfer request.
- Time window in which you expect users to either approve or decline a transfer
- Upcoming changes to the sign-in process after migration (only applies when using federation)
- Instructions on how to transfer ownership of private Google Docs files to a personal account
If you announce the migration by email, some users might assume it's a phishing attempt. To prevent this from happening, consider announcing the migration through a different medium as well.
For an example of an announcement email, see Advance communication for user account migration.
Initiate transfers in batches. Begin with a small batch of approximately 10 users, and grow your batch size as you go.
Allow sufficient time for affected users to react to transfer requests. Keep in mind that some employees might be on vacation or parental leave and won't be able to react quickly.
Make sure that by consenting to a transfer, users don't lose access to data or Google services that they need.
What's next
- Review how you can assess existing user accounts.
- Learn how to evict unwanted consumer accounts.