Evaluate performance, permissions, networking, security, and cost considerations before migrating file shares to Azure

Migration PlanningAzure FilesSMB / NFSHybrid Cloud2026

Key Considerations Before Migrating
File Shares to Azure

Moving file shares to Azure is not a copy job — it is an infrastructure transformation. The organizations that get it right spend more time planning than executing. The ones that get it wrong discover post-cutover that their ACLs didn't migrate, their performance tier was wrong for the workload, or their users can't authenticate. This guide covers every decision you need to make before writing the first RoboCopy command.

Port 445

The SMB port blocked by most ISPs and many corporate firewalls — the single most common cause of Azure Files connectivity failures after migration

100 TiB

Maximum size of a single Standard Azure file share with large file share enabled. Shares above this limit must be split before migration — plan the split before any data moves

30

Maximum number of Azure file shares a single Azure File Sync server endpoint can sync. Environments with more than 30 on-premises shares require share consolidation planning

File fidelity

The most overlooked migration requirement: timestamps, ACLs, alternate data streams, and metadata that copy tools handle differently — and that users notice immediately when missing

Table of Contents

1. 01Consideration 1 — Discovery: Know What You Are Migrating
2. 02Consideration 2 — Target Architecture: Direct Mount vs Azure File Sync
3. 03Consideration 3 — Protocol Decision: SMB vs NFS
4. 04Consideration 4 — Performance Tier and Capacity Planning
5. 05Consideration 5 — Network Architecture and Connectivity
6. 06Consideration 6 — Identity, Authentication, and ACL Migration
7. 07Consideration 7 — File Fidelity: What Gets Lost in Translation
8. 08Consideration 8 — Migration Tool Selection
9. 09Consideration 9 — Cutover Planning and Minimizing Downtime
10. 10Consideration 10 — Post-Migration Validation Checklist

The decision to migrate file shares to Azure is usually straightforward. The execution is not. Unlike server migrations — where a VM is lifted and shifted relatively intact — a file share migration involves decisions about protocols, performance tiers, authentication models, network paths, and copy tool behavior, all of which interact in ways that are not obvious until something breaks. This guide structures those decisions into ten considerations you must work through before any data movement begins. Each consideration is a decision point — not a task. The tasks come after.

Figure 1 — Migration planning sequence: the ten decision points that must be resolved before any data moves

Each decision feeds the next. Target architecture (02) determines which protocol options are available (03). Protocol determines required network configuration (05). Identity model (06) determines how ACLs migrate (07). Work through these in order — skipping ahead creates dependencies you will have to revisit under time pressure.

01Discovery: Know What You Are MigratingPre-Migration · Required

The most common cause of migration projects running over time and budget is an inaccurate inventory. Organizations consistently underestimate share count, total data size, and — critically — the number of small files. A 5 TB share containing 50 large files migrates in hours. A 5 TB share containing 50 million small files takes days. Azure Migrate now supports agentless discovery of SMB and NFS file shares across Windows and Linux servers, delivering a migration-ready inventory in hours rather than days of manual scripting.

What to capture for each share: total size in GiB, file count (not just folder count), average file size, oldest and newest file timestamps, protocol (SMB 2.x / 3.x / NFS), host OS, authentication model (NTLM, Kerberos, local accounts), whether the share is accessed by applications via hardcoded UNC paths, peak concurrent users, and observed IOPS and throughput during business hours. For environments over 100 TiB, Microsoft recommends Komprise — a third-party tool providing deep access-pattern analytics, file age distribution, and data temperature analysis across the estate.

1

Deploy or Update the Azure Migrate Appliance

Deploy the Azure Migrate appliance in your on-premises environment. If already deployed for server migration, update it to the latest version — file share discovery requires an updated agent released in early 2026. The appliance discovers SMB and NFS shares automatically and agentlessly — no agent installation on file servers required. Discovery typically completes within 2–6 hours depending on environment size.

2

Review Inventory and Export for Stakeholder Sign-Off

