Azure Storage Mover has spent most of its life doing one thing: dragging file data out of on-premises NAS and SMB servers and landing it in Azure. That is still its day job. But on October 15 Microsoft opened a public preview of something different, a cross-region copy and synchronization mode for Azure Files shares. The Azure Files to Azure Files copy feature lets you copy and sync share data across storage accounts, subscriptions, and Azure regions, all inside one Microsoft Entra tenant.
Why this landed where it did
The gap it fills is narrow but real. Premium SSD file shares do not support geo-redundant storage, so if you run a provisioned v2 share and want a second copy in another region for disaster recovery, you have historically been hand-rolling AzCopy scripts on a scheduler and hoping nobody touched them. Storage Mover gives that job a managed home: scheduled incremental transfers, centralized job definitions, logs, and automatic role assignment.
One detail worth knowing early: the copy target does not have to be the Azure paired region. You can put the secondary copy wherever your failover compute actually lives, which matters when your DR plan involves a specific geography for latency or data residency reasons.
How a copy job works
Each job run takes a share snapshot on the source and copies from that snapshot, so the data you replicate is at least internally consistent. The snapshot is deleted when the run reaches a terminal state, and if cleanup fails you are on the hook for deleting it manually. Transfers are incremental, so repeat runs only move what changed.
Copy modes are Merge and Mirror. Merge drops content into an existing target. Mirror makes the target match the source, which is what you want for a true DR copy. Both modes carry metadata, ACLs and timestamps included, not just file bytes.
Schedules are hourly, daily, weekly, or monthly. Hourly means every 1 to 12 hours, and you can set a schedule end date up to a year out. There is no conflict resolution, so Microsoft’s guidance is to treat the target as read-only between runs. Write to it and your changes can be overwritten or lost on the next pass.
The limits that will bite
Preview restrictions are worth reading twice before you plan a rollout:
- Both source and target must be SSD provisioned v2 SMB shares. NFS is out for now.
- The whole share is the unit of copy. No subdirectory selection.
- Configuration is portal-only. PowerShell and CLI support is not there yet.
- You enable the feature per subscription through a sign-up form, and jobs cannot be created until Microsoft flips it on for you.
- Concurrency is capped at 10 running jobs per subscription per Storage Mover region, with a hard ceiling of 50 per Storage Mover resource even after a limit increase.
Also note the RPO story, because it is the part most likely to disappoint. Storage Mover promises no recovery point objective. Your actual recovery point is whenever the last successful job run finished, not the schedule interval. If you need hourly RPO, schedule hourly runs and accept that a long transfer can push the real recovery point past the top of the hour. This is a scheduled managed copy, not continuous replication.
How it compares
AzCopy stays the right tool for one-off transfers and small datasets; Microsoft’s own migration guidance draws the line around 1 TB and ad-hoc jobs. AzCopy sync runs through the Files REST API and can lose some fidelity on very large jobs, while Storage Mover is rated for full SMB fidelity. What you give up with AzCopy is everything Storage Mover now handles for you: change tracking, retries, schedules, RBAC setup, and a single place to look when a transfer misbehaves.
Azure File Sync is a different product for a different problem. It keeps on-premises Windows servers as a cloud-tiered cache with two-way sync. Storage Mover copies data. If your goal is a secondary cloud copy for DR, File Sync was never the answer.
Getting in
The service itself is free; you pay standard storage, transaction, and networking charges for the data moved. One deployment quirk: Storage Mover resources can only be created in six regions (East US, East US 2, West Central US, West US 3, North Europe, Sweden Central), but the copy targets can live in any Azure public region.
Storage Mover reached general availability in April 2023 and has been quietly widening its scope ever since, adding NFS to Azure Files support in October 2025, agentless SMB migration, AWS FSx sources, and S3-to-Blob cloud-to-cloud transfers. This preview is the same pattern repeated: take the managed transfer plumbing and point it at a pairing customers were previously scripting themselves. If your DR runbook still contains a cron job running AzCopy, this preview is worth testing against it.