Can I import a SharePoint site straight into someone's My Drive?

No. SharePoint Online content goes to shared drives, one shared drive per site collection, with libraries and nested sites becoming folders. OneDrive content is the part that goes to a user's My Drive. If a site really belongs to one person, create the shared drive, import, then move the folder and hand over the ownership afterwards.

Does the import bring version history?

Only the latest version of each file arrives. If you have documents under audit, warranty or litigation, export their version history from Microsoft 365 before you decommission the tenant, because that history is not recoverable from the Google side afterwards.

OneDrive to Google Drive migration: what the import drops

Q: What happens to files owned by someone outside our tenant?

They are not imported. Either the external owner transfers the item to one of your accounts inside Microsoft 365 first, or somebody downloads it and uploads it to the new shared drive as your copy. Decide which, per folder, before the run rather than after.

The library nobody could open on Monday

Say a 24-person engineering firm moves to Google Workspace over a long weekend. Mail goes fine. By Monday at nine the project managers cannot find the four SharePoint libraries they live in, the site pages that held the client checklists are not there at all, and two people have edit rights on a folder they could only ever read before. Nothing failed. The import tool did exactly what its documentation says it does, and nobody had read that documentation closely enough to know what it meant for this particular company.

File migrations go wrong in a quiet way. Mail either arrives or it does not, and a bounce tells you which. Files arrive with the wrong shape and you find out five weeks later, when somebody needs the version of a drawing from March. So on every Microsoft 365 to Workspace project we answer two questions in writing before a single import runs: where does each kind of content land, and what does the tool not carry at all.

Which tool this is, and where it lives

OneDrive and SharePoint Online imports both run from the Google Admin console, under Menu, then Data, then Data import and export, then Data migration. There is nothing to install and no server to stand up. The import runs in Google's cloud and reads your Microsoft tenant using a Microsoft 365 Global Administrator sign-in on one side and a Google super administrator on the other.

Google made the OneDrive import generally available on 4 February 2025 and the SharePoint Online import on 14 July 2025. The SharePoint announcement put a default run at up to 100 SharePoint sites at a time, going into shared drives, with delta runs to pick up files that changed afterwards and a report of migrated and skipped counts you can export. An advanced method for larger estates became generally available on 25 August 2026: it runs several batches at once, scales its speed to your Microsoft licensing tier, and Google states it carries no additional tool cost. Those per-run figures have moved more than once as the tool has grown, so we read the current limit in the console on the day we plan the batches instead of trusting a number from a release note.

One thing worth settling early. Google Workspace Migrate, the older self-hosted product, will no longer be available for Exchange Online, SharePoint Online and OneDrive as of the end of 2026, and Google's own migration product matrix now points those sources at the data import tool. If a proposal written for you last year assumes Workspace Migrate for the Microsoft side, it needs rewriting before it becomes a project plan.

Where each thing lands, in one table

This is the table we put in front of a client before anyone clicks anything. It is the entire argument on one screen, and it is usually the moment somebody says "wait, the lists?"

What you have in Microsoft 365	Where it lands in Google	What to check afterwards
OneDrive for Business files	That user's My Drive, at the top level unless you set a target folder	Formats are kept, so a PDF arrives as a PDF. Confirm the Google account exists and is licensed first
A SharePoint site collection	A shared drive, one per site. Nested sites become folders	You cannot send SharePoint content straight into a person's My Drive, so decide the shared drive naming before you start
A document library	A folder inside that shared drive	Library-level settings such as required metadata do not travel
A SharePoint list	Nothing. Lists are not imported	Export each list you still use and rebuild it as a Sheet, or as a form plus a Sheet
A site page or news post	Nothing. Pages are not imported	Rebuild the handful that people actually open, usually in Docs or Sites
Site and folder permissions	Viewer, Contributor and Content Manager on the shared drive	Identities missing from your identity map lose their access silently
A Writer permission on a file	Editor in Drive	Items marked Restricted are skipped outright, not downgraded
Version history	Only the latest version of each file	Export the history of anything under audit, warranty or litigation before the run

Two rows carry most of the pain: lists and version history. Both are things people assume a file migration includes, because they look like files from the outside.

Sharing links: why only one survives per item

