This article is the first part of a multi-part series that discusses how you can migrate consumer accounts to Cloud Identity or G Suite. An account is considered a consumer account as long as the domain of the email address it uses has not been registered in G Suite or Cloud Identity.
The series consists of these parts:
- Migrating consumer accounts to Cloud Identity or G Suite (this article)
- Migrating consumer accounts to Cloud Identity or G Suite: Best practices for setting up federation
Many of Google's services such as Google Ad Manager, AdSense, or Analytics require you to sign in using a Google Account. If you are a G Suite or Cloud Identity customer, then employees can use accounts managed using G Suite or Cloud Identity to use these services.
If you haven't been using G Suite or Cloud Identity, it's possible that your organization's employees have been using consumer accounts to access these services. Letting employees use consumer accounts for business purposes can be risky because your company doesn't control the accounts, their lifecycle, and how secure they are:
- It might be difficult to keep track of which employee uses which account, and how many accounts are in use.
- It's not possible to use your existing identity provider and single sign-on (SSO) to handle authentication for consumer accounts used by your organization's employees.
- You can't enforce password policies or multi-factor authentication.
- After leaving the company, an employee might be able to access data that was created while they were still an employee, or they might be able to use services at the company's expense.
- You might not be able to access, transfer, or recover business-relevant data from a consumer account after the employee has left the company.
To avoid risks associated with using consumer accounts for business purposes, you can migrate consumer accounts to G Suite or Cloud Identity, provided that the accounts have been registered with a corporate email address.
Migration to managed accounts
Accounts that are managed by either G Suite or Cloud Identity are referred to as managed accounts. Managed accounts offer a number of advantages, including:
- You can use an external identity provider (IdP) for single sign-on, enforce password policies, or use multi-factor authentication.
- You can ensure that the account is disabled and access is revoked when an employee leaves the company.
- You gain transparency over the set of accounts used by your organization's employees.
Migrating a consumer account to a managed account requires that the consumer
account use an email address with a custom domain and that you own this domain.
If you own
example.com, you can migrate any consumer account registered with
an email address
@example.com. In contrast, you cannot migrate a
account, even if it was created by one of your organization's employees.
Converting a consumer account to a managed account implies that the user who registered the consumer account passes control of the account and associated data to your organization. Your organization might require employees to sign and adhere to an acceptable-email-use policy that disallows the usage 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 an acceptable-email-use 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—instead, you must have the user's consent.
Consumer accounts have certain privileges that Cloud Identity accounts lack—this includes being able to use Google Docs free of charge. When the consumer account is converted to a managed account, this privilege is lost unless the user is assigned a G Suite license.
Migrating consumer accounts to managed accounts is a multi-step process that you must plan carefully. The following sections walk you through this process.
Migration process overview
The goal of migrating is to convert a consumer account into a managed 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 illustrated by the following state machine diagram:
An account is considered a consumer account as long as the domain of the email address it uses has not been registered in G Suite or Cloud Identity.
When you add and verify a domain in G Suite or Cloud Identity, any 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 G Suite or Cloud Identity only
affects users whose email address matches this exact domain. For example, if you
example.com, the account
firstname.lastname@example.org is identified as an
unmanaged account, while
email@example.com is not unless you
corp.example.com to the G Suite or
Cloud Identity account.
The existence of unmanaged accounts is surfaced to you as the G Suite or Cloud Identity administrator. You can then ask the user to transfer their account into a managed account.
If the user consents to a transfer, an unmanaged account is converted to a managed account. The identity remains the same, but now G Suite or Cloud Identity controls the account, including all of its data.
If a user doesn't consent to a data transfer, but you create an account in G Suite or Cloud Identity 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.
A user signing on by using a conflicting account will see a ballot screen, prompting them to select either the managed account or the consumer account to resume the sign-on process. Crucially, only the consumer account still has access to the original data, while only the managed account is under the control of your organization. The result reflects that the user never consented to transferring the data—however, it likely doesn't reflect the intent of your migration. To avoid ending up with conflicting accounts, it's helpful to understand account states in more detail.
Migration process in detail
The following diagram illustrates account states in more detail:
When signing up for Cloud Identity or G Suite, 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 G Suite 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 G Suite 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.
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 Sent, indicating that no transfer request has been sent.
If you select a user and send an account transfer request, the user receives email similar to the following. Meanwhile, the account switches to being listed as Request sent.
An affected user might simply ignore the request 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 log in and access their data. However, the process of migrating account data to G Suite 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 primary email address is changed to use a domain that has not been verified by any Cloud Identity or G Suite account yet, then 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.
If at any point you create an account in G Suite or Cloud Identity 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 newly created account, together with the unmanaged account, becomes a conflicting account.
Creating an account with the same email address might also happen unintentionally. After signing up for Cloud Identity or G Suite, you might decide to set up single sign-on with an external identity provider (IdP) such as Azure AD or Active Directory. When configured, the external IdP might automatically create accounts in G Suite or Cloud Identity for all users you enabled single sign-on for, inadvertently creating conflicting accounts.
If a user accepts the transfer, the account is surfaced in G Suite or Cloud Identity. The account is now considered a managed account, and all data associated with the original consumer account is transferred to the managed account.
If G Suite or Cloud Identity 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'll be sent to the sign-in page of your external IdP when attempting to sign in. For this to succeed, the external IdP has to recognize the user and permit single sign-on. Otherwise, the account becomes locked out.
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 now each have different email addresses. 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. In
this case, they'll see the same screen again the next time they sign in and the
account will be assigned a temporary
gtempaccount.com email address.
An alternative way to resolve the conflict is to delete the managed account in Cloud Identity or G Suite, 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, then the account becomes an unmanaged account again.
Planning a migration
If you intend to migrate existing consumer accounts to either Cloud Identity or G Suite, plan and coordinate the migration steps in advance. Good planning avoids disrupting your users and minimizes the risk of inadvertently creating conflicting accounts.
Communicating migration plans
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.
Process for migrating without federation
The best way to approach a migration depends on whether you plan to federate Cloud Identity or G Suite with an external IdP such as Azure AD or Active Directory.
If you don't plan to federate Cloud Identity or G Suite with an external IdP, you can follow the process outlined in the following diagram:
- Sign up for Cloud Identity or G Suite and verify the domains you plan to use. If you use G Suite, don't change the DNS MX records yet, because it might cause the users of unmanaged accounts to not be able to receive email anymore.
- Identify unmanaged user accounts using the transfer tool for unmanaged users.
- Create accounts for users that don't already have an unmanaged user account.
- Select unmanaged user accounts to transfer. If you're dealing with a large number of unmanaged accounts, it might be best to do the migration in batches.
- Communicate your intent to transfer accounts to affected users and make sure that users understand both the importance and consequence of accepting or declining a transfer request.
- Send transfer requests using the transfer tool for unmanaged users.
- Wait for users to accept or decline transfer requests (quorum) and resend transfer requests as necessary. You can observe the status in the transfer tool for unmanaged users.
- When all account transfers have been completed, you might want to change the DNS MX records in case you use G Suite.
Challenges of migrating with federation
If you do plan to federate Cloud Identity or G Suite with an external IdP, you need to take other factors into account before settling on a migration plan.
Federating Cloud Identity or G Suite with an external IdP generally involves two pieces:
Provisioning accounts: Relevant user accounts and groups are synchronized periodically from the external IdP to Cloud Identity or G Suite. This process ensures that when you create a new account in your IdP, it's also made available in Google Cloud so that it can be referenced in Google Cloud even before the user has logged in for the first time. This process also ensures that account removals are being propagated.
Single sign-on: Whenever a user needs to authenticate in Google Cloud or any other Google service, authentication is delegated to the external IdP by using the Security Assertion Markup Language (SAML) protocol.
In the absence of unmanaged accounts, provisioning accounts works one-way. After setting up federation, the external IdP initially provisions accounts for all relevant users and then continuously propagates account creation, updates, and deletions to Cloud Identity or G Suite as they occur. Similarly, the external IdP might enable single sign-on for any account provisioned to Cloud Identity or G Suite, but disable single sign-on for all other accounts. As the following diagram suggests, you are only dealing with two sets of accounts:
- Accounts in external IdP is the set of all valid accounts in your external IdP.
- Accounts relevant for Google is the subset of accounts in your external IdP that should have access to Google services and that are being provisioned for Cloud Identity or G Suite and are also allowed to use single sign-on.
When migrating existing accounts, you must consider other sets of accounts:
- Existing Google accounts is the set of all Google accounts created by employees of your organization.
- Consumer accounts is the subset of Google accounts created by your
organization that use domains you have not verified in
Cloud Identity or G Suite, including
- Migrated accounts is the subset of Google accounts that have been successfully migrated to a managed account.
- Unmanaged accounts is the subset of Google accounts that are pending
- Also consider unmanaged "surprise" accounts, which is the set of unmanaged accounts that don't seem to overlap with the set of accounts you consider relevant for Google.
Given these additional sets of accounts, a one-way approach of provisioning accounts to Cloud Identity or G Suite is ill-suited because it would risk tampering with migrated and unmanaged accounts.
Avoiding inadvertent creation of conflicting accounts
After an IdP is configured, the default behavior of most external IdPs is to automatically create accounts in G Suite or Cloud Identity for all accounts considered relevant for Google. This behavior would cause all unmanaged accounts to become conflicting accounts.
There are two ways you can prevent this behavior:
- Configure your external identity provider to exclude the set of unmanaged accounts from the set of accounts relevant for Google.
- Let the external IdP utilize a user for provisioning that's allowed to modify accounts in Cloud Identity or G Suite, but lacks the privilege to create new accounts.
Avoiding inadvertent deletion of migrated accounts
At certain points during a migration, there are likely going to be user accounts in Cloud Identity or G Suite that lack a counterpart in the set of accounts relevant for Google. Certain identity providers such as Azure AD ignore such accounts by default, avoiding the risk of inadvertently deleting a migrated account.
Other identity providers or tools, including Google Cloud Directory Sync default to disabling or deleting accounts that lack a counterpart. To prevent affected users from losing access to their migrated accounts, let the identity provider ignore those accounts instead.
Avoiding lockout of migrated accounts
One set of accounts not shown in the Venn diagram earlier is the set of accounts that the external IdP allows to use single sign-on. For certain IdPs such as Azure AD, this set defaults to being the same as the set of accounts that are being provisioned to Cloud Identity or Google.
If you exclude unmanaged accounts from accounts relevant for Google, and you permit single sign-on only for accounts that are being provisioned for Google, then users of unmanaged accounts won't be able to sign in after accepting a transfer request. To prevent this from happening, the set of accounts that are allowed to use single sign-on should cover all unmanaged and migrated accounts.
Reconciling unmanaged "surprise" accounts
Unmanaged "surprise" accounts can have three causes:
- Your initial notion of which accounts are relevant for Google usage might have been inaccurate. In this case, you should extend the set of accounts relevant for Google as appropriate.
- An employee who shouldn't be using Google services has signed up for an account. In this case, you can force the employee to convert the account to a consumer account by deliberately creating a conflicting account.
- The employee left the company. To prevent the former employee from continuing to use an account with a company email address, create a conflicting account to force the former employee to rename the account.
Reconciling email mismatches
Matching each migrated account with its counterpart in the external IdP works based on the primary email addresses of accounts. The primary email address is the address that the employee used originally to sign up for a consumer account and has been using since to sign in to Google services.
If employees have a unique email address, you can expect this matching to be reasonably reliable. However, some of your employees might have multiple email addresses, or your email system might allow for variations in email addresses, including:
- Using alternate domains, for example
firstname.lastname@example.org be aliases for the same mailbox, yet the user might only be known as
email@example.com your IdP.
- Using alternate handles, for example
firstname.lastname@example.org also refer to the same mailbox, yet your IdP might recognize only one spelling.
- Using different casing, where
JohnDoe@example.commight not be recognized as the same user.
If your email setup allows any of these variations, matching migrated accounts with the accounts of the external IdP might fail in some cases. You must manually adjust the primary email address of affected accounts in Cloud Identity or G Suite to reflect the format used by your IdP.
Planning a migration with federation
Migrating unmanaged accounts before federating
One way to overcome the challenges outlined in the previous section is to migrate without federation first and to only set up federation and single sign-on after all relevant user accounts have been migrated.
A key benefit of this approach is the low risk of ending up with conflicting accounts or locking out users. Nonetheless, because your plan is to eventually use an external IdP for authentication, the approach has several downsides:
You cannot enable single sign-on before all relevant users have been migrated. Depending on the number of unmanaged accounts you're dealing with and how quickly users react to your account transfer requests, this might take days or weeks.
During the migration, you have to create new user accounts in Cloud Identity or G Suite in addition to creating accounts in your external IdP. Similarly, you have to disable or delete user accounts for employees who leave in both Cloud Identity and G Suite, and in the external IdP. This redundant administration increases overall effort and can introduce inconsistencies.
Even after domain verification, users can still sign up for consumer accounts, which immediately become unmanaged accounts. You can suppress self sign-up by proactively provisioning accounts in Cloud Identity or G Suite for all your users, thereby claiming their email addresses. After you set up federation, this can be achieved automatically—but during the migration, where accounts have to be created manually, it might be impractical to achieve this.
The following table summarizes the key properties of the process:
|Before domain verification||During migration||After setting up federation|
|How to authenticate||Password||Password||SSO/External IdP|
|How to create new accounts||Consumer self-signup||Cloud Identity||External IdP|
|How to disable/delete accounts||Not possible||Cloud Identity||External IdP|
Federating before migrating unmanaged accounts
By implementing an alternative approach, you can set up single sign-on early and enable users to authenticate using an external IdP as soon as their accounts have been transferred. Enabling sign-on early has a higher risk of inadvertently creating conflicting accounts, so this approach calls for an initial dry run.
- Identify an initial domain to verify. To reduce risk, choose a domain that's unlikely to have been used by users to register consumer accounts, or choose a domain that's reserved for testing purposes.
- Register one or more consumer accounts that you will use to perform a migration dry run. Register the accounts with an email address that uses the domain identified in (1) so that they will become unmanaged accounts later. Registering accounts is possible only for valid email addresses—if you use a domain reserved for testing purposes, you might have to configure DNS MX records first. Optionally, create some data with the test accounts—for example, by uploading a photo to Google Photos.
- Sign up for Cloud Identity or G Suite and verify the domain identified in (1). If you're planning to use more than one domain, don't verify other domains yet. Also, if you use G Suite, don't change the DNS MX records yet, because this might cause the users of unmanaged accounts to not be able to receive email anymore.
- Set up single sign-on in a way that avoids inadvertent creation of conflicting accounts, inadvertent deletion of migrated accounts, and lockout of migrated accounts.
- Create accounts in the external IdP that correspond to the test accounts you created in (2).
- Use the transfer tool for unmanaged users to send a transfer request to the test accounts you created in (2). It might take several hours before the accounts show up in the tool.
- Accept the transfer requests.
Verify that single sign-on works for all test accounts and that the accounts in Cloud Identity or G Suite have been successfully updated by the external IdP.
After you complete the dry run, you can migrate the remaining accounts.
Identify unmanaged user accounts using the transfer tool for unmanaged users. Again, it might take several hours before the accounts show up in the tool, so allow at least 12 hours before proceeding.
Optionally, selectively provision accounts in Cloud Identity or G Suite for users that you know don't have an unmanaged user account.
Select unmanaged user accounts to transfer. If you're dealing with a large number of unmanaged accounts, it might be best to do the migration in batches.
Create corresponding accounts in the external IdP, if they don't yet exist, and enable them for single sign-on.
Communicate your intent to transfer accounts to affected users and make sure that users are fully aware of both the importance and consequence of accepting or declining a transfer request.
Send transfer requests using the transfer tool for unmanaged users.
Wait for users to accept or decline transfer requests (quorum) and resend transfer requests as necessary. You can observe the status in the transfer tool for unmanaged users.
Reconcile email mismatches, if any, by renaming migrated accounts in Cloud Identity or G Suite, and notify affected users.
When all account transfers are complete, reconfigure the external IdP so that it's now allowed to provision users to Cloud Identity or G Suite. From this point on, users created in the external IdP can be automatically provisioned and enabled for single sign-on in Cloud Identity or G Suite.
If you use G Suite, it's now safe to change the DNS MX records.
The following table summarizes the key properties of the process:
|Before domain verification||During and after migration|
|How to authenticate||Password||SSO/External IdP|
|How to create new accounts||Consumer self-signup||External IdP|
|How to disable/delete accounts||Not possible||External IdP|
The process overcomes all of the downsides of migrating with deferred single sign-on, yet requires careful configuration of the external IdP in step (4).
- Lean more about best practices for setting up federation when migrating consumer accounts to Cloud Identity or G Suite.
- Find out more about the different ways to allow corporate users to authenticate in a hybrid environment.
- Find out how you can federate Google Cloud with Active Directory or Azure AD.
- Try out other Google Cloud features for yourself. Have a look at our tutorials.