Google Workspace Migration
Migrating files to a new storage platform can become a frustrating project for an organization. How does a company complete a large-scale file migration with no disruption to business or users? How can an organization plan for a major migration? Are there any unique qualities to a Google Workspace migration that makes them difficult? Is there a way to make sure all of the data was migrated into Google Workspace?
Before we begin on this educational journey, please note that unless explicitly stated, this generically refers to both Google MyDrives and Shared Drives as Google Workspace to keep things a little simpler. On the surface, Google Workspace may look and feel like any other online content repositories like Box, O365, Dropbox, etc. However, once you begin to dig a little deeper, you’ll quickly find that there are many unique qualities to Workspace that need careful consideration when planning your Google Workspace migration.
We’ll review these complexities, what considerations you need to make, and how DryvIQ can help address them. With DryvIQ as agnostic “middleware”– bridging platforms and moving content in any direction – we’ll address the complexities and considerations of moving content to or from Google Workspace.
A Tale of Two APIs: My Drive & Shared Drives
Google Workspace contains two distinct content repositories, MyDrive (personal content), and Shared Drives (collaborative content). These two repositories have different API sets and some unique capabilities around how they handle permissions (see below). It’s important to know that whether you are migrating to or from Google Workspace that you ensure your Google Workspace migration solution can support both repositories. DryvIQ of two distinct Connectors to support going to or from either of these locations within Workspace.
Native File Types and other Unique File Level Considerations for Google Workspace Migrations
Google is one of the cloud repositories that’s developed its own proprietary file types with its online editing suite. The three primary file types that are integral to Google Workspace migrations are Google Docs, Slides, and Sheets. DryvIQ has implemented configurable features to accommodate all of the different migration scenarios to maintain content in the desired format.
Migrating from Google Workspace to Another Platform
If you plan to migrate from Google Workspace to another cloud storage platform, then there’s a good chance that you will want the aforementioned Workspace native file types converted to their associated Microsoft Office formats. DryvIQ has a setting that will automatically perform this conversion for you. When your content lands in OneDrive for Business, Box, Dropbox, or any other content repository, you will now have usable Microsoft Office files, and your business users will be able to immediately begin leveraging their Microsoft Office software for collaboration.
Migrating to Google Workspace from Another Platform
When migrating to Google Workspace from another platform where you are using Microsoft Office for collaboration, an organization can configure DryvIQ to convert the Office files to their associated Google file types.
Google Workspace Migration from Another G Suite Tenant
The third migration scenario is a Google Workspace migration from one Google Workspace tenant to another Google Workspace tenant. Although uncommon, these types of projects occur within organizations managing mergers and acquisitions. In this scenario, the organization can configure DryvIQ to retain the Google files in their native format. Your Google Docs, Slides, and Sheets will remain as is with no conversion to the associated Office format
Other Native Google Drive File Types
Google Workspace Drive has additional native file types outside of the Docs, Sheets, and Slides. These files are Google Forms, Fusion Tables, Sites, and My Maps, and they’re not downloadable in Google Workspace. These additional native file types prevent DryvIQ from transferring them, so this is not a DryvIQ limitation. In most cases, the destination platform would not have an equivalent technology to map to.
However, DryvIQ can still help here. When DryvIQ identifies these files within Google Workspace as part of its analysis, the software will flag these items in a report with an informative error message stating “IO Violation and message: Downloading content is not supported for the file...” This way you know exactly where these files are located and can better manage your expectations with these content types. You can take a look at DryvIQ’s pre-migration analysis and flagged item reporting here.
Google Workspace Permission Complexities
Google Workspace supports very complex ownership permission structures that don’t translate well to other cloud content repositories. Many users in Workspace work with files and folders that have different permissions than the top-level folder. For example, permission levels in Workspace and OneDrive for Business seem similar; they both follow the concept of owner, editor, and reader for instance. However, both platforms differ in the way they store content. And this doesn’t just go for OneDrive for Business; organizations can apply the differences discussed below to most other cloud repositories. For these examples, we will be comparing Google’s permissions to Microsoft’s OneDrive for Business.
Google Workspace stores data in one, centralized location. Workspace uses permission levels on the drives, folders, and documents to build a dynamic interface allowing users to visualize the content as they need it. This can make for some very complex Google Workspace migration scenarios.
What Happens to Google Workspace Permissions During a Migration
For example, Brandon’s Google Workspace can have a top-level folder he owns containing a sub-folder that is owned by Mike, which stores a document owned by Dave. This folder is viewable in Brandon’s My Drive and is accessible in the Shared section for Mike and Dave (or as mentioned in point 3, can be added to Mike and Dave’s My Drive view). When Mike logs into Workspace he will see whatever he needs to see and will be able to do whatever the permissions allow him to do. This same scenario applies to Dave and Brandon.
OneDrive for Business, however, doesn’t have centralized storage but is rather user-based. Each user has a site collection to store the OneDrive files that the user owns. No matter what the permissions are on the folder or document, this user is a “super owner,” capable of overruling any permissions on his/her OneDrive for Business. Mike and Dave can still access files in this folder hierarchy, but Brandon is the super-owner of all files and folders.
With a Google Workspace migration to OneDrive, permissions set in Google Workspace on files and folders will be maintained. When migrated from Workspace to OneDrive, the three mentioned objects will “split” from one another and “stay” with the owner. So, after migrating to OneDrive, the top-level folder owned by Brandon would stay in his Files view in OneDrive with Mike’s folder and Dave’s file “splitting” from this and showing up in his Shared view. Mike would see his folder in his Files view with Brandon’s folder and Dave’s file showing in his Shared view. Dave would see his file in his Files view with Brandon and Mike’s folders showing in his Shared view.
Brandon’s “Files” View in OneDrive for Business
Brandon’s “Shared with Me” View in OneDrive for Business
Mike and Dave would also see these files/folders “split” with the documents they own in their Files view and documents they do not own showing in their Shared view.
As you can see with a Google Workspace migration, the permissions complexities when migrating from Google Workspace can get pretty confusing and you’ve got to know how they will be handled by your destination platform. The good news is that most of these complexities go away when migrating to Workspace. But there is one major exception that only applies to Google Shared Drives. Shared Drives do not support folder-level permissions to be applied to folders that sit beneath the root directory. Many other content repositories allow for folders to have different permissions applied beneath the root folder. An executed DryvIQ job identifies and reports on all permissions issues, and the software provides a few different automated methods for dealing with permissions that cannot be properly preserved.
External Shares and Links
Another consideration related to permissions, and this applies to most platforms whether going to or from Google Workspace, are external shares and links. DryvIQ can be configured to preserve permissions that have been granted to external parties as well as anonymous or “shared” links. Each platform handles these a little bit differently. Some platforms will automatically send notifications to external parties (Google Workspace) and DryvIQ doesn’t have the ability to turn that off, while other platforms (OneDrive) add external notifications to a queue for a user to send. Going into each platform and how it handles external notifications can get complicated, so please contact us if you have questions about your specific environment.
Additional Unique Google Workspace File Migration Considerations
Orphaned Files
You’ve probably come across the term “orphaned” content before. Files stored in Google Workspacecan “go missing” when they become orphaned. This is when the file exists but the parent folder it was located in is deleted. For example, this can occur if you create a file in someone else’s folder and that folder is deleted. Your file isn’t deleted along with the folder, but it no longer has a parent folder. It’s important to not only know where orphaned files exist in Workspace but just as important to migrate them to a known and owned location on another platform. DryvIQ has a unique capability to identify and migrate these orphaned as you see fit.
Duplicate File Names
DryvIQ has many unique auto-remediation capabilities when it comes to various file and folder conflicts that arise during migration activities. Here’s an interesting uncommonly supported one: You can store files in Google Workspace with the same name within the same directory. Instead of flagging this as a duplicate file when migrating this content to a repository that doesn’t support it (almost all of them), DryvIQ will transfer the file and automatically append a unique numeric to the file name and add it to its Revised item report.
Invalid Characters
Character limitations are very common and differ among platforms. For example, Google Workspace doesn’t have any character limitations when naming files in the UI. If one configures DryvIQ to transfer content from Workspace to a platform that does have character limitations, DryvIQ will automatically identify and convert the invalid character(s) to an “underscore” – File?xyz.txt will become File_xyz.txt and display in Dryv’s revised item reports.
Some platforms have stringent character limitations on file paths and file names. DryvIQ has a unique “truncation” feature that attempts to shave characters from a file name to fit within these limits. Of course, you can turn this off within your DryvIQ jobs and track and report on changes as Revised.
File Types
Similar to some of the other mentioned limitations, platforms will not allow storage of specific restricted file types. DryvIQ has a unique auto-remediation setting that will append a *.zip to the end of the file name and send it along while logging it in the Revised item report.
All of DryvIQ’s auto-remediation features mentioned will drastically reduce manual remediation activities that are part of every Google Workspace migration. In fact, DryvIQ transfer rates often exceed 99.99% thus removing much of the manual overhead caused by file conflicts of platform differences.
File Versions
It is very common for an organization to want to retain historical versioning on files during their migrations. Whether going to or from Google Workspace, DryvIQ has you covered, and the software has added options for version preservation. Organizations can configure DryvIQ to retain just the latest version, all versions, or X number of versions. If your legal team defines retaining all versions, then we’ve got you covered. Or maybe you want to reduce the amount of data transfer and your timeline, you can configure DryvIQ to only need to retain the last five versions. The key here, which broadly applies to DryvIQ’s configuration options, is that the software provides a lot of flexibility for you to construct your Google Workspace migration in a manner that really makes sense for your business.
How Much Data Do I Actually Have in Google Workspace?
Being migration experts we commonly get this question: “How much content do I really have in Google Workspace?” It is a paramount question that affects very important factors such as migration timeline, project scoping, and pricing. You think you’d be able to run a quick report within Google – but guess again. Understanding how much content you actually have can be quite a challenge within Workspace.
Ultimately there’s no reporting capability on sizing for native file types like Google Docs, Sheets, and Slides. You may have a very large Slide or Sheet that is a few megabytes or potentially several gigabytes in size, but Google Workspace does not provide any way to see the file size within the UI, their reporting, or programmatically via APIs. Being so, this Workspace limitation also applies to DryvIQ and its analysis capabilities; if Google itself can’t report on this metric, then there is no way DryvIQ has a way to do this. However, we have a recommendation for how you might answer this question. Although it is only a ballpark, you can still more accurately plan your Google Workspace migration efforts.
Estimating Content Volume Using Google Workspace’s Native File Report
We recommend first running a native file report in the Google Workspace Admin UI. Next, use industry standards for average file sizes to ballpark the content sizing for your Google Docs, Sheets, and Slides. We typically recommend using 500kB per file to estimate overall content sizing for your native Google Workspace file types. Therefore, if you have a total of 10,000 Google Docs, Sheets, and Slides combined, you might estimate the content size to be 500kB x 10,000 = 5,000,000kB or ~5GB. Again, this is not a perfect solution but it should put you somewhere in the right ballpark. Take a look below to see how to run the report.
1. Sign in to your Google Admin console with an administrator account
2. From the Admin console Home page, go to Reports
3. On the left, go to Audit log > Drive
4. Click the Add a filter > Item Type and then select Google Docs, Google Sheets, or Google Slides for your filter to create your report.
Start Your Google Workspace Migration
Hopefully, this has shed some light on the unique qualities of Google Workspace that could complicate your migration project. DryvIQ can help you solve some of these complexities whether you’re migrating to, or from, Workspace. If you’re planning on making a move, we would love to discuss your upcoming Google Workspace migration or synchronization efforts, so please contact us to get started.