Review the inventory in the Azure Migrate portal via both the Per-Server view and the Infrastructure view. Export to Excel — this is your official migration scope baseline. Have stakeholders sign off on the scope before designing the target architecture. Shares discovered but not in scope need a documented decision: migrate, retire, or archive.

3

Run Azure Files Assessment for Right-Sizing Recommendations

After discovery, run an Azure Files assessment in Azure Migrate. Configure your target region, pricing preference, and redundancy. The assessment analyses actual usage and recommends the correct tier for each share — preventing Premium over-provisioning where Standard is sufficient and under-provisioning where latency matters. Download the assessment as your official sizing document.

4

Identify Application-Owned Shares and Hidden Dependencies

Identify which shares are accessed by applications via hardcoded UNC paths — these require DFS-Namespace redirection or application reconfiguration at cutover, not just a share move. Identify shares accessed by scheduled tasks, backup agents, or monitoring systems. These dependencies are invisible in a share inventory but become critical blockers at cutover if not planned for in advance.

PowerShell — Inventory SMB file shares on Windows Server before Azure Migrate# Export share name, path, size (GB), and file count to CSV Get-SmbShare | Where-Object {$_.Name -notmatch '^\w\$|ADMIN\$|IPC\$'} | ForEach-Object { $share = $_; $path = $share.Path $size = if (Test-Path $path) { (Get-ChildItem $path -Recurse -ErrorAction SilentlyContinue | Measure-Object -Property Length -Sum).Sum / 1GB } else { 0 } $count = if (Test-Path $path) { (Get-ChildItem $path -Recurse -File -ErrorAction SilentlyContinue).Count } else { 0 } [PSCustomObject]@{ ShareName = $share.Name; Path = $path SizeGB = [Math]::Round($size,2); FileCount = $count } } | Export-Csv ".\share-inventory.csv" -NoTypeInformation Import-Csv ".\share-inventory.csv" | Format-Table -AutoSize

02Target Architecture: Direct Mount vs Azure File SyncArchitecture · Critical Decision

Azure Files can be deployed in two fundamentally different models. Direct mount replaces your on-premises file server entirely — users and applications mount the Azure file share directly over SMB or NFS. Azure File Sync keeps an on-premises Windows Server as a local cache while syncing all data to Azure in the background — users connect to the local server at LAN speed, while Azure holds the authoritative copy with optional cloud tiering of cold data.

Direct mount requires all clients to have reliable, low-latency connectivity to Azure — typically only acceptable for Azure-hosted workloads or users connected via ExpressRoute or high-bandwidth VPN. Azure File Sync is the right choice for branch offices, remote sites, or any environment where local file access performance is a hard requirement. The two models are not interchangeable and cannot be swapped post-migration without re-architecting.

Figure 2 — Two deployment models: direct mount (cloud-only) vs Azure File Sync (hybrid)

Direct mount eliminates the on-premises file server entirely — simpler to operate but requires reliable low-latency connectivity for all users. Azure File Sync keeps a Windows Server cache with LAN-speed access; cloud tiering keeps only hot data on-premises while Azure holds everything. Choose based on your users' location and network quality — you cannot change models post-migration without re-architecting.

Factor	Direct Mount	Azure File Sync (Hybrid)
On-premises server	Not required	Required (Windows Server 2016+)
User access latency	Azure network RTT applies to all reads/writes	LAN speed for cached files; recall delay for cold data
Protocol support	SMB 3.x and NFS 4.1	SMB only — no NFS sync
Share limit per server	No practical limit	30 sync endpoints per server endpoint
Cloud tiering	Not applicable	Available — cold data recalled on demand
Best for	Azure VMs, AVD, ExpressRoute offices, new greenfield deployments	Branch offices, NAS replacement, large estates with cold data

03Protocol Decision: SMB vs NFSProtocol · Authentication Impact

