46 TB of File Shares Moved Into SharePoint With No Downtime for 2,400 Users
Two decades of mapped drives across 94 file shares, with permissions nobody could explain and path lengths that break on upload. We fixed the information architecture and the permissions before moving anything, then cut over with a read-only window instead of an outage.
About the Client
The Challenge
The manufacturer ran 94 file shares on ageing Windows servers across several sites, totalling 46 TB and 18.2 million files. The oldest content predated the current ERP. Drive letters were mapped by login script, the mappings differed by site, and the DFS namespace had been extended enough times that nobody could describe the whole layout.
Permissions were the real problem. Access had been granted through a mixture of nested Active Directory groups, direct user ACLs applied at folder and sometimes file level, and a long tail of "just give them access" changes made over two decades. Several branches of the tree had inheritance broken at four or five levels. Lifting that structure into SharePoint as-is would have produced unique permission scopes in the thousands per library, which SharePoint handles badly and nobody can administer.
The technical blockers were the ordinary ones, at scale. A scan found 61,000 items whose full decoded URL would exceed SharePoint's length limit once the site and library path were prepended — mostly deep project folders with long descriptive names repeated at every level. There were files with characters and naming patterns SharePoint rejects, locked files open on desktops, personal archive files that should never have been on a server share, and folders colliding with reserved SharePoint paths.
And the business constraint: production planning, quality and engineering all worked directly from those shares during a shift. A weekend outage was theoretically available and practically unacceptable, because the site ran weekend shifts. The requirement was continuous read access throughout, with the shortest possible read-only period.
Our Approach
The information architecture decision comes before the tooling decision. We settled what the target looked like, cleaned the source to fit it, and only then chose how to move the bytes.
Scan, Profile and Archive Decision (Weeks 1-4)
Scanned every share for volume, file count, age, duplication, path length, illegal characters and permission structure. The age profile drove the first real decision: 37% of the content had not been opened in years and was archived to low-cost storage rather than migrated. Migrating content nobody reads costs migration time, SharePoint storage, search index quality and, later, Copilot answer quality.
Information Architecture and Target Design (Weeks 3-7)
Designed the target before touching the tooling: a hub with department and project sites rather than one site per share, libraries scoped so no single library would approach the item counts where views and governance become painful, and metadata columns replacing the top two or three folder levels. Indexed columns and metadata-driven views were designed in from the start so libraries stay usable past the list view threshold. Teams and channel mappings were agreed at the same time so the content landed where people would actually work on it.
Permissions Remediation Before Migration (Weeks 5-11)
Rebuilt access on groups, in the source, before migration. Direct user ACLs were replaced with Entra ID group membership, inheritance was restored wherever the break could not be justified to the data owner, and the remaining genuine exceptions were documented and mapped deliberately to SharePoint groups. Doing this first is the difference between a clean target and a permissions archaeology project that runs for months after go-live, with users unable to reach content and nobody able to say why.
Tooling Selection and Pilot (Weeks 8-12)
Evaluated Migration Manager in the SharePoint admin centre against third-party tooling on this estate. Migration Manager handles file share to SharePoint well, runs agents against the source, maps AD identities and is included in the subscription; third-party tools earn their cost where complex metadata mapping, detailed reporting and heavy scheduling are needed. We used Migration Manager for the bulk and a third-party tool for the shares with unusual structures. Piloted one department end to end, including adoption and drive-mapping changes.
Incremental Passes and Read-Only Cutover (Weeks 11-20)
Ran a full pass against the live source while users kept working, then repeated delta passes on changed files until each pass was small and predictable. At cutover the share went read-only rather than offline, a final delta ran, then the login script mapping was removed and the DFS path redirected. Users kept read access to the old location for 30 days as insurance. Each of 12 waves followed the same pattern, and the first wave was the one with the most complex permissions.
Solution Architecture
Target structure: A hub with department and project sites, libraries sized to stay manageable, and metadata columns replacing the top folder levels, with indexed columns and metadata-driven views designed in from the start
Migration tooling: Migration Manager agents against the file servers for the bulk of the estate, with a third-party tool reserved for the shares needing complex metadata mapping
Permissions: Group-based access rebuilt in the source before the move, inheritance restored where the break was unjustified, and genuine exceptions mapped deliberately rather than replicated
Cutover model: Full pass against a live source, repeated deltas until small, then a read-only window, a final delta and a DFS redirect — no offline period at any point
Post-migration: Archive tier for aged content, versioning and retention set at library level, and search re-crawled and validated before each wave closed. Downstream retrieval work continues through Copilot for SharePoint
Results
Client identity withheld under confidentiality. Figures are representative of engagements of this scope.
Technologies Used
Key Takeaways
If your organization is facing a similar challenge, here's what we learned:
The information architecture decision has to precede the move. Lifting a share into a library preserves every structural problem and adds SharePoint's own limits on top. Deciding the target shape first — sites, libraries, metadata replacing folder levels — is what makes the migration worth doing at all.
Remediate permissions before migration, never after. Item-level ACLs and broken inheritance become unique permission scopes in the target, which SharePoint handles poorly and administrators cannot unpick. Rebuilding access on groups in the source is unglamorous and it is the step that decides whether go-live is calm.
Scan for path length and naming early enough to act on it. Long paths and rejected characters do not stop a migration; they produce a failure list that someone has to work through under time pressure. Find them in week two, when renaming a folder is a normal request.
Archiving is the cheapest part of the project. Content nobody has opened in years costs migration hours, storage, search quality and later Copilot answer quality. Deciding what not to move is usually the highest-return hour spent on a migration.
Read-only beats offline. Incremental passes against a live source, then a short read-only window for the final delta, removes the outage entirely. Combined with a grace period on the old location, it also removes the pressure that makes teams skip validation. See our data governance consultants for the structure work that follows.
Still Running File Servers You Meant to Retire?
We scan the estate, tell you how much of it should never move, and run the migration to a read-only cutover rather than a weekend outage.