Google Drive Permission Changes: What CloudM Migrate Customers Need to Know

Author: Lana Ginns

Category: Migration

What Google Drive permission changes are being implemented?
Effective mid-February 2026, Google is simplifying Drive permissions so that access always cascades from parent folders to all children. The ability to selectively restrict or remove inherited permissions on individual items is being removed.

When are these Google Drive permission changes coming in?
Google will be enforcing this change in mid-February. CloudM has secured a grace period until 1 April 2026 to give our Migrate customers additional time to upgrade and prepare.

Google Drive Permission Changes: The Technical Background

TL;DR

Google is simplifying Drive permissions so that access always cascades from parent folders to all children. The ability to selectively restrict or remove inherited permissions on individual items is being removed. While the visibility of restricted folders will change, permission fidelity is fully preserved — users retain exactly the same access rights they had in the source system.

CloudM Migrate’s implementation of the Limited Access approach ensures:

Complete folder hierarchy preservation
Identical effective access rights
Alignment with Google’s design philosophy
Minimal disruption to your migration projects

Take action now: Upgrade to the new version of CloudM Migrate before 1 April 2026 to ensure uninterrupted migration capability.

Deepdive into Google Drive Permission Changes: What Is Changing Why and When
Google Drive uses an “expansive access” model for permissions, where access granted at a parent folder level automatically cascades down to all child folders and files. Historically, administrators could work around this by:

Granting broad access at a parent folder level (e.g., give the entire Sales team Editor access to /Sales/)
Selectively removing or restricting that inherited access on specific child folders or files (e.g., remove Sales team access from /Sales/Confidential-Forecasts/)

This pattern of “grant broadly, restrict selectively” is common in enterprise file systems, particularly in Microsoft SharePoint where it’s known as “broken inheritance.”

Effective mid-February 2026, Google is removing the ability to selectively restrict or remove inherited permissions on individual items. The Drive API will no longer support the “Update item only” or “Remove from item” options that allowed breaking inheritance. To restrict access to a subfolder, you must now use Google’s Limited Access folder feature. This is not a CloudM decision — it is a fundamental platform change by Google.

Why Google Drive permissions are changing

According to Google’s UX research, hidden folders caused significant user confusion. Users reported inconsistent experiences where some team members could see items that others could not, leading to uncertainty about whether content existed or had been deleted.

Google’s stated goal is to make the folder structure visible to all users, with restricted items clearly marked as inaccessible rather than hidden entirely. This aligns with Google’s “opinionated” approach to product design — providing a consistent, predictable experience for all users.

Reference: Updating access experience in Google Drive

How CloudM Migrate is Adapting to the Google Drive Permission Changes

The Limited Access Approach

After consulting directly with Google and validating our approach with our Professional Services team, CloudM Migrate is implementing Google’s Limited Access feature (inheritedPermissionsDisabled) to handle restrictive permission scenarios.

This approach was selected because it:

Preserves the complete folder hierarchy: Users maintain context of where content sits in the structure
Maintains permission fidelity: Effective access rights remain identical to the source
Aligns with Google’s intended design: Uses the Limited Access feature exactly as Google designed it
Minimises implementation risk: Lower complexity ensures reliability ahead of the deadline

How It Works

Folder-Level Restrictions

When migrating a folder where certain users should not have access:

Parent folder permissions are applied normally
The restricted child folder has inheritedPermissionsDisabled set to true
Direct permissions are applied only for users who should have access
Excluded users see the folder as greyed-out — visible but inaccessible

Example:

Folder	Source Permissions	Result in Google Drive
/Sales/	Sales Team: Editor	Sales Team can access normally
/Sales/Public/	Inherits from parent	Sales Team can access normally
/Sales/Forecasts_Q4/	Sales Team access removed	Sales Team sees folder greyed-out, cannot access

File-Level Restrictions

Google Drive does not support files having more restrictive permissions than their parent folder. To handle files with unique restrictive permissions, CloudM Migrate creates a synthetic “wrapper” folder:

A wrapper folder is created, named after the file (e.g., Confidential-Report.xlsx/)
The restricted file is placed inside the wrapper
Limited Access is applied to the wrapper folder
Excluded users see the wrapper folder greyed-out

This approach is required by Google’s new permission model and applies regardless of which migration tool or approach is used.

What The Google Drive Permission Changes Mean for End Users

Before and After

