Worked example: a 120-person organisation moves 2 TB of file shares to SharePoint and OneDrive
A fictional public sector style organisation follows our file server to SharePoint playbook: inventory, a new site design, simplified permissions, a pre-scan, Migration Manager passes and a read-only cutover. The organisation is invented to show how the steps fit together.
Who they are and what they faced
Illustrative example. The organisation is fictional; the steps follow our How to migrate a file server to SharePoint and OneDrive.
Organisation
A 120-person local government style organisation with a main office, a depot and a library branch (fictional, not based on any real council)
Moving from → to
One Windows file server with about 2 TB across department shares, a public records share and personal home drives mapped as drive letters by Group Policy → SharePoint sites per department, some connected to Teams, and OneDrive for home drives, in an existing Microsoft 365 tenant with Active Directory users synced to Entra ID
Constraints
- Records have legal retention requirements, so nothing can simply be deleted without the records officer agreeing
- Folder trees in some departments are very deep, with long folder names built up over many years
- Several teams use Access databases and linked Excel workbooks on the shares
- Internet bandwidth at the main office is shared with public services such as library computers
Assess
The IT team used the inventory step of the playbook: Get-SmbShare to list shares, the per-folder size and file count script to measure each share, and Get-ADUser with the HomeDirectory property to list home drives. Each share got a business owner in the Mailbox and data inventory sheet, and an Action column of Move, Archive, Delete or Leave read-only.
The last-modified spread showed a large part of the 2 TB had not been touched in years. A search for .accdb, .mdb and linked workbooks found several Access databases used by the depot and finance. Some home drives turned out to be team folders in disguise.
Decisions
- Use Migration Manager rather than SPMT The playbook recommends Migration Manager for several shares or a project run centrally across agents. SPMT suits a small move from one machine.
- Move less: archive stale data first The playbook calls moving less the single biggest saving. The records officer and owners agreed an archive cut-off, recorded in the Data retention mapping, instead of moving everything.
- Keep Access databases off SharePoint The playbook warns Access databases do not work well from a synced library and suggests keeping them on a server or Azure Files.
Plan
The plan ran a pilot share first, then department waves, each with a scan-only run, a bulk first pass out of hours and incremental passes, finishing with a read-only cutover per wave. The risk register included the 400-character path limit, broken permissions inheritance, Access databases, bandwidth contention with public services and the deprecation of auto rerun.
The communication plan told staff when their department would move, that they would use Add shortcut to My files rather than syncing whole libraries, and that drive letters would disappear on cutover day.
Decisions
- Run bulk passes overnight and at weekends The playbook advises out-of-hours bulk copies because they compete with users for server and internet bandwidth, and Microsoft 365 throttles heavy traffic.
- Keep the server read-only for an agreed period after cutover The playbook says decommissioning is the true point of no return, so the plan kept the server read-only first.
Design
Each share was mapped to a target site and library in the Target-state architecture, using a separate site where the audience or permissions differed. Deep trees in planning and works were promoted to their own libraries, and site and library names were kept short to leave room in the 400-character path for folders and file names.
NTFS permissions were exported with Get-Acl for each top-level folder and reduced to Owners, Members and Visitors groups holding synced security groups. Owners signed off the mapping sheet. Item-level permissions were avoided; where a folder needed different access, it became its own library.
Decisions
- Turn off Preserve file share permissions for redesigned libraries The playbook warns that copying every NTFS ACL recreates years of broken inheritance as unique permissions, and Microsoft recommends a general limit of 5,000 per library.
- Prepare a user mapping file for departed staff Files owned by accounts no longer in Entra ID would come across as the migration account. The playbook says to use a mapping file and turn off Microsoft Entra lookup when doing so.
- Home drives go to OneDrive, team folders in disguise go to sites The playbook separates personal home drives from team content; the disguised team folders were mapped to their department site instead.
Execute
The team ran the playbook's read-only PowerShell pre-scan for each share with the matching site and library prefix, fixed long paths, invalid names and oversized files at source, and scanned again until only accepted items remained. OneDrive was pre-provisioned for home drive owners with Request-SPOPersonalSite and the sites were created with the short names from the design.
Migration Manager agents were downloaded from the SharePoint admin center and installed on machines close to the file server, each with a working folder on a fast disk with the free space Microsoft requires. Tasks were created per share with Only perform scanning on for the first run, auto rerun off, junk extensions excluded and the agreed archive cut-off applied. The bulk passes ran out of hours, and each re-run performed an incremental pass.
Decisions
- Read the task reports after every pass Auto rerun is scheduled for deprecation, so the playbook says to turn it off, read the reports and re-run tasks yourself once the cause is fixed.
- Keep the default invalid character handling The playbook recommends leaving it on and renaming at source the files people rely on by name, such as files referenced by macros.
Cutover
For each wave, at the agreed time the team changed the share permissions to read-only with Revoke-SmbShareAccess and Grant-SmbShareAccess, ran the final incremental pass, checked the task reports and recorded file counts and sizes in the Data validation report with the share owner. The drive letter mappings were removed from Group Policy so staff stopped saving to the old server.
Staff opened their department library in the browser and used Add shortcut to My files on the folders they needed. Large archive libraries were left browser-only, in line with Microsoft's guidance of no more than 300,000 synced files per user.
Decisions
- Make the source read-only before the final pass The playbook does this so no new changes land on the server between the final pass and the switch.
- Use shortcuts, not mass sync The playbook recommends shortcuts to specific folders and warns that large synced libraries slow or stall OneDrive.
Close
Validation used the playbook's checks: file counts and sizes matched apart from excluded and accepted files, the final pass showed no new failures, every share was in its planned site and library, permissions matched the signed-off mapping, linked files and macros worked or had been kept on a server as planned, net use no longer listed the old drive letters and test saves to the old shares were refused.
The server stayed read-only for the agreed period. Then the team archived it as the Data retention mapping required, confirmed the archive could be restored, and followed the Decommission checklist.
Decisions
- Archive before decommissioning The playbook says decommissioning the server after the archive cannot be undone.
The cutover timeline
- Wave week, Monday to ThursdayIncremental passes each night; owners check content in the new site and libraries.
- Friday 16:30Go / no-go: last incremental pass clean, permissions mapping signed off, quick-start guide sent, help desk briefed.
- Friday 17:30Change the wave's shares to read-only and confirm with Get-SmbShareAccess.
- Friday 18:00Run the final incremental pass for each task in the wave and download the reports.
- Friday 21:00Compare file counts and sizes with the share owner and record them in the Data validation report.
- Friday 21:30Remove the wave's drive mappings from Group Policy.
- Monday 08:00Floor support: staff add shortcuts to My files, check access and report issues to the hypercare log.
What surprised them and what they did
Paths in one department exceeded 400 charactersThe pre-scan found them early. The team shortened folder names and promoted the deepest folders into their own library, as the playbook advises.
Some files arrived owned by the migration accountThey belonged to staff who had left. A user mapping file was added for the remaining waves.
A team synced a whole archive library and OneDrive slowed downThey unsynced it and added shortcuts to the specific folders they needed, keeping under the sync guidance.
Linked workbooks broke after the moveThey had been found in the inventory, so owners rebuilt the links from a list instead of discovering them one by one.
Bulk copies slowed public computers at the library branchPasses were moved to nights and weekends only, as the playbook's considerations suggest.
Templates they used
Questions
Is this a real council?
No. The organisation is fictional and generic. It shows how the steps in our file server to SharePoint playbook fit together.
Why not move all 2 TB?
The playbook says moving less is the biggest saving. Stale data was archived under the retention rules instead of being copied.
Why were some files kept off SharePoint?
Access databases do not work well from a synced library, so the playbook suggests keeping them on a server or Azure Files.
How could they roll back a wave?
While the server was only read-only, by restoring write access and the drive mappings, then copying back anything saved in SharePoint after cutover.
Did NTFS permissions copy across?
Only where the ACLs were confirmed clean. Elsewhere access was redesigned around site Owners, Members and Visitors groups.