Azure Files supports two protocols: SMB 3.x for Windows clients and NFS 4.1 for Linux and POSIX workloads. The protocol choice is typically driven by client OS, but the differences in authentication and network access have significant migration design implications.

SMB 3.x supports identity-based authentication through AD DS, Azure AD DS, or Entra ID Kerberos. It works on port 445 — frequently blocked by ISPs and firewalls. SMB supports full Windows NTFS ACLs on files and directories enabling per-user permissions that migrate from on-premises servers. SMB over QUIC (port 443) provides a VPN-free option for Windows 11 clients where port 445 is blocked.

NFS 4.1 does not authenticate — access is controlled entirely by VNet and subnet restrictions. Every client in the allowed subnet has access to the NFS share. NFS requires a Premium SSD storage account and is accessible only from private networks. Never expose an NFS share on a public endpoint — there is no authentication mechanism to protect it. If your workload uses Windows ACLs and per-user permissions, choose SMB. If it runs on Linux with POSIX permissions, choose NFS.

Port 445 — Test This Before Setting a Cutover Date

Verify port 445 from every client location before committing to a migration timeline. Run: Test-NetConnection -ComputerName <account>.file.core.windows.net -Port 445 from Azure VMs, from on-premises machines, and from a remote worker's machine. Any failure here must be resolved before cutover. If port 445 is blocked and cannot be unblocked, plan for SMB over QUIC (Windows 11 only), Azure Virtual Desktop, or a VPN requirement for remote users.

04Performance Tier and Capacity PlanningSizing · Cost Impact

Azure Files offers four tiers in 2026. Choosing the wrong tier is the most common cause of both performance problems and unnecessary cost after migration. The Azure Migrate assessment provides tier recommendations based on observed usage — always validate these against peak load requirements, not just average metrics. Premium SSD uses a provisioned billing model — you pay for GiB allocated, not GiB used. Over-provisioning Premium wastes money; monitor actual usage and right-size down periodically after migration.

Tier	Media	Billing	Max IOPS	Best For
Standard HDD Hot	HDD	Pay-as-you-go (consumed GiB + transactions)	~10,000	General-purpose user file shares, mixed daily access
Standard HDD Cool	HDD	Lower capacity cost, higher transaction cost	~10,000	Shares accessed less than once per week — archival-leaning
Standard Tx Optimised	HDD	Lower transaction cost, higher capacity cost	~10,000	High-transaction, low-data workloads
Premium SSD	SSD	Provisioned GiB (pay for allocated, not used)	Up to 100,000+	SAP HANA, SQL on Linux (NFS), VDI user profiles, sub-ms latency

Azure CLI — Create Standard and Premium file shares with correct tiers# Standard HDD — for general user shares az storage account create --name stfiles001 --resource-group rg-files-prod \ --location eastus --sku Standard_ZRS --kind StorageV2 \ --enable-large-file-share --allow-blob-public-access false --min-tls-version TLS1_2 az storage share-rm create --name hr-shared --storage-account stfiles001 \ --resource-group rg-files-prod --quota 5120 --enabled-protocols SMB # Premium SSD — for latency-sensitive workloads (provisioned billing) az storage account create --name stfilesprem001 --resource-group rg-files-prod \ --location eastus --sku Premium_ZRS --kind FileStorage \ --allow-blob-public-access false --min-tls-version TLS1_2 az storage share-rm create --name sap-data --storage-account stfilesprem001 \ --resource-group rg-files-prod --quota 4096 --enabled-protocols NFS

05Network Architecture and ConnectivityInfrastructure · Connectivity

Network configuration is the most technically complex migration consideration and the one most likely to surprise you post-cutover. Azure Files must be reachable from every client type before the share can serve as the production replacement. The required configuration depends on the protocol and endpoint type.

Figure 3 — Network connectivity paths for Azure Files: SMB and NFS options for different client types

