Migrating a Windows file server to Azure Files: the plan you would actually run

The file server migration is the classic first cloud project: high visibility, real users, and one gotcha — identity — that quietly breaks most first attempts. Here is the plan as I would actually run it, decision table first, warnings in plain language.

New to cloud? CAMPUX is a free, build-first course. Start here →

To migrate a Windows file server to Azure Files, pick the target first — direct file share, Azure File Sync cache, or lift the VM — fix identity for SMB before copying anything, seed with RoboCopy, then cut over with a final incremental pass; identity, not the copy, usually fails first.

Most guides start with "create a storage account." That is step four. Start there and you will land 2 TB in Azure, mount the share, and watch every user get access denied — the ACLs you copied reference an identity system the storage account knows nothing about. So this plan does decisions and identity first, copying last. That order works.

Step one: the decision, not the storage account

There are three honest destinations for an on-prem Windows file server, and the choice hinges on two questions: do users need LAN-speed access after the migration, and does anything on that server depend on it being a real Windows box?

Option 1: Azure Files direct — kill the server

The clean ending. Your shares become Azure file shares, users connect over SMB straight to the storage account, and the old server gets decommissioned. No OS to patch, no disks to replace, backups become share snapshots and Azure Backup. Right answer when users have good connectivity to the Azure region — or work remotely anyway — and the server is a plain document store. The trade: every file open now crosses the WAN, fine for documents, noticeable for people who work in large media files all day.

Option 2: Azure File Sync — cloud is the truth, the branch keeps a cache

Azure File Sync inverts the setup: the Azure file share becomes the authoritative copy, and one or more on-prem Windows servers become caches of it. Cloud tiering is the clever part — hot files stay on local disk at full speed, cold files tier to Azure leaving only a pointer, so a 10 TB share can sit behind a server with 2 TB of disk. Right answer when branch offices need LAN speed, when several sites should see the same data, or when you want a gradual off-ramp instead of a hard cutover. The honest trade: you are still running a Windows server. Fewer of them, smaller disks, but the patching does not go away.

Option 3: lift the VM — the "do not migrate to Files" answer

Sometimes the right call is admitting Azure Files is the wrong target. If an application needs a local drive letter, installs a filter driver (some backup and AV agents do), depends on NTFS features Azure Files does not implement, or has a vendor who says "supported on Windows Server only" — lift the server as an Azure VM and keep it a file server, just on Azure disks. It feels like cheating. It is not. A working lift-and-shift beats a broken modernization every time, and you can revisit once the awkward app is retired.

New to how storage accounts, tiers, and shares fit together? Class 12 on storage accounts covers the foundation this article stands on, free.

Step two: identity for SMB — the part everyone underestimates

Here is the sentence I wish someone had said before my first attempt: an Azure file share does not know who your users are until you explicitly teach it. On-prem, the file server was domain-joined, so Kerberos and NTFS ACLs just worked. A storage account is not. Mount a share with the account key and you are effectively root — every file, full control, no identity at all. Fine for the migration copy; catastrophic as an end state for users.

For real users with real permissions you need identity-based authentication, and as of 2026 you are mostly choosing between two options:

• Microsoft Entra Kerberos for hybrid identities. Entra ID issues the Kerberos tickets. The win: users on Entra-joined machines can reach shares without line of sight to a domain controller — no VPN back to a DC just to open a file. The catch is in the name: it works for hybrid identities, accounts synced from on-prem AD, and directory-level permissions still involve your AD-sourced SIDs — this is not a way to escape AD entirely.
• On-prem AD DS integration. You domain-join the storage account itself, and clients get Kerberos tickets from your domain controllers exactly as they do for the old server. Most faithful to how things worked before — but clients need connectivity to a DC to authenticate, which matters for remote workers.

The honest hedge: pure-cloud identity for SMB shares — no on-prem AD anywhere in the story — still has rough edges as of 2026. If you are cloud-only with no AD, read the current identity-based authentication overview for Azure Files before promising anyone anything; the supported matrix has been moving, and the live doc beats my snapshot of it.

Whichever route you take, permissions are two-layered: share-level permissions assigned as Azure RBAC roles (the SMB Share Contributor family) act like the old share permissions, and NTFS ACLs work underneath, exactly as before. Both layers have to be right; one without the other fails in confusing ways.

Step three: the mechanics — sizing, seeding, and RoboCopy without regret

Storage account and share choices

