Seven articles ago I said the question had changed from whether Azure Files can replace a file server to which posture fits your estate. This is the article where I answer it the way I would across a table: workload by workload, with the criteria stated plainly enough that you can disagree with me precisely instead of vaguely.
The decision, workload by workload
Departmental and team shares, the bulk of most estates by count and the least glamorous data you own, move, and the only real question is posture. A cloud-native org with Entra-joined Windows 11 devices takes the direct mount: Entra Kerberos, a deliberate access path from the networking articles, HDD provisioned v2, done. An office-anchored or hybrid org keeps a caching server per site with File Sync and lets the refresh cycle retire the hardware naturally. The thing that used to make this answer hard, needing domain controllers in the path to get real permissions, stopped being true in May 2026, and if you skipped to the end of the series, that sentence is the series. Identity has not become a non-issue, and I would not want anyone reading this to plan as though it had: it still sets your client floor, still constrains which regions and configurations are supported, still requires the Conditional Access exclusion and the cloud-group tag from the identity build sheet, still changes which ACL tooling works, and still has to be reconciled with the private-endpoint naming. What changed is that none of those are a reason to keep a domain controller alive.
User home directories move with one eye open: the ABE gap means users see folder names they cannot enter on direct mounts, so home shares either ride a File Sync server, get carved into per-user shares, or, the answer I give more often each year, stop existing because OneDrive already ate the workload and nobody admitted it. Profile containers, FSLogix for AVD and Windows 365 estates, are the platform’s flagship use case and go on SSD with the handle limits doing the sizing, and they are also the one workload where I will not argue with anyone who chooses Azure NetApp Files at scale instead; above a few tens of thousands of concurrent handles the sharding arithmetic starts favoring ANF, and the Windows 365 series owns the details. Application data moves last and only after the feature inventory from the migration article comes back clean: anything leaning on alternate data streams, hard links, aggressive locking semantics, or single-digit-millisecond latency from on-prem belongs on a VM’s disks or ANF, not here. Archives move happily, to pay-as-you-go cool if nothing will ever scan them or HDD provisioned v2 if anything will, and the honest cheap answer for a true dead archive is Blob storage, not a file share wearing an archive costume.
The file server was never one workload. It was six workloads sharing a chassis, and the reason this decision feels hard is that they stopped sharing an answer.
When the answer is somewhere else, say so
Three referrals I make without embarrassment. Collaborative documents, the folders where humans co-edit and version and share outward, belong in SharePoint and OneDrive, where co-authoring is real and the storage is already licensed; migrating them to Azure Files preserves a 2009 workflow at 2026 prices. High-performance and enterprise-app storage, sustained tens of thousands of IOPS, files past 4 TiB, sub-millisecond latency, NFS with teeth, belongs on Azure NetApp Files, which costs more per gigabyte and less per problem at that tier. And the multi-site estate that genuinely co-edits the same files from three continents needs the distributed lock that File Sync does not have, which is a Nasuni-class purchase or a workflow redesign, and pretending otherwise buys you conflict copies with an enterprise agreement attached. Keeping a Windows file server VM, on-prem or in Azure, remains defensible in exactly one frame: when you need the server-ness itself, FSRM quotas and screens, true SACL auditing with no cache in the path, third-party agents, dedup, and you accept that you are keeping the patching, the backup agent, and the 2 a.m. pages that come with it. What is no longer defensible is keeping it by default, because the defaults changed and inertia is not a design.
What would change these answers
Three watch items would redraw parts of this map, and I flag them so this article ages honestly. Native SMB over QUIC on the service would collapse the remote-access story to “mount it from anywhere on 443” and demote two of my build sheets to history. Conditional Access on the SMB flow itself would retire the exclusion-plus-network-enforcement pattern that the identity and GSA articles spend their care on. And geo-redundancy for SSD would close the one DR gap I still design around by hand. None of the three exists today; any of the three gets this series a revision within the month it ships.
The closing argument
The file server earned twenty-five years of loyalty by being the thing that always worked, and it deserves a retirement with dignity rather than a rewrite of history: most of what it did, a managed share now does with less operational surface, real Kerberos, honest per-folder permissions, backup that survives an attacker, and an invoice that reflects decisions instead of accidents. The estate that reads this series and does the work ends up in one of three defensible places, direct mounts for the cloud-native, cached servers for the anchored, and a short, explicit list of workloads that went to the platforms that serve them better. The domain is shrinking, the server count is shrinking, and the file share, the oldest workload most organizations own, no longer holds either of them hostage. That is the arc this series belongs to, and where the servers themselves go next is a story I have already told in the Azure Arc series, with the identity half still to come.
Azure Files
‹ Previous: [AF 7.1] Build Sheet: Data Protection and Alerts
