We're considering moving a roughly 3 TB branch-office file share from an on-premises Windows file server VM to Azure Files. This would be our first Azure deployment, so we're looking for guidance on the overall design and potential pitfalls.
The branch currently connects to corporate headquarters through a site-to-site VPN. The file server and two domain controllers are located at headquarters, while the branch firewall provides DHCP and points clients to the existing domain controllers for DNS. Users authenticate against on-premises Active Directory and access the share across the VPN. Remote users connect with FortiClient VPN and then access the share through the corporate network.
We'd like to retire the file server VM to free SAN capacity while preserving our existing AD-based permissions. We need to understand the recommended approach for authentication, network routing, private access, DNS, migration, and remote-user access. We're also evaluating whether Azure Files or SharePoint would be a better fit for mostly spreadsheets, PDFs, and images.
Backup is another concern. We currently keep local backups and copy them off-site in accordance with the 3-2-1 rule. What is a practical Azure Files backup and recovery design that provides multiple independent copies and reliable point-in-time recovery?
Would an Azure landing zone with a hub-and-spoke network, private endpoints, and private DNS be appropriate, or is there a simpler architecture for this relatively small deployment?
2 Answers
Start with a proof of concept before committing. Azure Files is quick to deploy, so test real user workflows with representative files and permissions rather than just checking whether the share mounts.
The biggest risk is latency. SMB can feel very slow when traffic crosses the branch-to-HQ VPN and then another path to Azure, especially with lots of small files or applications that make frequent file operations. If possible, give the branch a direct route to Azure instead of hairpinning through headquarters. If you still have local compute at the branch, Azure File Sync is also worth testing because it can keep frequently used data local while using Azure Files as the central storage layer.
For backup, Azure Files snapshots and copies to another region can be useful, but make sure the design includes an independently recoverable copy and that restores are tested. A proof of concept should include failover and recovery, not just normal access.
That makes sense. We’ll test with real files and user workflows, including access over the existing VPN, before deciding whether direct Azure routing or a local sync cache is necessary.
Since this is your first Azure project, build a small but properly structured landing zone instead of treating the storage account as an isolated deployment. A reasonable design would include an Azure hub network with connectivity back to headquarters, firewall controls, and the required identity integration. Put the storage workload in a spoke network, disable public access, and expose Azure Files through a private endpoint.
You’ll also need private DNS configured so on-premises clients resolve the storage account name to the private endpoint address. That generally means forwarding the appropriate DNS queries from your existing DNS servers into Azure. Confirm that the branch, headquarters, and remote-user VPN paths can all reach the private endpoint over the intended routes.
Azure Files can use Active Directory-based authentication, but verify the exact identity model and permissions in a lab first. Preserve share-level permissions and NTFS-style directory permissions during migration, and test access from branch clients, remote VPN users, and administrative systems. A staged copy followed by a final cutover is safer than attempting to migrate everything during one long outage.
This is the architecture overview I was looking for. I’ll start with a small proof of concept, then validate the hub, private DNS, private endpoint, routing, and AD permissions before planning the production migration.
It’s also worth testing from an Azure Virtual Desktop session or another workload close to the storage account. That helps separate Azure Files performance from the latency introduced by the branch VPN path.