Create a storage account dedicated to file shares — do not mix them into an account serving an application's blobs, because settings and limits will fight each other. The tier choice: standard (HDD-backed, pay for use plus transactions, or provisioned in newer models) versus premium (SSD-backed, provisioned, consistent low latency). General document share: standard is usually fine. Transaction-heavy — small files opened constantly, application data, profile containers — premium stops being a luxury; more on cost below. Redundancy matters too: the trade-offs are in LRS vs ZRS vs GRS, and the wider account decision in storage account types explained.

RoboCopy: the flags, and the warning

For a single server, RoboCopy remains the honest workhorse. Mount the Azure share — with the storage account key for the migration itself, so ACL writes are not blocked — then run something like:

robocopy D:\Shares\Finance \\acct.file.core.windows.net\finance /MIR /COPYALL /DCOPY:T /MT:16 /R:2 /W:1 /LOG+:C:\migr\finance.log

• /MIR mirrors the tree — including deletions — which is what makes incremental re-runs converge on an exact copy.
• /COPYALL carries data, timestamps, NTFS ACLs, owner, and auditing info. Without it your permissions stay behind.
• /DCOPY:T preserves folder timestamps, which users notice more than you would think.
• /MT:16 multithreads the copy; /R:2 /W:1 stops a locked file from stalling the night's run for hours of retries.

Now the warning, stated plainly: /MIR deletes files at the destination that do not exist at the source. Point it the wrong way — or at the wrong folder — and it will efficiently and irreversibly erase the destination to match. People have mirrored an empty folder over a live share. Triple-check both paths, run with /L (list mode, no changes) first, and never run your first /MIR against anything you cannot restore.

Storage Mover, and seeding over nights

Migrating a fleet rather than one server? Azure Storage Mover is Microsoft's managed service for exactly this — agents on-prem, orchestration and progress tracking in Azure, no hand-rolled scripts per server. For one or two servers, RoboCopy plus a log file is simpler and I would not reach further.

Either way, the pattern that works is seeding over nights: run the bulk copy as a scheduled task outside business hours, as many nights as it takes, while users keep working on the old server. The first pass moves terabytes; each later /MIR pass only moves the changes and gets faster. Watch bandwidth — an uncapped multithreaded RoboCopy will saturate the office uplink, so throttle it (fewer threads, or QoS on the link) or keep it to hours nobody is on a video call. There is no downtime in this phase, which is why rushing it is pointless.

Step four: cutover without a bad weekend

Cutover is short if the seeding was patient:

1. Freeze writes on the old server — shares read-only or offline, Friday evening in most shops.
2. Run the final incremental pass. Same RoboCopy command; it moves only the delta and finishes fast.
3. Repoint the namespace. This is why DFS Namespaces earns its keep: if users reach shares through \\yourdomain\files\finance rather than the server's real name, you change the folder target to the Azure share and every mapped drive and shortcut keeps working, untouched. If you never deployed DFS-N, this migration is the reason to. The alternative — a DNS CNAME from the old server name to the storage endpoint — can work for SMB but has enough constraints that I treat it as the fallback, not the plan.
4. Verify with real users — open, edit, save, check a restricted folder correctly denies someone.
5. Keep the rollback ready. The old server, untouched and read-only, is the rollback plan. Point DFS-N back at it and you are where you started, minus files changed since cutover. Keep it powered for two weeks or more before decommissioning. Migrations with a cheap rollback get approved; migrations without one get postponed forever.

One more cutover-eve check: SMB runs on port 445 outbound, and many consumer ISPs block it. Office traffic over ExpressRoute, VPN, or a private endpoint is fine; the person working from a coffee shop is not. Decide the remote-access answer — VPN, private endpoint, or SMB over QUIC via File Sync — before the switch, not during Monday's ticket flood.

The gotcha everyone hits: ACLs copy, identity mapping breaks

RoboCopy will faithfully deliver every ACL to Azure. Whether Azure can do anything with them is a separate question — and it is the one that ruins Monday mornings.

This deserves its own section because it is the single most common failure in first file-server migrations. NTFS ACLs are lists of SIDs. When your /COPYALL run finishes, those SIDs are all present on the Azure share. But at access time, the storage account has to map the connecting user's Kerberos ticket to those SIDs — and that only works if the identity integration from step two is correctly configured and the user's account is synced and matching. If not, you get a share full of perfect permissions nobody can pass: access denied for everyone, or worse, for only some people in ways that look random.

The defense is boring and non-negotiable: pilot one share with one real user before you move terabytes. Pick a small share, run the full plan end to end — identity config, RBAC share role, copy with ACLs — then mount as an ordinary user, not as an admin and not with the account key, and have a genuine member of that department open a file they should see and get denied on one they should not. Fifteen minutes of testing here saves the roll-back-everything meeting, and if the pilot fails you learn exactly which layer is broken while the blast radius is one volunteer.