Aspect	Previous Behaviour	New Behaviour
Restricted folders	Hidden from excluded users	Visible but greyed-out
Restricted files	Hidden from excluded users	Wrapper folder visible but greyed-out
Folder hierarchy	Could appear fragmented	Preserved — users see the complete structure
Access rights	Users cannot access restricted content	Unchanged — users still cannot access restricted content

Key Points for Users

Permission fidelity is preserved. If a user could not access a folder or file in the source system, they cannot access it in Google Drive. The access controls are identical.
Visibility has changed. Restricted folders will appear greyed-out in the Drive interface rather than being completely hidden. Users can see that the folder exists but cannot open it or view its contents.
Folder hierarchy is maintained. Unlike approaches that fragment the structure, the complete folder hierarchy remains visible. This provides context about where content lives within the organisation’s file structure.
This is Google’s intended design. The greyed-out appearance is Google’s standard UX for Limited Access items, based on their user research indicating this provides a better experience than hidden content.

Affected Source Platforms

This change affects all migrations to Google Drive from external platforms. Each source platform has permission models that may trigger the Limited Access transformation:

Microsoft 365 (SharePoint and OneDrive)

SharePoint’s “broken inheritance” feature is the most common trigger. When a SharePoint library or folder has inheritance broken and users are removed from access, CloudM Migrate will apply Limited Access to the corresponding folder in Google Drive.

Key triggers:

Broken inheritance on document libraries
Explicit user/group removal from folders
Unique permissions on individual files

Windows File System

NTFS permissions with explicit Deny ACEs or disabled inheritance will trigger Limited Access in the destination.

Key triggers:

Explicit Deny ACEs on folders or files
Disabled inheritance with users removed from child items
File-level permission restrictions

Dropbox

Dropbox shared folders where users have been removed from access will trigger Limited Access.

Key triggers:

Users removed from shared folders
Team Space restrictions
Folder-level permission changes

Box

Box migrations are generally less affected due to Box’s “waterfall” permission model, which more closely aligns with Google Drive’s inheritance. However, scenarios where collaborators are removed or access levels are downgraded will still trigger Limited Access.

Key triggers:

Collaborator removal from folders
Access level downgrades on child items

Timeline and Required Action

Key Dates

Date	Event
25 February 2026	CloudM Migrate update available
Mid-February 2026	Google enforces permission changes — affects all other tools and manual processes
4 March – 1 April 2026	CloudM upgrade window (grace period)
1 April 2026	CloudM grace period ends — force upgrade to new version

What You Need to Do

Plan your upgrade. Review your current migration projects and schedule time to upgrade to the new version of CloudM Migrate.
Upgrade before 1 April. The new version will be available from 4 March. Upgrading during this window ensures uninterrupted migration capability.
Communicate with stakeholders. Inform your users and project stakeholders about the visibility change for restricted folders.

What Happens If You Don’t Upgrade

After mid-February: Other migration tools and manual permission processes will be affected by Google’s change
After 1 April: CloudM Migrate will require the upgraded version to continue Google Workspace migrations

CloudM has worked with Google to secure the grace period until 1 April, giving our customers additional time compared to the broader ecosystem. We recommend upgrading early in the window to allow time for testing and adjustment.

Pre-Migration Recommendations

To ensure the smoothest transition, we recommend the following actions before and during your migration:

Use the Environment Scan to Identify Affected Items

CloudM’s Environment Scan now includes enhanced detection for items with restrictive permissions (negative ACLs). Before migrating, run an Environment Scan to identify folders and files that will become visible as greyed-out items in Google Drive. The scan shows you exactly which item names will be exposed to users who currently cannot see them, giving you the opportunity to review and rename sensitive items before migration begins. Results are available in the CloudM UI and can be exported to CSV for detailed analysis. This feature supports all source platforms: Microsoft 365, Windows File System, Dropbox, and Box.

1. Review Source Permission Structures

Identify folders and files with restrictive permissions that will be affected by this change. Understanding where Limited Access will be applied helps set appropriate expectations.

Look for:

SharePoint libraries with broken inheritance
Folders where specific users or groups have been removed from access
Files with unique permissions different from their parent folder

2. Consider Restructuring Sensitive Folder Names

Because restricted folders will now be visible (though greyed-out), folder names will be seen by users who previously could not see them. If any folder names contain sensitive information, consider restructuring or renaming before migration.

Example: A folder named /HR/Termination-Plans-Q2/ would be visible to users even if they cannot access it. Consider whether such names should be changed to something less revealing before migration.