File Server Migration to Azure Files and SharePoint

An inventory of every in-scope file server and share — sizes, counts, age profile, NTFS ACL exports, DFS topology, drive-mapping policies and application dependencies; a written destination map and permission mapping you approve; the Azure targets built — storage accounts, shares, private connectivity, identity-based authentication, RBAC, seeded ACLs, snapshots and backup — plus Azure File Sync caches, SharePoint sites and libraries provisioned as-is, OneDrive readiness with Known Folder Move, and Azure NetApp Files volumes where the map places shares there; the migration itself with Microsoft's tooling, delta runs and per-share reconciliation; wave cutovers with DFS namespace and drive-mapping changes; helpdesk notes; decommissioning of the retired hosts; and a closeout report. Quoted per estate from $4,950; a typical estate runs about 6 weeks.

Those pages are one share, one destination, one server, at a fixed price: the SharePoint Online migration from a file share as-is is priced per server, the OneDrive services move home folders, the Company Document Migration moves a bounded document set, and Azure Files Implementation creates a share and maps one drive. This page is the estate: the per-share decision across four destinations, the identity model for Azure Files, the permission translation for SharePoint, DFS namespaces and drive mappings across sites, the applications wired to UNC paths, and the retirement of the Windows Server 2016 hosts at the end. If your job fits one of the single-purpose pages, we will tell you so on the scoping call — it is cheaper for that job.

From four questions per share, answered with inventory data and a conversation with the share owner: what is in it (Office documents people edit, or binaries, archives and application data), who uses it (a team, one person, or a process), how it is used (co-authored and shared, opened from a mapped drive, written by an application, or read at high throughput), and what its permissions look like (a few groups, or a deep tree with deny entries and special permissions). Co-authored team documents with simple permissions go to SharePoint; personal folders go to OneDrive; anything that behaves like a disk — mapped drives, application data, deep ACLs, large binaries — goes to Azure Files; NFS and sustained high-performance workloads go to Azure NetApp Files. Each disposition is written down with its reasons, and you approve the map before anything is copied.

On Azure Files, yes: the storage account joins your Active Directory or uses Microsoft Entra Kerberos for hybrid identities, share-level access is an Azure RBAC assignment, and the folder and file ACLs are copied with the data by RoboCopy or Storage Mover and enforced exactly as on the server — we verify a sample with icacls on both sides. On SharePoint Online they are translated, not copied: AD groups become Microsoft 365 or SharePoint groups, permission levels are mapped to read, contribute or full control, and deny entries and per-file special permissions have no equivalent, so shares that depend on them go to Azure Files instead. On OneDrive the owner gets the folder and nobody else, by design. The permission-mapping document shows all of this per share before you approve it.

For shares going to Azure Files, usually not. If you use DFS Namespaces, the folder target is switched at cutover and the path stays the same; if you map drives by Group Policy, the mapping is re-pointed to the new location on domain-joined devices, and on Microsoft Entra-joined devices an Intune-deployed mapping does the same. Where DFS Namespaces are not in use we recommend introducing them before the move, so this and every future change is a target switch rather than a desktop change. For shares going to SharePoint or OneDrive the experience does change — a site or a synced library instead of a drive letter — and the end-user notes for each wave say exactly what to click.

Only where a site needs local speed for large files or works through a slow or unreliable link. There, a Windows Server 2022 or 2025 host runs the Azure File Sync agent with cloud tiering: the full namespace is visible locally, hot files are cached on the server, cold files live only in Azure Files, and every site sees the same share. The Windows Server 2016 host is retired either way. Sites with good connectivity and modest files usually need no server at all — users open the Azure file share directly over VPN, ExpressRoute or a private endpoint, and SharePoint and OneDrive destinations need no server by definition.

They are the first thing the inventory looks for, because they are the thing that breaks quietly. Each application gets a named owner, its share goes to Azure Files or Azure NetApp Files where UNC access and file locking work as on a server, and the path is kept through DFS Namespaces or updated in the application's configuration with the owner. The owner tests against the new path before the old share goes read-only — that is a success criterion, not a hope. One honest caveat: an application that is very chatty over SMB may perform worse against storage in Azure than against a server in the same rack; where the test shows that, the map says so and the usual answer is to move the application server to Azure next to its storage, which is a separate migration.

Per share, roughly the length of the final delta copy plus the path switch. Seeding and the earlier delta runs happen while the share is in production, so by cutover night the remaining change is small — minutes to a couple of hours depending on the share's change rate — during which the source share is frozen and then set read-only. SharePoint and OneDrive destinations follow the same pattern with the migration tool's incremental runs. Each wave is scheduled in a window the business agrees, has a validation checklist and a rollback path, and the old share stays read-only for an observation period before the host is decommissioned.

About 6 weeks for a typical estate: inventory and the destination map in the first two weeks, targets built and seeded by week three, delta runs through week five, cutovers from week four, and decommissioning in week six. What extends it is predictable — dozens of servers, slow links that need Data Box, hundreds of ACL-heavy shares, a long change-freeze calendar, or share owners who cannot decide — and the wave plan states the real dates before you commit. Client-side delays move the dates, not the scope.

From $4,950, quoted per estate as a fixed price in writing before work begins; per our standard terms you pay after you approve delivery. The floor covers a small multi-server estate with straightforward shares. What moves the number is not the server count but ACL depth and orphaned entries, data volume and change rate, the number of sites and the speed of their links, the applications wired to UNC paths, how many shares go to SharePoint rather than Azure Files, and Data Box logistics. Scoping is quick — a server list, a share list with sizes and your driving date — and no work starts without the written quote. Microsoft's charges for Azure storage, Data Box, Azure NetApp Files and Microsoft 365 storage are separate and projected in the destination map.

Yes. Per Microsoft's product lifecycle, extended support for Windows Server 2016 ends on 12 January 2027; after that the host receives no security updates unless it is enrolled in Extended Security Updates, which Microsoft bills per core per year through Azure Arc to your Azure subscription. A file server holding every department's documents is a poor thing to leave unpatched, and it is also the easiest 2016 role to retire, because the data can move to services Microsoft patches for you. We build the wave plan to retire the file hosts before the date where the estate allows it; for a host that cannot make it, ESU enrollment through Azure Arc is a separate, quoted step and the metered ESU charge is yours.

You can, and the result is usually a workaround file server nobody planned for. SharePoint is excellent for the documents a team co-authors, shares and searches; it is not a disk. Applications that write to UNC paths, scanner drop folders, database and backup files, very large binaries, shares with deep or deny-based permissions, and libraries that would exceed the sync client's recommended item count all behave badly there. Azure Files exists precisely so those shares keep their semantics without a server to patch. The destination map is honest about the split for your estate — many estates end up with most of the volume on Azure Files and most of the daily collaboration in SharePoint, and both are the right answer.

Each retired host goes through a decommission checklist in an order agreed with your backup and compliance owners: Azure File Sync server endpoints removed, DFS targets and namespace roots cleared, a final backup taken and retained for your retention period, service accounts and scheduled tasks cleaned up, the computer object disabled, then power off. Going forward, Azure Files data is protected with share snapshots and Azure Backup for Azure Files, configured as a deliverable; SharePoint and OneDrive content is covered by versioning, the recycle bins and Microsoft's retention controls, and a dedicated Microsoft 365 backup product is a separate decision we can advise on. Nothing is deleted from a source server until you approve it.

Roman Sotnik is the service owner. IT Partner has been a Microsoft partner since 2006 and holds Microsoft Solutions Partner designations for Infrastructure and Modern Work — the two solution areas this migration sits across, Azure storage on one side and SharePoint and OneDrive on the other.