The honest gap: what Azure Files does not give you

Competing guides end at "and now you are in the cloud." Here is what you give up — set expectations before your users set them for you:

• No deduplication on the share. If your old server ran Windows dedup and squeezed 6 TB of logical data onto 3 TB of disk, Azure Files stores — and bills — the full logical size. Size and price against the rehydrated number, not the number in Server Manager.
• Snapshots behave differently. Share snapshots are good, and Azure Backup manages them well, but they are share-level and capped in count — not a drop-in clone of the VSS Previous Versions experience users are used to, though a File Sync cache server can restore some of that. Practice the restore in the backup and restore a file share lab before the day you need it under pressure.
• Latency is a WAN now. On the LAN, a file opened in a few milliseconds. Direct to Azure Files, every operation carries your round trip to the region. For documents nobody notices; for chatty applications or 500 MB spreadsheets, people notice. This is precisely the case File Sync's local cache exists for.
• Some NTFS-adjacent features do not carry over. Anything that assumed a real Windows volume — certain quota tooling, filter-driver agents, legacy audit setups — needs a fresh answer on the Azure side, not an assumption that it came along.

A note on cost, with the hedges attached

I will not quote per-GB prices because they change and vary by region — run your numbers through the Azure pricing calculator. The shape of the cost is the useful part. On standard shares under consumption billing you pay for capacity and per transaction — and a share serving hundreds of users doing small reads and writes all day generates a startling number of transactions. Teams have been surprised by bills where transactions, not storage, were the biggest line. Premium is provisioned: you pay for what you reserve, transactions included, which is often cheaper for transaction-heavy workloads despite the faster disks — model both before assuming standard is the budget option. Microsoft has also been moving standard shares toward provisioned billing, so check what your region offers when you build rather than trusting any article's snapshot, including this one. And remember the dedup point above: your billable size is the logical size.

Questions people also ask

Can Azure Files fully replace a Windows file server?

For most general-purpose department shares, yes — Azure Files speaks SMB, honors NTFS ACLs, and supports Kerberos authentication, so users keep their mapped drives and permissions. It cannot replace every server, though. Applications that need local-path access, filter drivers, or very low latency, and servers relying on features like deduplication, are better served by Azure File Sync or by lifting the server as a VM. Test your specific workloads on a pilot share before committing.

How do I keep NTFS permissions when migrating to Azure Files?

Copy the data with a tool that preserves ACLs — RoboCopy with /COPYALL, or Azure File Sync, which carries ACLs natively. But copying ACLs is only half the job: those ACLs reference SIDs from your Active Directory, so the storage account must be joined to the same identity source (AD DS integration or Microsoft Entra Kerberos for hybrid identities) for Azure to resolve them at access time. If identity is not configured, the ACLs are present but effectively dead, and users get access denied. Verify with a real user on a pilot share before the full copy.

Should I use Azure File Sync or migrate directly to Azure Files?

Go direct if your users have decent connectivity to Azure and you want the server gone — fewer moving parts, no server to patch. Choose Azure File Sync when people still need LAN-speed access, typically branch offices or workloads with large files opened frequently: the share becomes the authoritative copy in Azure while a local Windows server keeps a cache, and cloud tiering keeps only hot files on local disk. File Sync means you still run a server, so it is a stepping stone or a branch-office pattern, not a way to eliminate on-prem entirely.

How long does it take to migrate a file server to Azure Files?

Plan in weeks, not days, and let the data seed over nights. The initial bulk copy is bandwidth-bound — a few terabytes over a typical office uplink can take several nights of scheduled RoboCopy runs — but that happens while users keep working on the old server, so it costs no downtime. The parts that actually take calendar time are identity setup, the pilot share test with real users, and change management. The final incremental pass and cutover can usually fit in one evening or weekend window.

Do mapped drives and UNC paths still work after moving to Azure Files?

Yes, with planning. Azure Files exposes a standard UNC path, and if you front your shares with DFS Namespaces, you repoint the folder targets at cutover and users' existing paths keep working with no changes on their machines. If users map directly to the old server name, you either update the drive mappings via Group Policy or use a DNS CNAME approach, which has more constraints. One practical caveat: SMB over port 445 outbound is blocked by many ISPs, so remote users typically need a VPN, private endpoint, or SMB over QUIC path. Sort this out before cutover, not after.