Google Workspace to Google Workspace Migration Watchpoints

 

Cutover Impacts and Considerations

As an email domain cannot exist in more than one Google Workspace instance, in situations such as a divestiture where migrating email domains are still in use in the source Google Workspace instance, the target Google Workspace instance will need to have a temporary primary domain name up until the cutover / go live. 

There are several considerations and watchpoints which should be observed:

• At cutover, all use of the migrating email domains must be removed in the source Google Workspace instance to to allow transfer of the required domains to the new Google Workspace instance. Users, groups will need to be renamed with a different email domain, relevant aliases removed and shared domain contacts renamed or deleted.

• All users and groups in the target domain will require a temporary email address until cutover, users will then be renamed at cutover. See impacts of renaming users.

• CFM’s and Chrome licences and devices cannot exist in the target domain until after it is renamed. Licences and devices will need to be provisioned after the primary domain is renamed.

• Renaming the primary domain is not available if Chrome licenses or devices are present and will need to work with Google Support to facilitate removal of Chrome licenses temporarily.

• Settings will need to be updated for Billing, Marketplace and Google App Engine apps, Domain aliases, Google Calendar, Logos and custom URLs

• Changes may take some time to be seen in your Apps (eg GCP organization display name ~48hrs)

• Apps from Marketplace or Google App Engine may need to be reinstalled at or after golive