Private endpoint is the recommended path for all deployments — it disables public internet access and routes all traffic through the VNet. On-premises clients require ExpressRoute or Site-to-Site VPN. SMB over QUIC (port 443) provides a VPN-free path for Windows 11 clients where port 445 is blocked — but requires Premium tier and specific storage account configuration.

1

Create Private Endpoint for the File Sub-Resource

Create a Private Endpoint targeting the file sub-resource (not blob). Allow the portal to auto-create the Private DNS Zone privatelink.file.core.windows.net and link it to your VNet. Test: Resolve-DnsName <account>.file.core.windows.net from inside the VNet should return a private IP (10.x.x.x), not a public IP. Only disable public access after confirming the private path works.

2

Configure DNS Forwarding for On-Premises Clients

On-premises DNS must forward the privatelink.file.core.windows.net zone to Azure's Private DNS Resolver. Without this, on-premises clients resolve to the public IP even with a Private Endpoint configured. Use Azure Private DNS Resolver (2022+) to handle forwarding without deploying custom DNS forwarder VMs.

3

Verify Port 445 from Every Client Type

Test-NetConnection -ComputerName <account>.file.core.windows.net -Port 445 from: (a) an Azure VM in the same VNet, (b) an on-premises machine over ExpressRoute or VPN, and (c) a remote worker's machine. Any failure must be resolved before cutover — it will not fix itself. Document the result of each test as part of your pre-migration go/no-go checklist.

06Identity, Authentication, and ACL MigrationIdentity · Access Control

Authentication for Azure Files determines whether users can access their files after migration — and it is the consideration most commonly deferred until it becomes an emergency. Azure Files supports four methods, but only two are recommended for new deployments in 2026: Entra ID Kerberos for cloud-native or hybrid environments without on-premises AD DS, and Active Directory Domain Services (AD DS) for environments with existing on-premises domain controllers as the authoritative identity source.

The authentication method determines how file and folder ACLs are interpreted. If users access the Azure file share using the same Active Directory identities they use on-premises, and the storage account is joined to the same AD DS domain, NTFS ACLs migrate faithfully — the SIDs in the ACLs match the SIDs of authenticated users. If the authentication model changes during migration (for example, moving from on-premises AD DS to Entra ID Kerberos), ACLs must be re-evaluated because SIDs may not match.

Auth Method	Requires	ACL Support	Recommended For
AD DS (on-prem)	On-premises domain controller with line of sight	Full NTFS ACLs, per-user	Hybrid environments keeping on-prem AD DS as identity source
Entra ID Kerberos	Entra ID only — no on-prem DC needed	Full NTFS ACLs, per-user	Cloud-native environments, new deployments in 2026
Azure AD DS	Azure AD DS managed domain	Full NTFS ACLs, per-user	Managed domain without on-prem DC
Storage Account Key	Always available (account key)	Share-level only — no file-level ACLs	Break-glass only. Never as primary auth in production.

Critical: Set Root ACLs Before Copying Any Files

If migrating from on-premises file servers to Azure Files, set the ACLs for the root directory of the file share before copying any files. If you copy millions of files first and then change root-level permissions, the ACL propagation must recurse through every child object — on a multi-million file share this takes hours and blocks user access during propagation. Set root directory permissions first, confirm they are correct, then begin the copy job.

Azure CLI — Enable Entra ID Kerberos and assign RBAC on file share# Enable Entra ID Kerberos authentication on the storage account az storage account update --name stfiles001 --resource-group rg-files-prod \ --enable-files-aadkerb true # Assign Storage File Data SMB Share Contributor to an Entra ID group SHARE_ID=$(az storage share-rm show --storage-account stfiles001 \ --resource-group rg-files-prod --name hr-shared --query id -o tsv) az role assignment create \ --assignee-object-id <GROUP-OBJECT-ID> \ --assignee-principal-type Group \ --role "Storage File Data SMB Share Contributor" \ --scope $SHARE_ID

07File Fidelity: What Gets Lost in TranslationData Integrity · Copy Tool Selection

