How to Migrate a Google Shared Drive to SharePoint

To migrate a Google shared drive to SharePoint, you inventory the files and permissions, create the destination SharePoint sites and libraries, move the content with Microsoft's Migration Manager or a third party tool, then rebuild and test access before switching users over. Manual download and upload works for a handful of small folders, but anything larger needs a tool that carries permissions, versions and metadata across. This guide covers when the move makes sense, how to plan it, and the problems to expect.

Why move from Google shared drives to SharePoint?

The most common reason is consolidation. When a company standardizes on Microsoft 365 for email, Teams and Office apps, keeping files in Google Workspace means two sets of logins, two security models and two places to search. SharePoint puts documents next to Teams channels, Outlook and the Office apps people already use.

Other reasons include finer control over permissions, retention and data loss prevention policies managed in one place, and the ability to build workflows and apps on top of document libraries with the Power Platform.

Before you commit, answer three questions honestly:

• Will SharePoint fit how your teams actually collaborate, or are they deeply attached to Google Docs and Sheets?
• Do your security and compliance needs require controls you cannot get in your current setup?
• Are you moving everything, or only the content that belongs with Microsoft 365 workloads?

Google shared drives vs SharePoint

Both platforms handle shared files well. The differences lie in how they are organized and governed.

Storage allowances on both sides depend on your license tier, so check your current plans rather than relying on published figures that change.

Step 1: Inventory files and permissions

Every successful migration starts with knowing what you have.

• List the shared drives. Record each shared drive, its owner and the team that uses it.
• Measure content. Note file counts, total size, very large files and very deep folder paths. Long paths and unusual characters cause failures later.
• Document permissions. Record who has manager, content manager, contributor, commenter and viewer access, and which files are shared outside the organization.
• Flag Google native files. Docs, Sheets, Slides and especially Forms, Sites and Apps Script do not have exact Microsoft equivalents. Decide how each should be converted or replaced.
• Clean up first. Archive or delete obsolete content. Moving clutter costs time and makes the new site harder to use.

Step 2: Design the SharePoint structure

Do not copy the Google folder tree blindly. A migration is a chance to fix it. Map each shared drive to a SharePoint site or a document library within a site, decide which permission groups each site needs, and add metadata columns where they would replace deep folder nesting. If the content belongs to a team that already works in Microsoft Teams, use the site connected to that team so files appear in the channel.

Step 3: Choose a migration method

Microsoft Migration Manager

Microsoft offers Migration Manager for Google Workspace, started from the Microsoft 365 admin center. It connects to Google with an administrator account, scans and assesses drives, lets you map destinations and user identities, then migrates and reports on the results. Microsoft's documentation notes that file level permissions and older file versions need explicit migration settings, so review those options before you run anything. A simplified Lite version is available for smaller tenants.

Third party migration tools

Commercial tools exist for complex projects with heavy permissions, external sharing, tight cutover windows or multiple source systems. They usually add more detailed reporting, scheduling and delta syncs. Compare them on how they handle permissions, versions, Google native file conversion and incremental passes, and run a pilot before you sign.

Manual download and upload

For a small set of files you can download from Google Drive and upload to a SharePoint library. Google converts native files to Office formats on download.

1. In Google Drive, open the shared drive, select the folders and choose Download.
2. In SharePoint, create or open the destination site and its document library.
3. Upload the files in small batches, or sync the library with OneDrive and copy them in.
4. Set access on the site or library using SharePoint groups, then adjust exceptions folder by folder.

Manual migration loses version history, sharing settings and original owners, so treat it as a fallback, not a plan.

Step 4: Pilot, migrate and cut over

1. Run a pilot. Migrate one representative shared drive and have its users test access, links and file formats.
2. Fix mapping issues. Unmatched user identities and unsupported files show up in the pilot reports.
3. Migrate in waves. Move departments one at a time, with a short freeze on the source drive during each wave.
4. Run a final delta pass. Copy anything changed since the main run, then set the Google drive to read only.
5. Communicate. Tell users where their files now live, how to sync them and who to ask for help.

Troubleshooting common problems

Files fail to transfer

Check the migration report first. Common causes are file paths that are too long, unsupported characters, files above the size limit and file types the tool cannot convert. Shorten paths, rename problem files, then rerun only the failures.

Permissions do not match

Compare the SharePoint permissions against your inventory from step 1. Unmapped user accounts are the usual culprit. Fix the identity mapping, then reapply permissions at the site or library level rather than file by file wherever possible. Ask a sample of users to confirm they see what they should.

Missing or broken files

Spot check that file counts and sizes match between source and destination. Google Forms, Sites and Apps Script will not arrive as working equivalents and need separate rebuilds. Embedded links between Google files will still point to Google, so plan to update the most important ones.

Codeeo's team of 80+ across Dubai, Riyadh and Karachi works with Microsoft 365, SharePoint and the Power Platform as part of wider system projects. If you are planning a move, our Microsoft 365 services cover migration planning, site design and governance, and we can extend libraries with Power Platform developers or connect them to other systems through Azure integration. To discuss your shared drives, contact our team.