• There are additional impacts if the primary domain is being removed from the source instance (See also https://support.google.com/a/answer/7009324?hl=en)

 

General

Google Username

In the majority of cases users will receive the same username again (depending on project), or the same username @newdomain.

Either way they will receive a new password as this cannot be migrated. Any 2-Step Verifications will need to be re-created on migrated accounts if existing. If SSO is being used, this should be evaluated.

Action:  Admins to review authentication and identity process and provide necessary comms on changes.

 

Gmail Personal Settings

Settings within Gmail will not be migrated across such as:

• Filters/rules (including forwarding on rules)
• Templates aka Canned responses, add-ons, labs
• Mailbox backgrounds
• External forwarding
• Inbox Categories
• Inbox layout

Out of Office and signatures in most cases are not accurately migrated due to complex formatting. 

Account delegations and internal forwarding will be replicated. 

Action: Users to be informed and requested to take note of current configurations. Filters/Rules can be exported and imported adjusting for any domain name changes where relevant by users.  

 

Snoozed and Confidential Emails

Snoozed emails are migrated but are no longer snoozed and will not re-appear in the users inbox.

If a user has sent a confidential email, this will migrate and appear as expected in Sent Items.

Recipients of confidential emails will have the message migrated, but can only view the subject, timestamp and sender. Google will prompt for the original user to login to be able to view the confidential email, which in most instances users will not have access to their old account.  

Migrating the original email across will not grant the user access as it is tied to Google backend ID of the user who received the message originally. 

 

Labels

Messages are migrated with associated labels created and assigned to relevant messages. If a source label contains no messages, the label will not be re-created in the new environment as there is no message attached. 

Action: Include in FAQ. 

 

Chrome Profiles

Chrome Profiles will be reset/unable to be migrated as users receive a new Google Workspace account. Users who have signed into Chrome will lose settings, extensions, bookmarks. Users will need to delink their old account from Chrome on day one, and sign into their new account. 

Action: Users can export bookmarks, and re-import after migration. Take note of settings/extensions present. 

 

Mobile 

As users receive a new account, they will need to remove their old account and add their new account to their mobile devices post migration.  

Action: Determine if documentation required, and provide relevant comms to users for Android and iOS. 

 

Impact of User Renames Post Migration

During the cutover process, users may be renamed in both source and target domains, depending on the migration situation. There are impacts to renaming users, which can be reviewed here. The majority are not relevant in the context of migration, or are covered elsewhere in this document. 

Users may see references to temporary domain names used during migration. Any temporary email addresses will be retained as aliases.

 

Contacts Migration

Depending on migration configurations and migration plan, users may receive duplicate entries of Contacts if previous aliases are mapped and forced to update to the users new primary email. 

Action: Customer / Partner to assess if impacting, and communications can advise users to use the Merge Duplicates functionality within Contacts. 

 

Suspended due to Suspicious Activity

Post Go Live, I.T administrators may find a handful (0.5-1%) of users suspended at random by Google due to suspicious activity/login. This is due to Google detecting users login locations again, and occasionally triggering Google security systems. This will typically no longer occur after the first week or two of Go Live. 

Action: Admins to monitor and unsuspend accounts when notified. 

 

Google Vault

The Google Vault export process extracts the labels Google stores against each item.  In some circumstances these labels may not correspond to what is visible in the Google UI.

• Custom labels will be in lowercase, with spaces converted to hyphens
• The export will also contain Internal/System Google labels

Google Vault matters and retention policies are not migrated and will need to be recreated.

If migrating Google Vault deleted items to users Gmail mailbox, a number of system and historical labels may appear. It is therefore recommended that messages are migrated into a predefined label. 

Action: Determine on predefined migration label for deleted items

 

Google Drive

Deleted Items

Deleted files and folders are not migrated and users should restore items from Bin prior to migration if required.

4.2 Google Drive HyperLinks

As users' Google Drive documents are migrated, the documents receive a new Google ID/URL in the new destination. Any existing hyperlinks within documents linking to other Google documents will no longer point to the correct document.

Action: Put the document name next to the hyperlink, so users know which document is being referenced, instead of “Click Here”. 

Record document mappings and deploy lookup mechanism for users to find migrated file

 

Shortcuts

Drive shortcuts such as “Shared with Me”, “Recent”, “Starred” will be skewed as migration performs sharing and accessing of documents. The starred attribute on files and folders is not able to be migrated.

The ‘Shared with Me’ and ‘Recent’ shortcuts can continue to be used in the new destination as the user uses Google Drive. 

The newer Drive Shortcuts, creating a folder link to another folder will be migrated if the user is migrating, and the destination folder is also migrating to the destination. Shortcuts that point to a folder within a Shared Drive or a folder externally owned will not be migrated. 

Action: Users to be informed and note any starring Drive contents prior to migration. 

 

Comments & Revision History

Anchored comments within Google Docs can migrate if desired, however there are several caveats (e.g. disabling comment email notifications is not supported and email notifications will be sent in several cases). Suggestions/assignments are not able to be migrated. Comments within Google Sheets, Slides, Drawings cannot be migrated. 

Previous revision history of files will not be migrated, not allowing rollback of file versions. 

If Required: Performing Google Takeout of a Google Drive, will retain the Comments in a separate TXT file. 

 

Externally Owned Files/Folders

Users will lose access to Google Drive documents, that are owned by external parties, that have been shared with your users. Users will not be able to search within their Drive for these files post migration. 

Action: Users will have to record the File/Folder URL, and request access after the migration. Post migration, users can request access again by the sharing notification in their mailbox. 

Users can download and re-upload important documents, or make a copy which they will own which will be migrated. 

Inform potential Partners who may perform a high number of sharing with your organisation. 

 

Externally shared files/non migrating users

During premigrations of data permissions are replicated, so users who are external or not migrating will have the files/folders shared back to them. If a Drive search is performed they may see duplicates (i.e original and the new copy in the new domain). 

They will not be placed in the same folder structure in the source domain, but back in the source domain users ‘Shared with me’. 

If files are required to live in a particular folder hierarchy existing in the source domain, these will have to be manually moved. 

Actions: User comms or choose to perform migration without replicating any external sharing permissions outside of the new domain

Doc / Drive Add-ons

Any Doc or Google Drive Add-ons in use will not be migrated and have to be re-installed by the end users if integrated into specific documents. 

Actions: Advise users to take note of any important add-ons.

 

Google Forms

Google forms are stored in Google Drive and migrated. There are some watchpoints to consider. 

• If the Google Form has responses stored within the form itself (not linked to a Google Sheet), the form and responses will be migrated.
• If the Google Form is linked to a Google Sheet for responses, the Google Sheet will be migrated if the owner is targeted for migration. The Google Form will still be linked to the original Google Sheet, and will need to be updated to point to the migrated response sheet. 
• Actions: Advise users to relink forms post migration
• Any Google Sites, Intranets, Websites redirecting users to a Google Form should be updated to point to the new migrated form url post migration. 
• Actions: Perform analysis and advise users to relink forms post migration to the new url.  
• If Forms are publicly accessible, viewable to anyone, permissions should be updated at cutover weekend to restrict access. This will stop users from continuing to access the form with responses going to the source location. 

 

Google Sheet Macros

Macros within a Google Sheet are migrated across with the Google Sheet. Users will need to re-authorise the oAuth token to grant access again to their new account. 

The oAuth report can be generated, filtered to show the number of macros authorised if desired. 

Actions: Advise users via comms if required. 

 

Drive Template Gallery

Templates in the Template Gallery are not migrated and will need to be manually re-created. Files that are stored in end users Drives/Shared Drives will be migrated, to enable re-creation of the template gallery. 

Actions: Assign to relevant team to recreate if required

 

Drive Size and Sharing Models

With the rise of unlimited storage on Google Drive, users Google Drives can become very large, complex and interlinked with other users data and folder structures. The number of folders a user owns, files, and permissions on those folders or files impact migration timelines. 

Any large internal directories may be best to move to a Shared Drive prior to migrations to ensure a smoother and quicker migration of the directory. 

Actions: Determine if any large folder structures are present within the domain

• Perform analysis of users MyDrive
• Determine file counts of popular MyDrive folders
• Migrate MyDrive folder to Shared Drive if possible. 

 

Drive Orphaned Files

Unknown to users, they may be owners of orphaned files, hidden in their Google Drive, where they have lost access to the parent folder. 

Orphaned files will be migrated to ensure all users files are migrated. They will appear in owners MyDrive and will need to be tidied up post migration.

Drive File Stream

Users will need to log back into Drive File Stream with their new accounts. 

Action: Inform end users

 

Shared (Team) Drives

Link Sharing

Any files with ‘link sharing’ enabled will have ‘link sharing’ enabled automatically in the destination domain but have a ‘new’ link. 

Action: Users to be aware files receive a new link

Full/Owner Access

Users who are not migrating into the destination domain (non migrating users, external parties) who have been granted Full/Owner Shared Drive permissions will not be replicated due to Google API and software limitations. 

Migrating users with Full/Owner access will be granted the same access in the destination domain. 

Action: Share Drive access to relevant external users that require Full/Owner access post migration. 

 

Edit/View/Comment permissions

These will be replicated as part of the migration into the destination drive, either on the root or file level. 

Any user with edit/view/comment permissions, whether migrating, not migrating or external, will have permission copied across.

Other Notes

• Shared Drive activity feed will be skewed due to migration due actions being recorded.
• Shared Drive themes will need to be manually replicated

 

Drive Shortcuts

Drive shortcuts in Shared Drives will only be migrated if they point to folders within the same Shared Drive. 

Shortcuts will not be migrated if they point to a folder into another Shared Drive, folder within a user's My Drive, or a folder owned externally.

 

Shared Drive Permissions (Visual)

Depending on migration configurations and aspects, if users are undergoing a rename of user identities in the target domain at cutover, their previous email address will be visible in Shared Drives. This will not be updated until the old alias is removed. As a work around, admins can temporarily remove and re-add aliases which should resolve this issue. 

 

Calendar

Calendar Events Migration

Events owned by the migrating user will migrate across and re-shared out to original participants, with participants' email address being updated automatically if they are also migrating. 

If the event is owned by a non-migrating user (ie externally owned & created event), a copy will be migrated over for the user. Users will be able to see the original event details, and the organiser but no other attendees aside from the organiser and themselves. 

These events are not linked to the original event so any future changes to either the original or migrated event will not automatically update (eg if the migrated user updates the event it will only be for themselves).

The original external owner will see no changes to their calendar, with the invite showing the original source domain user. 

When the tool migrates recurring events, it will migrate them but they are de-linked when migrated (essentially migrated 1 by 1 and not all at once). The best advice for users is for the owner to delete the first occurrence of the meeting which "should" give the ability to delete all of the occurrences. Our best recommendation currently is for users to create duplicate of the recurring meeting and either attempt to delete the first occurrence (thus giving them the option to delete the other occurrences). Unfortunately, due to the de-linked of the events, any modifications made to single occurrences are not then linked to all other occurrences. Hopefully the explanation is understandable. Again, these are the limitations of the API and not the tool itself. 

 

Calendar events that get migrated from the source that exist in an attendee’s  destination calendar get unlinked. There cannot exist 2 events with the same calendarEventID. 

 

Action: Provide relevant comms as required. 

 

Recurring Events

Customizations/changes to single instances of a recurring Google event are not migrated. The following if modified, are not migrated:

• Event Title
• Event Description
• Change of event length
• Adding/Removing of attendees
• Event reminder time

If the event is moved forward of its original time/date it will be migrated (keeping original details). If the event is moved into the past of the original event it will not be migrated at all.

Action: Provide relevant comms as required.

Meeting Room Bookings

It is recommended to migrate Meeting room bookings, like for like. If meeting room bookings are not migrated, the user events will still show the original room booking. Hovering over the room booking will show the meeting room URL pointing to the original domain. 

Action: Provide relevant comms for users to update room bookings post migration if required or migrate room bookings to new Google Calendar resources during the migration process. 

Map non migrating meeting rooms to a generic account ‘Room Not Booked’ so users are aware they need to rebook their meeting. Users will need to remove the new “Room Not Booked” attendee, and the original meeting room will still be present within the location field.
 

Meeting Room Video Links

If the option to migrate video links is enabled, it will add the original video link into the meeting description of the migrated calendar. This link should be used for divestitures, if a migrating user needs to attend a meeting hosted by the original domain. As they are joining from another domain, they will need to be admitted/accepted by someone of the original domain. 

A new hangout video link will need to be generated by the owner/host of a migrated event by modifying an event and selecting  ‘Add Conferencing’ to it. The original link should be deleted from the event description if chosen to be migrated.

If all users are migrating, the original link should not be migrated as it will be linked to the original domain. This is applicable for both Hangouts and Hangouts Meet. 

Action:  Decide if video links need to be migrated, or start a green field, advising users to re-create necessary video links where applicable, dependent on domain settings.

Reminders & Secondary Calendars

Users who have created non-admin secondary calendars on their account have these migrated. Calendar Reminders are not migrated.

Look to migrate calendars of Former Employees as well so secondary calendars are migrated.  

Action: Comms for end users

 

Calendar Event Forwarding during Cutover

In a divestiture, where mail is being forwarded from the original domain to the new domain account, calendar events will be forwarded as well. 

As calendar events are forwarded, this essentially is a copy of the event and the migrated user will only have the option to ‘Add to Calendar’ to save a copy to their new calendar. They will be the owner/organizer and not be able to see other attendees etc. As the event is not linked to the original, any additional updates/changes will be added as another calendar and users will have to manually remove the previous copy. 

Action: Provide relevant comms as required and advise contacts of users new email addresses as soon as possible to minimize disruption. 

 

Calendar Notifications & Reminders

Depending how long source users stay active and have calendar enabled post cutover, users source accounts will generate calendar notifications and reminders for events, and forward them to the new account if forwarding is enabled from the source to destination. 

Users will be under the impression they are receiving two email notifications for their events.

Action: Provide relevant comms as required, remove calendar access in the source as soon as possible, or execute a script to remove the source calendar reminder and notification settings. The script will not remove any custom event override notifications.

Calendar API Quota

It is recommended to only migrate 2-3 years of historical calendar events. If all historical calendar events are migrated, and depending on the number of users, Calendar API limits can be breached, halting calendar migrations during cutover weekend. 

 

Action: Confirm if 2-3 years of calendars is sufficient, inform users, and keep a watchful eye on migrations.

 

Google Sites

CloudM does not recommend the migration of Google Sites where possible. Due to the complex nature and integration of different components in Sites, they are typically unable to be migrated cleanly without issues. 

Many classic sites have different widgets, custom gadgets, drive and calendar integrations.
There is no automatic migration path for the new Google Sites format stored in Google Drive as of July 2018.

We recommend users or Admins perform the following steps in order to migrate Classic and New Sites: 

Action:
1. Share the Classic Site to the new designated owner (i.e their new Google account). 

2. User receives early access to their new Google account and views the Google site. 
3. With their new account, the user can then create a copy of the Classic Site into the new domain.
4. User makes corrections to any inconsistencies on the copied site and share it out to relevant users ready for Go Live
   
   

Some watchpoints to note:

• Integrations with Google Drive would require updating, as drive file URLs change during the migration. 
• Integrations with Google calendar would require updating as user accounts change and any other integrations where permissioning would be impacted. 
• Site URLs would change to the new domain
• Sites would require to be 're-published' if required and re-shared.
• Any quick links or external DNS would require to be updated etc to point to the new site. 
• When you delete a secondary domain, all sites created on the domain are also deleted.

 

3rd Party Applications & Additional Services

Marketplace Apps

3rd Party Marketplace Apps installed on the domain are not automatically migrated. If required, they need to be manually installed on the new domain, configured, user permissions re-granted or any data exported and re-import depending on the application,service and integrations. 

 

oAuth Access to External Applications

Users who have used their Google Account to sign into Web Applications will lose their 3rd party account and link. Their authorisation and account ID will change as they are migrated to a new account.

Example applications are LucidCharts, Google Wallet, JIRA, Trello, Smartsheet, PokemonGo etc.
If users are receiving the same email post migration, some applications may relink automatically depending if they are coded to the primary email address or the backend account ID. 

Action: Admin and users to review what applications are being used, and users manually export or save offline any required data. 

 

Google Analytics / 360

Access to Google Analytics instances is managed within Google Analytics service. 

If Analytics is in use, the Analytics owners/managers should share access to their new accounts prior to account deletion and renaming, to avoid being locked out. The new accounts should be granted the same permissions as existing to avoid loss of access and loss of data.. 

Analytics User Permissions Guide: https://support.google.com/analytics/answer/1009702?hl=en

Action:  Ensure someone on the new domain has full access to the Analytics account to avoid losing full administration rights to the Analytics instance.

 

Google Ads (Adwords)

Google Ads accounts will have to be shared out to their new accounts prior to migration as per Google Analytics. 

Google Ads (Adwords) User Permissions Guide: https://support.google.com/adwords/answer/6372672?co=ADWORDS.IsAWNCustomer%3Dfalse&hl=en

Action:  Ensure someone on the new domain has full access to the Adwords account.

Ad Manager (DoubleClick)

Ad Manager (formerly DoubleClick) accounts will have to be shared out to their new accounts prior to migration as per Google Analytics and Google Ads. 

Ad Manager permissions guide: https://support.google.com/dfp_premium/answer/3059181?hl=en

Action:  ensure someone on the new domain has full access to the Ad Manager account.

 

GCP/API Projects

GCP Project migration requires further evaluation of services, structure, permissions/access etc prior to migration and working with Google Support to migrate GCP Projects over to a new organisation.

• For most GCP project migrations, there will be no down time but depending on services being utilized this should be assessed further (VPCs, oAuths). 

Actions: 

• Plan migration well in advance.
• Ensure integration points are investigated and tested prior to cutover. 
• After migration, check all services / API’s, check & update any integrated systems if (eg websites) if relevant, update billing details
• Migrate and update billing account users and billing account holder

See guide and watchpoints outlined for planning and performing GCP project migration here.

 

AppMaker

Although Appmaker application files are stored within Google Drive, these currently are not able to be migrated automatically through migration tools or via API. AppMaker typically includes integrations into Google Sheets, GCP CloudSQL and other products. 

Appmaker applications can no longer be created due to Google discontinuing the product. 

Action: Handle on case by case basis depending on complexity. Ensure application is replicated and working in a new suitable environment i.e AppSheet.

 

Datastudio

Datastudio files will require updating. Although Datastudio reports are located in Drive they are not  migrated, data sources may remain in the source domain or other applications and reports will often break after migration/cutover. Reports, data sources and data source connections may therefore require updating.

Behaviour will vary as data sources have multiple connection types and may point to migrating files in Drive or non-migrating internal (eg GCP) or external data sources. It is also possible some linked data sources may be owned by a non-migrating user and may not migrate. Note it may not be possible to directly transfer ownership of reports or data sources outside of the source domain due to sharing policies.

Action:

1. Identify any Datastudio reports in use and any linked data sources. 
2. Manually reshare reports and datasource connections to new report owners in the new domain prior to cutover - the new owner can make copies of both the report and datasource and update the copied report to point to the copied datasource. 
3. Evaluate data sources to see if these are migrated or not, and if any further action required. 

Note you will need to use Datastudio to perform any copying, renaming or sharing actions, this cannot be done in Drive.

Users can locate Datastudio reports: https://datastudio.google.com/navigation/reporting User can view datasources: https://datastudio.google.com/navigation/datasources

Alternatively these can be retrieved for the domain via GAM.

Google Keep

Google Keep notes are not migrated across. Google Tasks are.  

Action: Advise users to either:

A. Use the Google Keep option to copy to Google Drive, which creates the note as a Google Doc. 

1. Use Google Takeout service for users to export Google Keep notes as HTML for referencing.

 

Google+ / Currents

Google+ and/or Currents communities, circles and posts are not able to be migrated. There is an option for end users to export their own data using Google TakeOut as HTML files. No import method is possible.
 

Action: Advise users on manual methods or start new again.

Hangout Chat

Classic Hangout Chats and new Hangout Chats or Chat Rooms are not migrated. However, if chat history is on, Hangout Chat messages are stored within Gmail and are migrated as emails. 

 

Youtube Channels / Videos

YouTube videos/channels can either be associated with an end-user and self managed by the end user. They can also be managed by a named  Youtube ‘Brand’ Account which enables the management of the Youtube Brand/Channel videos by multiple users. 

 

Action: Assess Youtube usage and whether videos are associated with an end-user or a Youtube Brand Account. Individual YouTube Accounts should be converted to Brand Accounts to enable transferring of primary ownership across accounts and domains. 

Managing Permissions on Brand Accounts

• If Youtube Premium is in use, this can be investigated further.
  
  

Watchpoint: The primary owners must grant Owner access to their new account prior to cutover. They then must wait 24hrs before prior to increasing their new account to ‘Primary Owner’ 

 

Google Play Store, Other Services

Ensure that the services which users access are shared to their new accounts prior to cutover.

Action: If you are using an Enterprise Developer Play Store to push custom applications to users, ensure access as been granted to new accounts before restricting access to old accounts. 

 

Google Photos

Photos stored in Google Photos cannot be automatically migrated. Users will be required to self migrate/export using Google Takeout, or add photos to an album and download album.

AppScript

Any AppScripts embedded into a Google sheet will be migrated with the Google Sheet. If it is a standalone app script, these are stored in Google Drive and also migrated. 

The auto system GCP projects associated with AppScripts do not need to be migrated via a GCP migration, as they will be recreated when the AppScripts are re-authorised.

 

Post migration any AppScripts will need the following to occur

• Need to be reauthorized in the new user account / domain before they are executed. 
• Any script's that have file ID's, email addresses and other script IDs may need to be reviewed and updated to function again. 
• Any scheduled tasks or actions triggered with the scripts will need to be reestablished and checked

Action: Include in user FAQs

 

Google Groups

Google Groups can be used for different functionality from simple email distribution lists & security groups, discussion groups, Q+A forums and Collaborative Inboxes (see below). Each of these group types have a different set of Group settings to provide the functionality.

 

Watchpoints:

• Not all group settings can be extracted and then reimported.
• Examples of settings which cannot be exported or migrated:
  Email options settings - subject prefix, email footer options (how to post, unsubscribe etc), auto replies options. 

Moderation permissions settings - approve members, approve posts, ban members, hide abuse, lock topics, move topics in, move topics out, sticky topics.

• If using a legacy decommissioned Group setting where nested Groups have been granted ownership rights, this cannot be replicated.

Analysis:

• Organisations will need to perform an inventory of their groups to understand usage/functionality.
• Simple email distribution lists and security groups, created by GCDS, can have their settings easily exported and imported via the Admin API.
• Discussion Groups, Q+A forums or groups that have settings changed via the UI will need to have settings manually re-created via the web UI. 

 

Collaborative Inboxes

These are messages stored within a Google Group and are not a regular user or shared mailbox. There is no direct migration path currently present, so data requires to be exported from Google Vault as mbox or PST, and then migrated into a new Google Group in the new domain.

Watchpoints:

• Read/unread status of messages will not be migrated. All messages will be marked as unread.
• Message tags/labels will not be migrated
• Determine if deleted messages should be included or not.

Analysis:

There is no easy way to determine if a Group is used as a Collaborative Inbox as an Admin or via API. Organisations will have to check with Group owners, confirm if messages are present and updated via the Group UI, and not functioning as a traditional distribution list. 

 

Former Employees

Past employees are typically kept licensed for retention purposes, typically suspended and with Google Workspace services disabled. 

Depending on termination/offboarding policies, files owned by former employees will most likely be shared with and used by active employees. Suspension and disabling of services of file owners accounts does not prevent other users being able to access their shared Google Drive files.

Migration of data requires former employees to be reactivated - ie unsuspended and unarchived with Google Workspace services enabled (Gmail, Calendar, Drive) and then target mail and drive migrations from Gmail and Google Drive interface/APIs. Vault can be targeted to migrate deleted email items if required. 

 

Watchpoints:

• Google Workspace license buffer to allow re-activation depending on license SKU
• Accounts require to be unsuspended and unarchived with services enabled for migration of data
• Bouncebacks no longer received if emailed
• Reset passwords to restrict access (if not done during the offboarding process)
• Exclude Google Workspace accounts from any Google Cloud Directory Sync or similar tools etc to prevent suspensions (if relevant)
• Assuming former employees may own Google Drive  files which are shared and still in use: 
• Former employees will need to be included in cutover delta migrations, in order for most recent changes to active files to be updated (ie Former employees Google Drive should be migrated in parallel with active employees)
• Efforts should be taken to identify former employees who are owners of actively used files, particularly those which may own larger numbers of files.

 

Appendix A - Google Drive Decommissioning

Overview

Google Drive is not a traditional  file system and can have elaborate folder structures, typically owned across numerous individuals, with complex file and folder sharing. 

When folder structures and folder contents are both owned by migrating and non migrating users, care needs to be taken to ensure minimal disruption for users staying in the source domain. 

It is important to note that: 

• The migration process creates new copies of files in the target domain - the originals are left in the source domain with previous sharing settings enabled. 
• Suspension of migrated accounts in the source domain post go-live will not prevent other users (internal or external) from continuing to access the original files owned by those users.
• As migration of data requires accounts to be active, users with a large number of files may potentially require accounts in the source domain to be active for a short period of time after cutover/golive in order to complete their migration. 

When performing a Google Workspace to Google Workspace divestiture migration a number of points need to be taken into consideration post migration. This section outlines the post migration Drive options for tidying up accounts in the source domain and the points to consider.  There are primarily two approaches that can be taken to achieve this.

 

Option 1: Deletion of User Accounts (with No Drive Transfers)

In the majority of cases, administrators will delete the user accounts in the source domain after the user’s data has been migrated to a new Google Workspace domain. While a simple approach, it can create orphaned files for users in the source domain if parts of the folder structure are owned by the migrating users. 

 

Orphan Files

If an item in Drive loses its parent folder, it becomes an orphan. The item still exists and is owned by the user but it is now harder to find. 

Here are some ways a file can become an orphan:

• You create a file in someone else's folder, and then that folder is deleted. Your file isn't deleted along with the folder because no one else can delete your file, but it no longer has a ‘home’.
  
  
• You share a folder with someone, who then deletes one of your files from the folder. The file isn't actually deleted because no one else can delete your file, but it's no longer in the folder.

Scenario:

User A is an owner of a folder and migrating away, and User A’s folder contains folders or files that are owned by User B, who is not migrating. 

When User A is deleted post migration, the files and folders of User B are orphaned as outlined above. They are no longer in the expected folder structure and have to essentially be recovered. 

On a larger scale, with complex multi-level folder structures, owned by a mix of migrating and non migrating this can cause large unexpected issues to users folder structures post deletion. 

 

Recover Orphan Files & Folders

Each user in the source domain will be required to perform a search query within their Google Drive:

is:unorganized owner:me

This will display a list of orphaned files and folders that the user can either drag and drop into a folder in My Drive, or move to a relevant Drive folder location. The search query needs to match the spelling as above.

While the option of deleting the users from the source domain with no drive transfers is the simplest option from an administrator's point of view, it can take some effort for each user to recover orphaned files. This can be managed through good change management communications before and after users are deleted to ensure they are aware of the Drive search query. 

 

Option 2: Deletion of User Accounts with Drive Transfer

Prior to the deletion of users from the source domain, administrators have the option of transferring ownership to another user or central holding archive account. This can be done manually, one by one, via the Admin console, or in bulk via an API script. 

Doing so allows administrators to mitigate the above risk of orphan files and folders as the folder structures and files are not deleted. 

 

Duplicate Files

However, this method runs the risk of duplicate files appearing within the source domain. This is due to the fact that the migrated users files and folders in the new domain are shared back into the source domain to those users who are not migrating (if this option was selected). 

 

Scenario:

User A is a owner of a file and migrating away. User A’s file is shared to both users that are not migrating (User B) and those that are migrating. 

User A’s file is copied to the new domain and then shared out again to the same collaborators as previously, i.e with users that have migrated and users who have stayed in the source domain (User B).

When User B performs a Drive search for said file, they will find two copies. One owned by the central holding account in the source domain, and one owned by User A in the new domain. 

Again, change management communications should be used to inform non migrating users to check and ensure they update the correct copy of the file i.e. the one now owned by the migrating user in the new domain. 

 

Removing Duplicate Files

If the duplicate files are to be removed, there are the following options: 

Option 1: Manual

Users can delete the duplicate files that they come across, which will hide it from their view, but still keep ownership within the central holding account, essentially orphaning it (See above bullet point #2 Orphaned Files).

An administrator can carefully go through the central holding account deleting only files, keeping folders present, so existing folder structure is not disrupted. This is a manual and time consuming task. 

Option 2: Bulk Script Deletion

Administrator’s print a file list of the central holding account via API. From the list, files are separated from folders. A script is run against files only to deleted that are within the central holding account (eg the migrated users). 

Option 3: Prefix migrated users files with “Do not use - Migrated”

Once the migrated users drive contents ownership have been shifted to a central holding account the file list can be exported via API. 

Once received, files can be separated from folders and the file names prefixed with “Do Not Use - Migrated” via bulk script API changes. 

This will highlight to the users on the source domain that this file has been migrated over to the new domain, but allow them to still view/edit it for referencing. 

At some point in the future it is envisioned the files most likely will be deleted either by users or administrators to clean up the environment. 

 

Appendix B - Shared Drive Decommissioning

As per Drive migration, the migration process creates new copies of files in the target domain, and originals are left in the source domain.

There are two options available for Shared Drive decommissioning post migration:

Option A: Delete Shared Drive data and delete the entire Shared Drive. 

• All contents no longer required
• Cannot be recovered. 

Option B: Remove users from Shared Drive access, keep data & Shared Drive in an ‘archive’ state

• All contents available to administrators
• Data can be recovered later if required

 

Appendix C - Early Removal of Former Employees prior to cutover

In some cases, a business may wish to migrate and remove Former Employees accounts early, eg due to licensing renewals and constraints.

Transfer of ownership of former employees Drive files to existing active user accounts (i.e manager or colleague) may be considered for the purpose of Drive migration. Dedicated user ‘holding’ accounts could be created and former employees Drive content could be transferred to these accounts, in order to keep folder structures and files available to active users and allow migration as per above. 

In this scenario, the holding accounts will contain a severe amount of files, causing the Drive migration for the few service accounts to take an extended time to complete both pre-migration and delta migration on the cutover weekend - this has several risks/impacts noted below.

Watchpoints:

• Files will no longer be owned by the original owner or stored in Vault under the original owner if required for compliance purposes. They will be held by the nominated holding account.  
• Licensing SKUs for holding accounts will likely require Google Workspace Enterprise
• Due to the time it will take for the delta migration to complete at cutover, there is a high risk of lost data from active users working on files which have not yet completed their migration at golive (recent changes to files owned by the holding accounts are more likely to not be updated during the cutover delta migrations in time for users golive, due to the high number of files owned by the single holding account. This will give users the illusion of missing data and result in recent changes being lost if files are updated by end users prior to the migration completing)
• Migration/project timelines could stretch due to the extended time needed to migrate the holding accounts.

 

Recommendations

CloudM recommends as a least risk approach that when users are actively accessing data of Former Employees, these accounts are not consolidated and are migrated as individual accounts. 

If consolidation is required, steps must be taken to identify any departed owners of critical shared files and users with a large amount of Drive data whose files may be actively used, and to not consolidate these accounts, so their files have the best chance of recent changes being updated in a timely manner during cutover.