Why Your Azure File Sync Migration Doesn’t Look Like On-Premises

There's a very specific moment in almost every Azure File Sync conversation where things go from "this is going great" to "wait, what do you mean we can't do that?" P.S. That happened this week and it took me back, hence the blog post.

This usually happens right after the POC looks successful. You've synced a few hundred gigs from the D: drive of an on-premises file server, cloud tiering is working, ACLs look intact, and everyone feels good. Then someone asks how you expose the shares exactly the way they exist today, and you realize Azure Files is not playing by the same rules as a Windows file server.

The assumption everyone brings in

If you've spent time around Windows file servers, you're used to thinking of shares as flexible. You've got a volume, something like the D: drive, and inside you have a bunch of folders. Some folders get shared out, some don't, and over time you end up with a structure like this:

D:\Shared\Finance  →  \\fileserver\finance
D:\Shared\HR       →  \\fileserver\hr
D:\Shared\Scripts  →  \\fileserver\scripts

This works because Windows treats shares as pointers. The filesystem is one thing, the share layer is another. You can take any folder and promote it to a share, and Windows just rolls with the flow (thanks, Windows!).

Naturally, when you move to Azure Files, the assumption is you can do the same thing. Sync the whole drive, then expose the same folders as individual shares.

That's not how Azure Files works. Azure Files (and let's be honest, most of Azure) have different rules that require you to think and design differently.

Azure Files changes the rules, Ever so quietly

Azure Files looks like a file server from the outside. You get SMB access, UNC paths, NTFS ACL support. But under the hood it's a platform service, not a Windows server, and that difference shows up in one specific place.

The share is not a pointer. The share is the container.

There is no layer where you can take a subfolder and promote it to a share. Every share exists at the root, and everything underneath belongs to it. Microsoft documents this change, but I feel it's easy to miss until you hit the change head on.

So when you sync like this:

D:\  →  \\storageaccount\global

Azure File Sync does exactly what you asked. It mirrors the entire namespace, folders and ACLs included. But what you end up with looks like this:

\\storageaccount\global\Shared\Finance
\\storageaccount\global\Shared\HR

Those are folders. There is no supported way to turn them into:

\\storageaccount\finance
\\storageaccount\hr

That's the moment where the design has to change (fortunately or unfortunately, you decide).

Why this actually matters

If it were just cosmetic, nobody would care. But this hits three things immediately in real environments.

1. Users are mapped to specific UNC paths. Changing \\fileserver\finance to something else and you've got a user experience problem, not to mention a ticket storm.

2. Applications sometimes expect specific paths. You don't always get the luxury of just updating the mapping.

3. Your cutover strategy depends on preserving those access patterns. DNS alone doesn't fix this, because DNS can't change the share structure.

The data synced perfectly. The presentation layer did not.

The patterns that actually work

Once you accept that Azure Files is not going to behave like a Windows file server, you have a few solid options. None of these are workarounds...they're patterns people actually run in production.

Pattern 1: One Azure File Share per on-prem share

This is the cleanest design, even if it requires more intentional planning upfront. Instead of syncing the entire D:\ into one share, you sync each shared folder individually:

D:\Shared\Finance  →  \\storageaccount\finance
D:\Shared\HR       →  \\storageaccount\hr

One sync group per share. Your Azure structure actually matches how the service is designed to work. Permissions stay scoped, shares are isolated, and you're not fighting the platform.

The tradeoff is that it doesn't feel like a lift-and-shift, because it isn't one. You're being deliberate about what you sync instead of grabbing the entire volume and hoping for the best. The planning documentation is useful to help plot out what this may look like.

Pattern 2: Keep the global share and add DFS

This is usually the right answer when you've already synced the entire D: drive into a single share and don't want to start over.

You keep:

\\storageaccount\global

Then you introduce a DFS Namespace to recreate the share abstraction Azure Files doesn't provide. Users still access:

\\domain\files\finance

But behind the scenes, DFS maps that to:

\\storageaccount\global\Shared\Finance

DFS is doing the indirection that Azure Files doesn't natively support. UNC paths stay the same, share names stay the same, and you don't have to redesign your sync topology. The tradeoff is a namespace layer to manage, but in most enterprise environments that's a reasonable trade. The DFS Namespaces overview is located here.

Pattern 3: Mount and re-share from a VM

If you need behavior that's truly identical to a traditional file server, you can mount the Azure File Share to a Windows VM and re-share the subfolders from there. This works exactly the way you expect because you're back in Windows land. But you've also reintroduced a server, which is usually what my customer was trying to eliminate this week. It's a reasonable transitional pattern, not a great end state.

Pattern 4: Azure NetApp Files

If the requirement is "this needs to behave like a traditional NAS, no compromises," Azure NetApp Files is worth evaluating. It offers more flexibility around how shares are structured and presented, but it comes with a different cost profile and operational model. This is a deliberate architectural choice, not a default fallback.

What I'd actually recommend

For the scenario where a customer already has a global share synced and wants to avoid running servers in Azure: keep that model and introduce DFS. DFS preserves UNC paths, avoids re-architecting the sync topology, and works within the constraints of the platform instead of fighting them. From the user's perspective, nothing changes, which is usually the goal in these migrations.

In a greenfield design, I'd push toward one share per workload from the start. But in a POC that's already in motion, DFS is the least disruptive path forward.

The real takeaway

Azure Files is not trying to be a one-to-one replacement for a Windows file server. It gives you SMB, ACLs, and scale, but it doesn't give you the same share abstraction model. The sooner you stop trying to impose that model and start designing around how the service actually works, the cleaner the whole thing gets.

The migration isn't broken. The mental model just needs to catch up.