File fidelity is the completeness of what your copy tool preserves from source to destination. Users notice missing timestamps immediately. Applications that rely on ACLs break silently. Compliance systems that depend on last-modified dates report incorrect audit trails. Understanding what your chosen copy tool preserves — and what it drops — is essential before any data movement begins.

File Attribute	Migration Risk if Lost	Preserved by
Data stream	File is unreadable. All copy tools preserve this.	All tools
NTFS ACLs	All users get the same access level. Security model breaks.	RoboCopy /COPYALL, Azure Storage Mover
Creation timestamp	All files show migration date as creation date. Affects compliance and archiving.	RoboCopy /COPYALL
Last modified timestamp	Most impactful for users and applications that sort by modified date.	RoboCopy /COPYALL, AzCopy /PreserveSMBInfo
File attributes	Read-only files become writable. Hidden files become visible.	RoboCopy /COPYALL
Owner SID	Ownership audit reports are incorrect. Required for some backup agents.	RoboCopy /COPYALL with SeBackupPrivilege

RoboCopy /COPYALL Requires SeBackupPrivilege to Work Correctly

RoboCopy /COPYALL copies Data, Attributes, Timestamps, NTFS ACLs, Owner, and Auditing. However, it requires the running account to have SeBackupPrivilege and SeRestorePrivilege Windows privileges to preserve ownership and full ACL fidelity. Run RoboCopy as a local Administrator or as a service account with these privileges explicitly granted. Running as a standard domain user with /COPYALL will silently skip ACL and owner preservation on files where the running account lacks permission — without any error message.

08Migration Tool SelectionTooling · Data Movement

No single tool is best for all scenarios. The right choice depends on the source environment, target architecture, data volume, and file fidelity requirements. The table below maps source scenarios to recommended tools with key trade-offs.

Tool	Best For Source	Key Advantage	Key Limitation
Azure Storage Mover	NFS shares on Linux/NAS, SMB shares	Managed Azure service, no infrastructure to maintain, incremental copy support	Newer tool. No Windows NTFS ACL preservation for SMB source.
RoboCopy	Windows file servers, DFS shares	Full Windows file fidelity (/COPYALL). Widely understood. Multi-threaded (/MT).	Requires mounted share. Sensitive to network latency on large file counts.
Azure File Sync	Windows Server shares of any size	Continuous bidirectional sync — no fixed cutover window. Built for hybrid.	SMB only. Windows Server required. 30-share-per-server limit.
AzCopy	Azure Blob, S3, other cloud storage	Very fast parallel transfers. Best for cloud-to-cloud migrations.	Limited Windows ACL preservation. Better suited for Blob than Azure Files from on-premises.
Azure Data Box	Very large datasets (100 TB+) with limited bandwidth	Physical appliance eliminates bandwidth constraint for massive migrations.	7–14 day device round-trip. Last-mile delta sync still needed over network.

RoboCopy — Production migration with full file fidelity (run as Administrator)# Mount the Azure file share (Kerberos/Entra ID if identity auth is enabled) net use Z: \\stfiles001.file.core.windows.net\hr-shared # Initial bulk copy — full fidelity robocopy \\on-prem-server\hr-shared Z:\ ^ /E /COPYALL /DCOPY:DAT /MT:32 /R:3 /W:5 ^ /LOG:bulk-copy-log.txt /TEE # Delta sync runs (before cutover) — /XO copies only newer files robocopy \\on-prem-server\hr-shared Z:\ ^ /E /COPYALL /DCOPY:DAT /MT:32 /R:3 /W:5 ^ /XO /LOG+:delta-log.txt /TEE # Final delta (during cutover window, after source is read-only) robocopy \\on-prem-server\hr-shared Z:\ ^ /E /COPYALL /DCOPY:DAT /MT:32 /R:3 /W:5 ^ /XO /LOG+:final-delta.txt /TEE

09Cutover Planning and Minimizing DowntimeOperations · Downtime

