Azure Storage Mover now supports agentless migration from on-premises SMB file shares to Azure Files, in public preview. Until now, moving file shares into Azure with Storage Mover meant deploying and managing migration agents on VMs near the source data. The agentless path removes that step entirely: the service reads the SMB share over the network and copies it to an Azure file share, with nothing to install on your servers.
The docs for the preview landed on Microsoft Learn, and they’re concrete enough to plan a real migration against.
What you need before you start
The requirements list is short but has two items that trip people up.
First, private connectivity is mandatory. The service needs a private network path between Azure and the network hosting the source share, over a VPN or ExpressRoute, with TCP 445 reachable end to end. If your shares sit behind firewalls or NSGs, that path has to be opened deliberately. There’s no public-endpoint fallback, which is a sensible default for anything carrying file server credentials.
Second, SMB credentials live in Azure Key Vault, split into two secrets: one for the username, one for the password. The source endpoint’s managed identity needs the Key Vault Secrets User role to read them, and if the role assignment doesn’t happen automatically at runtime, you assign it yourself. Creating the endpoint is a few clicks in the portal or a single CLI command:
az storage-mover endpoint create-for-smb --resource-group <rg> --storage-mover-name <mover> --name OnPremSmbSourceEndpoint --host <smb-server-fqdn-or-ip> --share-name <share>
Beyond that you need a Storage Mover resource, a storage account with a destination Azure file share, and RBAC permissions to create both.
Preview limits
Read these before pointing the tool at production shares:
- Each migration job handles up to 500 million objects. Bigger shares get split across multiple jobs.
- Up to 10 migration jobs can run concurrently per subscription.
- During preview, run only one job at a time per target file share.
- SMB 1.x sources aren’t supported. SMB 2.x or 3.x only, which shouldn’t hurt anyone who has already patched past the 2017 ransomware era.
- Data is copied, not moved. Source data stays put until you decommission it.
That last point is actually the correct design for a migration tool. Copy first, validate, then cut over and retire the old server on your schedule. The docs describe the full sequence: prepare, configure endpoints, run the job, validate the data, complete cutover.
How the migration actually runs
The workflow splits cleanly into endpoint setup and job execution. You create a source endpoint pointing at your SMB server (host name or private IP, plus the share name without leading backslashes), a destination endpoint for the Azure file share, then define a migration job that ties them together and run it. Job runs log copy progress, and the docs cover monitoring copy and job run logs through Azure Monitor, so you can watch throughput and error counts without tailing anything on a server.
Validation is an explicit step rather than an assumption. The intended sequence ends with validating the copied data before cutover, which is where you check file counts and spot-check content before pointing users at the new share. Skipping that step to save an hour is how migrations turn into restores.
When to use this versus the alternatives
Storage Mover’s agentless mode fits the one-time migration case: a NAS or Windows file server that’s moving to Azure Files and not coming back. No agent VMs to size, deploy, patch, or clean up afterwards, which removes most of the operational overhead of the classic path.
It’s not a replacement for Azure File Sync. If you want to keep files on-premises with a cloud cache, tiering cold data to Azure, File Sync remains the right tool. And for very large or long-running migrations where you want scheduled incremental copies from multiple sites, the agent-based approach still has a role. Agentless mode simply covers the most common shape of the job, lift the share and move on, with the least machinery.
If a job fails
The troubleshooting checklist in the docs covers the usual suspects in order: validate Key Vault secret access for the source endpoint identity and storage data access for the target, verify the private connection and TCP 445 reachability across VPN, ExpressRoute, NSGs, and firewalls, confirm the host and share name values, and read the job definition output before retrying. Most preview-era failures will be network path or permissions issues rather than the copy itself.
For teams sitting on aging Windows file servers or NAS boxes, this is the lowest-friction path to Azure Files yet. The private connectivity requirement is the main planning item, and it’s better to know that on day one than during the migration window.