A single file in SharePoint or OneDrive can carry several sharing links at once, each with its own audience and its own permission. One "anyone with the link can view" for a client, one "anyone in the organisation can edit" for the team, one direct grant for a contractor. Drive does not work that way. An item in Drive has one link-based sharing state.

So when the import finds several "Anyone" links pointing at the same item, it keeps the most restrictive of them. That is the right default, and it is also why Monday morning feels broken: a client who had a view link to a proposal may now have nothing, because a tighter link on the same file won. Direct permissions behave better. A Writer in SharePoint becomes an Editor in Drive, and Visitors, Members and Owners on a folder become Viewer, Contributor and Content Manager.

What we do about it is unglamorous and it works: before the run, we pull the list of items shared by link with people outside the company, and we decide for each one whether it gets re-shared from Drive afterwards or dropped on purpose. Usually most of them can be dropped. The ones that matter are the live client folders, and there are rarely more than a dozen.

What does not come across, and the export we do first

Google documents this plainly, which is a kindness. The items the file import does not bring over:

Previous versions of a file. Only the latest version arrives.
Files kept in Personal Vault.
Favourites, folder shortcuts, and folder colours.
Document expiration dates.
SharePoint lists and SharePoint web pages.
Permissions for users and groups that are not in your identity map.
Items owned by people outside your tenant.

That last one surprises people most often. A folder a partner agency created inside your site is owned by them, so it is not yours to import. Either they hand it over inside Microsoft 365 first, or somebody downloads it and uploads it to the new shared drive as your copy, which also resets the authorship. Decide which, in writing, per folder.

The export we always run before the import: version history for regulated or warranty-bearing documents, the contents of every Personal Vault that is actually in use, and a CSV of each SharePoint list that still has a reader. Those three take an afternoon and they are not recoverable once the Microsoft tenant is gone.

The identity map is the real work

The import matches people on both sides with an identity map: a CSV whose columns are the source entity and the destination email address. You can skip it when the addresses are identical, or when only the domain changes and the local part stays the same. Group names can be mapped to Google Groups.

Source Entity,Destination Email
maria.lopez@oldcompany.com,maria.lopez@newcompany.com
projects@oldcompany.com,projects@newcompany.com
j.kim@oldcompany.com,jkim@newcompany.com

This file is where a file migration is won or lost, and it is never clean. The leavers who still own folders. The shared mailbox that was made the owner of a site because it seemed tidy at the time. The contractor whose account is in a different tenant. The person who married and changed their address two years ago and has permissions under both. Anything not in the map does not fail loudly, it just arrives with less access than it had.

So we build the map from the Microsoft side's actual permission export, not from the HR list of current staff, then walk the exceptions with whoever knows the history of the company. On a 25-person firm that is a two-hour conversation. It is the two hours that decide whether Monday is calm.

The order when mail moves in the same week

Files and mail are separate imports, and they do not have to happen together. When they do, this is the order we use:

Create and license every Google account first. The import does not create accounts, and an unlicensed user is a skipped user.
Run the identity map against a pilot: two or three people, one small SharePoint site. Check permissions and a known file by hand, not just the report.
Import the bulk of the files while everyone is still working in Microsoft 365. Nothing is deleted on the Microsoft side, so this is safe to do in daylight.
Cut the mail over, then run the mail import.
Run a delta file import after the cutover to pick up everything people changed in the meantime.
Re-share the external links you decided to keep, and only then tell people to stop opening OneDrive.

One warning that costs real money: do not end an import and start a fresh one over the same data. That is how a company ends up with two copies of a project folder and nobody sure which one is being edited. Use a delta run for the same scope instead.

If the mail side of the same week is what worries you, the authentication records are the part that bites after an MX change, and you can check those yourself in a minute.

How Guanacos Tech helps

We run Microsoft 365 to Workspace moves end to end for small and mid-sized teams: the permission export, the identity map, the shared-drive design, the lists and version history that have to be exported by hand, the pilot, the batches and the reconciliation afterwards. In English and Spanish, across North America and Latin America, on Workspace projects since 2018. If you want the file side planned before anyone clicks import, we work as Google Workspace consultants for teams your size; the scope of the file side is on the file migration page, and the whole route is on the Google Workspace migration page. A 30-minute call is enough to produce your own version of the table above and the list of things that will not come across.

OneDrive and SharePoint to Google Drive: what the import keeps, and what it quietly leaves behind