The cutover window is the period between making the source share read-only and confirming all users can access the destination Azure file share. The goal is to make this window as short as possible by completing as much data movement as possible beforehand through incremental delta syncs.

Figure 4 — Cutover timeline: bulk copy, delta syncs, cutover window, and DFS redirect to live

The bulk copy phase runs for days or weeks with the source live. Daily /XO delta runs narrow the gap. The cutover window opens only when the source is made read-only — the final delta is fast because only changes since the last delta need copying. DFS-Namespace redirect switches all users to the Azure share simultaneously without requiring them to remap drives.

1

Set Root ACLs on Azure Share Before Any Data Copy

Before running the first RoboCopy job, set the root directory ACLs on the Azure file share to match the source share's root permissions. This is critical — attempting to change root ACLs after a large file migration triggers recursive ACL propagation that can take hours and blocks user access during propagation.

2

Run Bulk Copy Then Daily Delta Syncs

Run the initial bulk copy without a time constraint. After it completes, run daily delta syncs with RoboCopy /XO to copy only files changed since the previous run. Each delta run should be shorter than the last as the change backlog shrinks. Measure each run's duration — the final delta duration equals your cutover downtime.

3

Open the Cutover Window: Freeze Source, Run Final Delta

At the scheduled cutover window, make the source share read-only — remove write permissions from all users or redirect DFS-N to a non-existent path. Run the final RoboCopy delta. The duration equals your downtime. If it takes longer than expected, assess whether to continue or defer.

4

Update DFS-Namespace and Keep Source Read-Only for 48 Hours

Update the DFS-N target from the old on-premises UNC path to the Azure file share UNC path. This switches all users simultaneously without requiring drive remapping. Keep the source share read-only for 48 hours as a rollback option — if a critical issue is found, redirect DFS-N back to source within minutes. Decommission the source only after 48 hours of successful Azure operation.

10Post-Migration Validation ChecklistValidation · Go-Live

Validation confirms every aspect of the migration met its requirements before the source is decommissioned. Run through every item on this checklist — do not skip items because they seem obvious. The issues that cause post-migration incidents are almost always the ones that "seemed fine" and were not explicitly tested.

• Connectivity verified from all client types. Azure VMs, on-premises machines, and remote workers can all reach the Azure file share. Test-NetConnection port 445 succeeds from each location.
• Authentication working. Users authenticate via Entra ID Kerberos or AD DS credentials — no prompts for storage account keys or anonymous access dialogs.
• ACLs verified. Spot-check representative folders: read-only users cannot write, write-permitted users can create and modify, users outside the permitted group receive access denied.
• File count parity confirmed. Run robocopy /L /E /LOG:verify.txt between source and destination after the final delta — file counts must match. Any discrepancy must be investigated before decommissioning the source.
• Timestamps preserved. Spot-check creation and modification timestamps on a representative sample. Timestamps should match the source, not the migration date.
• All applications tested. Every application that accessed the old share has been tested against the Azure share. UNC paths, configuration files, and connection strings updated where required.
• Performance baseline passed. Open and save representative large files from the highest-latency user locations. Compare to pre-migration baseline. Escalate if response time exceeds the agreed SLA.
• Soft delete enabled. Soft delete configured with at least a 14-day retention period — protecting against accidental share or file deletion in the first weeks of production.
• Diagnostic logging active. StorageFileLogs flowing to a Log Analytics workspace. Verify by checking for authentication events in the logs within 24 hours of go-live.
• Defender for Storage enabled. Microsoft Defender for Storage configured on the storage account for malware scanning and anomalous access alerting from day one of production use.

Migration Planning Summary: The Non-Negotiables

→Inventory first, always. An inaccurate file count is the most common cause of migration schedule overruns. A 5 TB share with 50 million small files behaves completely differently from a 5 TB share with 50 large files — for copy tool performance, delta sync duration, and cutover window estimation. Use Azure Migrate agentless discovery before estimating any timeline.

