Migrate to SMB Azure file shares

This article covers the basic aspects of a migration to SMB Azure file shares and contains a table of migration guides. These guides help you move your files into Azure file shares. The guides are organized based on where your data is and what deployment model (cloud-only or hybrid) you're moving to.

Applies to

File share type	SMB	NFS
Standard file shares (GPv2), LRS/ZRS
Standard file shares (GPv2), GRS/GZRS
Premium file shares (FileStorage), LRS/ZRS

Migration basics

The goal is to move the data from existing file share locations to Azure. In Azure, you'll store your data in native Azure file shares you can use without a need for a Windows Server. This migration needs to be done in a way that guarantees the integrity of the production data and availability during the migration. The latter requires keeping downtime to a minimum, so that it can fit into or only slightly exceed regular maintenance windows.

Azure offers different types of cloud storage. A fundamental aspect of file migrations to Azure is determining which Azure storage option is right for your data.

Azure file shares are suitable for general-purpose file data. This data includes anything you use an on-premises SMB share for. With Azure File Sync, you can cache the contents of several Azure file shares on servers running Windows Server on-premises.

For an app that currently runs on an on-premises server, storing files in an Azure file share might be a good choice. You can move the app to Azure and use Azure file shares as shared storage. You can also consider Azure Disks for this scenario.

Some cloud apps don't depend on SMB or on machine-local data access or shared access. For those apps, object storage like Azure blobs is often the best choice.

Preserving file fidelity

A key aspect in any file share migration is capturing as much file fidelity as possible when moving your files from their current storage location to Azure.

Here are the two basic components of a file:

• Data stream: The data stream of a file stores the file content.
• File metadata: Unlike object storage in Azure blobs, an Azure file share can natively store supported file metadata. General-purpose file data traditionally depends on file metadata. App data might not. The file metadata has these subcomponents:
  • File attributes like read-only
  • File permissions, which are often referred to as NTFS permissions or file and folder ACLs
  • Timestamps, most notably the creation and last-modified timestamps
  • An alternative data stream, which is a space to store larger amounts of nonstandard properties. This alternative data stream can't be stored on a file in an Azure file share. It's preserved on-premises when Azure File Sync is used.

File fidelity in a migration can be defined as the ability to:

• Store all applicable file information on the source.
• Transfer files with the migration tool.
• Store files in the target storage of the migration.
  The target for migration guides in this article is one or more Azure file shares. Consider this list of features that SMB Azure file shares don't support.

To ensure your migration proceeds smoothly, identify the best copy tool for your needs and match a storage target to your source.

Users that leverage Active Directory Domain Services (AD DS) as their on-premises domain controller can natively access an Azure file share. So can users of Microsoft Entra Domain Services. Each uses their current identity to get access based on share permissions and on file and folder ACLs. This behavior is similar to a user connecting to an on-premises file share.

Learn more about identity-based authentication for Azure Files over SMB.

Supported metadata

The following table lists supported metadata for Azure Files.

Discovery phase

The first phase of a migration is the discovery phase, in which you determine all the existing SMB file shares that need to be migrated, including their size, number, and any dependencies. This can be a difficult and time consuming task, especially for organizations with large, distributed environments. For customers with more than 100 TiB of file data, we recommend using Komprise, a third-party tool that can help you discover and analyze your file shares. For more information, see Komprise File Migration.

Keep in mind that your existing SMB file shares might not be limited to on-premises Windows Servers. They could be on Linux servers, in the cloud, or on external NAS devices.

Assessment phase

After discovery comes the assessment phase, which involves understanding available options for file storage, deploying the Azure resources you'll need, and preparing to use Azure file shares.

Deploy Azure storage resources

As part of the assessment phase, you'll provision the Azure storage accounts and the SMB Azure file shares within them.

An Azure file share is deployed in the cloud in an Azure storage account. For standard file shares, that arrangement makes the storage account a scale target for performance numbers like IOPS and throughput. If you place multiple file shares in a single storage account, you're creating a shared pool of IOPS and throughput for these shares.

As a general rule, you can pool multiple Azure file shares into the same storage account if you have archival shares or you expect low day-to-day activity in them. However, if you have highly active shares (shares used by many users and/or applications), you'll want to deploy storage accounts with one file share each. These limitations don't apply to FileStorage (premium) storage accounts, where performance is explicitly provisioned and guaranteed for each share.

For more information about performance and cost, see Understand performance and Understand billing.

Another consideration when you're deploying a storage account is redundancy. See Azure Files redundancy.

If you've made a list of your shares, you should map each share to the storage account it will be created in.

The names of your resources are also important. For example, if you group multiple shares for the HR department into an Azure storage account, you should name the storage account appropriately. Similarly, when you name your Azure file shares, you should use names similar to the ones used for their on-premises counterparts.

Now deploy the appropriate number of Azure storage accounts with the appropriate number of Azure file shares in them, following the instructions in Create an SMB file share. In most cases, you'll want to make sure the region of each of your storage accounts is the same.

Prepare to use Azure file shares

You'll also need to decide how your servers and users in Azure and outside of Azure will be enabled to utilize your Azure file shares. The most critical decisions are:

• Networking: Enable your networks to route SMB traffic. See Networking overview for Azure file shares for more information. You can use public endpoints, private endpoints, or a combination of both.
• Authentication: Configure the Azure storage account for identity-based authentication and join the storage account to your AD domain. This will allow your apps and users to use their AD identity for authentication.
• Authorization: Share-level ACLs for each Azure file share will allow AD users and groups to access a given share. Within an Azure file share, native NTFS ACLs will take over. Authorization based on file and folder ACLs then works like it does for on-premises SMB shares.
• Business continuity: Integrating Azure file shares into an existing environment often entails preserving existing share addresses. If you aren't already using DFS-Namespaces, consider establishing that in your environment. You'll be able to keep share addresses your users and scripts use, unchanged. DFS-N provides a namespace routing service for SMB by redirecting clients to Azure file shares.

Migration guides

Selecting the right tools for your migration scenario is crucial. The following table lists suggested tool combinations for migrating to SMB Azure file shares.

How to use the table:

1. Locate the row for the source system your files are currently stored on.

2. Choose one of these targets:

   • Hybrid deployment: Use Azure File Sync to cache the content of Azure file shares on-premises and tier less frequently used files to the cloud.
   • Cloud-only deployment: Azure file shares in the cloud, with no on-premises caching.

   Select the target column that matches your choice.

3. Within the intersection of source and target, a table cell lists available migration scenarios. Select one to view the migration guide.

A scenario without a link doesn't yet have a published migration guide. Check this table occasionally for updates.

File-copy tools

To select the right tool for your migration scenario, consider these fundamental questions:

• Does the tool support the source and target locations for your file copy?

• Does the tool support your network path or available protocols (such as REST or SMB) between the source and target storage locations?

• Does the tool preserve the necessary file fidelity supported by your source and target locations?

  In some cases, your target storage doesn't support the same fidelity as your source. If the target storage is sufficient for your needs, the tool must match only the target's file-fidelity capabilities.

• Does the tool have features that let it fit into your migration strategy?

  For example, consider whether the tool lets you minimize your downtime.

  When a tool supports an option to mirror a source to a target, you can often run it multiple times on the same source and target while the source stays accessible.

  The first time you run the tool, it copies the bulk of the data. This initial run might last a while. It often lasts longer than you want for taking the data source offline for your business processes.

  By mirroring a source to a target (as with robocopy /MIR), you can run the tool again on that same source and target. This second run is much faster because it needs to transport only source changes that happened after the previous run. Rerunning a copy tool this way can reduce downtime significantly.

The following table classifies Microsoft tools and their current suitability for SMB Azure file shares:

Recommended	Tool	Support for Azure file shares	Preservation of file fidelity
	Azure Storage Mover	Supported.	Full fidelity.*
	Azure Data Box	Supported.	Full fidelity.*
	RoboCopy	Supported. Azure file shares can be mounted as network drives.	Full fidelity.*
	Azure File Sync	Natively integrated into Azure file shares.	Full fidelity.*
	Azure Storage Migration Program	Supported.	Full fidelity.*
	Storage Migration Service	Indirectly supported. Azure file shares can be mounted as network drives on SMS target servers.	Full fidelity.*
	Data Box (including the data copy service to load files onto the device)	Supported. (Data Box Disks doesn't support large file shares)	Data Box and Data Box Heavy fully support metadata. Data Box Disks does not preserve file metadata.
	AzCopy latest version	Supported but not fully recommended.	AzCopy sync supports up to 10 million files per AzCopy job and some file fidelity might be lost as AzCopy uses the Azure Files REST APIs for copying content to your Azure Files share. Learn how to use AzCopy with Azure file shares
	Azure Storage Explorer latest version	Supported but not recommended.	Loses most file fidelity, like ACLs. Supports timestamps.
	Azure Data Factory	Supported.	Doesn't copy metadata.

* Full fidelity: meets or exceeds Azure file share capabilities.

Migration helper tools

This section describes tools that help you plan and run migrations.

Azure Storage Mover

Azure Storage Mover is a relatively new, fully managed migration service that enables you to migrate files and folders to SMB Azure file shares with the same level of file fidelity as the underlying Azure file share. Folder structure and metadata values such as file and folder timestamps, ACLs, and file attributes are maintained. To learn how to use Azure Storage Mover with Azure Files, see Migrate to SMB Azure file shares using Azure Storage Mover.

RoboCopy

Included in Windows, RoboCopy is very useful for SMB file migrations. The RoboCopy documentation is a helpful resource for this tool's many options.

Azure Storage Migration Program

Understanding your data is the first step in selecting the appropriate Azure storage service and migration strategy. Azure Storage Migration Program provides different tools that can analyze your data and storage infrastructure to provide valuable insights. These tools can help you understand the size and type of data, file and folder count, and access patterns. They provide a consolidated view of your data and enable the creation of various customized reports.

This information can help:

• Identify duplicate and redundant data sets
• Identify colder data that can be moved to less expensive storage

To learn more, see Comparison Matrix for Azure Storage Migration Program participants.

TreeSize from JAM Software GmbH

Azure File Sync scales primarily with the number of items (files and folders) and not with the total storage amount. The TreeSize tool lets you determine the number of items on your Windows Server volumes.

You can use the tool to create a perspective before an Azure File Sync deployment. You can also use it when cloud tiering is engaged after deployment. In that scenario, you see the number of items and which directories use your server cache the most.

The tested version of the tool is version 4.4.1. It's compatible with cloud-tiered files. The tool won't cause recall of tiered files during its normal operation.

See also

• Azure file share overview
• Planning for an Azure File Sync deployment
• Azure File Sync: Cloud tiering