We're considering moving a roughly 3 TB branch-office file share from a VM on our corporate SAN to Azure Files. This would be our first Azure deployment, so we're looking for guidance on architecture, authentication, networking, migration, and backup.
The branch office currently connects to headquarters through a site-to-site VPN. The file server VM and two domain controllers are located at headquarters, while the branch firewall provides DHCP and points clients to the domain controllers for DNS. Users authenticate against our existing Active Directory environment and access a single SMB share across the VPN. Remote users connect through FortiClient VPN to reach the corporate network.
We'd like to retire the file server VM while preserving our existing AD-based permissions. Ideally, branch and remote users would have secure access to Azure Files, using private connectivity rather than exposing the storage account publicly. We also follow the 3-2-1 backup approach: the current server is backed up locally, with an additional off-site copy. What is a sensible backup and recovery strategy for Azure Files, including protection against accidental deletion or ransomware?
The data is mostly spreadsheets, PDFs, and images. We're also wondering whether SharePoint or another Microsoft 365 option would be a better fit. What would a recommended design and migration plan look like, and what performance or latency issues should we test first?
2 Answers
Treat this as part of a broader Azure foundation rather than deploying only a storage account. A typical design would include a hub network with a site-to-site VPN and Azure Firewall or another controlled network-security layer, plus a spoke for the storage workload.
Disable public access on the storage account, create a private endpoint for Azure Files in the spoke, and configure private DNS zones so on-premises clients resolve the storage name to its private address. Your on-premises DNS should forward the relevant Azure zones across the VPN. Keep the existing domain controllers and synchronize identities as appropriate for your hybrid setup, then configure Azure Files identity-based SMB access and validate share-level and NTFS-style permissions before migrating production data.
Build and test this in a separate subscription or resource group first. Also document routing, DNS, firewall rules, authentication dependencies, and what happens if the VPN or domain controllers are unavailable.
For backup, don’t rely on a single layer such as snapshots. Azure Files snapshots are useful for quick restores from accidental changes, but they should be combined with a separate backup or copy strategy and tested restores. Consider storing an additional copy in another region or account with appropriate retention and protection from deletion. Make sure the design gives you separate recovery points and that at least one copy is isolated from normal administrative credentials.
Before migration, inventory permissions, file paths, unsupported characters, open files, and applications that depend on the existing server name. Migrate a representative subset first, then perform a controlled cutover and keep the old server available until restores and user access have been verified.
This is the kind of architecture overview I needed. I’ll start with a small proof of concept, but I’ll build it around the hub, private DNS, VPN, and private endpoint requirements instead of treating Azure Files as a standalone service.