→Test port 445 from every client type before committing to a cutover date. This is the most common post-migration connectivity failure. ISPs block 445. Corporate firewalls block 445. Test from Azure VMs, from on-premises servers, and from remote user machines before the cutover date is scheduled.

→Set root ACLs on the Azure file share before the bulk copy, not after. Post-copy root ACL changes propagate recursively through every child object — on a multi-million file share this takes hours and blocks access during propagation. Do it first, confirm it is correct, then start copying files.

→Use DFS-Namespace as the cutover mechanism. Updating a DFS-N target switches all users simultaneously without requiring drive remapping. Without DFS-N, every user must remap — which means a help desk flood. If you don't use DFS-N today, implementing it before the migration is worth the effort.

→Keep the source share read-only for 48 hours after cutover. This is your rollback option. A DFS-N redirect back to the source takes minutes. Discovering a critical issue after decommissioning the source takes days to recover from. The 48-hour wait costs nothing and has saved many migrations from becoming major incidents.

→Standard HDD for general user shares — Premium only where performance requirements justify the cost. Premium SSD costs 5–10× more than Standard HDD and uses provisioned billing (you pay for what you allocate, not what you use). It is the right choice for databases, SAP workloads, and VDI profiles. It is not the right choice for general corporate file shares.

Frequently Asked Questions

Can I migrate directly from a NAS appliance (NetApp, Dell EMC, Synology) to Azure Files?

Yes, but the approach depends on the NAS protocol. For NFS-based NAS appliances, Azure Storage Mover supports direct NFS source to Azure Files (NFS) or Blob Storage destinations. For SMB-based NAS, the recommended approach is to stage through a Windows Server: copy from the NAS SMB share to a local Windows Server folder using RoboCopy, then sync from the Windows Server to Azure Files via Azure File Sync. This two-step approach preserves Windows ACLs that a direct NAS-to-Azure copy would lose. For enterprise NAS estates over 100 TiB, Microsoft recommends Komprise — a third-party tool providing deep access-pattern analytics and migration orchestration.

Will my users need to remap their drives after migration?

Not if you use DFS-Namespace (DFS-N). With DFS-N, users map drives to a namespace path (such as \\contoso.com\hr\shared), and DFS-N resolves this to the physical share location. During migration, you update the DFS-N target from the old on-premises UNC path to the new Azure Files UNC path — the user's mapped drive path does not change. Without DFS-N, users must remap to the Azure Files UNC path (\\<account>.file.core.windows.net\<share>), requiring either a help desk-assisted process or a login script change. Implementing DFS-N before the migration is one of the highest-return preparation steps for any organization that does not currently use it.

How long does a typical file share migration take?

The bulk copy duration depends almost entirely on file count, not data volume. As a rough benchmark, RoboCopy with 32 threads over a 10 Gbps network path copies approximately 1 million files per hour for average-sized files (100 KB–10 MB range). A 5 TB share with 1 million files may take 1 hour. The same 5 TB across 50 million small files may take 50+ hours. The cutover window itself is typically 30 minutes to 4 hours depending on the change rate on the source share during the final working period before the window opens.

What is the maximum size of a single Azure file share?

For Standard HDD tier with large file share enabled (required for shares over 5 TiB), the maximum is 100 TiB per share. For Premium SSD tier, the maximum provisioned size is approximately 100 TiB per share. If your source share exceeds 100 TiB, you must split it into multiple Azure file shares before or during migration. Plan this split carefully to maintain logical grouping and avoid breaking application paths that depend on a single share root. For organizations with more than 250 storage accounts per subscription per region, the subscription limit becomes the relevant planning constraint — contact Microsoft support to request a limit increase before migration begins.

Related FAVRITE Articles

• Designing a Secure File Storage Architecture in Azure
• Azure Files vs Azure NetApp Files: Which Should You Choose?
• Azure Blob Storage Explained: Complete Beginner-to-Advanced Guide
• ADLS Gen2 vs Blob Storage: Choosing the Right Storage for AI Workloads