File Share to SharePoint Migration
Network drives, a NAS, Dropbox or Google Drive into SharePoint — with the target structure designed first, because a literal copy just moves the problem.
The copying is the easy part. The value is in the inventory, the permissions remodelling, and knowing which files should not be migrated at all.
Do not copy the folder tree. A literal migration reproduces every problem that made the file server hard to use, hits path length limits, and produces a permissions model nobody can audit. The sequence that works is inventory, design the target, pilot one department, copy in the background while the source stays live, then a delta pass and read-only cutover. The source is never modified and is never deleted on the day.
Six sources, and what each one involves
Windows file server or NAS
The most common source. Decades of nested folders and NTFS permissions granted to individuals. The folders migrate easily; the permissions need remodelling rather than copying.
Dropbox or Box
Straightforward content-wise. The work is in sharing links, which all break, and in deciding what was genuinely organisational versus what was one person's account.
Google Drive and Shared Drives
Shared Drives and SharePoint sites are different models. Covered in more depth on our Google Workspace migration page, because the whole platform usually moves together.
Individual laptops
The files nobody admits are only in one place. Finding these is slow and is almost always worth doing, because a laptop is not a filing system.
An old SharePoint or intranet
Restructuring an existing SharePoint that grew organically. Done alongside the live one and moved in stages rather than by stopping work.
A mixture of all of the above
Realistically the usual answer. The inventory stage exists to find out what you actually have before anybody commits to a date.
Six things that go wrong
None of these are exotic and all of them are predictable. They are the reason a file migration is a project rather than a copy command.
Path length limits
Deeply nested folders with long names hit path length limits and fail to copy. This is the single most common cause of a migration reporting errors, and it is why flattening structure is part of the design rather than an optional tidy-up.
Every existing link breaks
Shortcuts, mapped drives, links inside documents, and anything a third-party system points at. We inventory the ones that matter and reissue them deliberately, rather than discovering them one complaint at a time.
Permissions do not translate literally
NTFS permissions granted user by user, copied faithfully into SharePoint, produce a structure nobody can audit. Permissions are remodelled around groups — which means deciding who should have access, not just recording who currently does.
Illegal characters and filenames
Characters that were fine on a file server are rejected by SharePoint. These are found and renamed during staging rather than discovered as failures on the night.
Timestamps and history
Created and modified dates can usually be preserved with the right tooling; file-server version history generally cannot. Where that matters for compliance, the source stays available for a defined period.
Data that should not move at all
Most file servers are half archive. Migrating everything means paying to store a decade of obsolete files. The inventory is the moment to archive rather than carry it across.
Six stages, source live throughout
Inventory
What you actually have: total volume, folder depth, file count, oversized files, illegal names, and which shares are genuinely in use. Automated scan plus conversation, because usage data does not tell you what matters.
Design the target
Sites, libraries and a permissions model built around how the business works — not a copy of the folder tree. This is the stage that determines whether people can find anything afterwards.
Pilot
One department moved first, fully, including permissions and sync. Problems surface here at small scale, while changing the design is still cheap.
Staged copy
Bulk content copied in the background over days or weeks while the file server stays live and authoritative. Nothing is switched off.
Delta and cutover
A final pass catches everything changed since the bulk copy, then the old share goes read-only. Read-only rather than deleted, deliberately.
Decommission
The old share stays readable for an agreed period. Only once nobody has needed it for weeks does it get retired.
SharePoint migration — common questions
helpHow long does a file share to SharePoint migration take?
expand_more
Driven by data volume and by how much restructuring is needed, not by user count. A few hundred gigabytes with a sane folder structure is typically two to four weeks including design and a pilot. A decade-old file server with deep nesting and per-user permissions takes longer, and most of that additional time is design and clean-up rather than copying.
helpCan we just copy our folder structure into SharePoint?
expand_more
You can, and we would advise against it. A literal copy reproduces the problems that made the file server hard to use, adds path length failures, and produces a permissions state nobody can audit. It also wastes the one opportunity you will get to restructure, because doing it later means moving everything twice.
helpWhat happens to our existing permissions?
expand_more
They are used as evidence, not as the specification. We look at what access exists today, establish what access should exist, and build a group-based model to match. Copying NTFS permissions literally into SharePoint is technically possible and produces something unmaintainable within months.
helpWill mapped drives and shortcuts still work?
expand_more
No. Mapped drives, desktop shortcuts, links embedded in documents and any third-party system pointing at the old paths will all break. SharePoint libraries can be synced to File Explorer so people still work in folders, which covers most day-to-day use. The links that matter are inventoried and reissued.
helpDo we have to stop working during the migration?
expand_more
No. Content is copied in the background while the file server stays live and authoritative, and a final delta pass catches anything that changed. The only disruptive moment is when the old share goes read-only, which is scheduled with you and is a matter of minutes rather than a weekend.
helpWhat about files nobody has opened in years?
expand_more
Archive them rather than migrating them. Most file servers are half archive, and carrying that across means paying to store a decade of obsolete material and making search worse for everybody. The inventory identifies it; the decision about what to keep is yours.
helpWe are moving from Google Drive specifically.
expand_more
That normally happens as part of a whole-platform move, and Google Shared Drives map onto SharePoint sites in a way that needs designing rather than copying. Our Google Workspace to Microsoft 365 page covers that case in more detail, including what happens to Docs, Sheets and Apps Script.
helpIs the data safe during the migration?
expand_more
The source is never modified. Content is copied, not moved, and the original stays live and authoritative until you agree to make it read-only. If something goes wrong mid-migration, the answer is always that the file server is still there and still correct.
Related pages
SharePoint for Business
The destination: sites, libraries and a permissions model that lasts.
Google Workspace to Microsoft 365
If Drive is moving as part of a whole-platform migration.
OneDrive for Business
Where personal files go, and why that boundary matters.
Microsoft 365 Migration
The umbrella service: mail and files together.
Microsoft 365 Migration Checklist
The practical before, during and after list.
Microsoft 365 Backup
What protects the data once it is in SharePoint — and what does not.
Microsoft 365 Services
Licensing, implementation, migration, security and support.
Scope the migration
Rough data volume and how many shares is enough to start.
Scope your file migration
Tell us roughly how much data you have and where it lives. The inventory stage will tell us the rest — including how much of it should not move at all.
- check_circle
Source stays live and unmodified throughout
- check_circle
Target structure designed before anything is copied
- check_circle
Old share goes read-only, not deleted, at cutover
Moving a file server alongside an existing Windows domain is covered, item by item, on our page for Microsoft 365 partner in Ernakulam.
Prefer to talk first? Call +91 99467 89916 or email admin@techgeum.com.