Moving Petabytes Without the Panic: At-Scale Storage Assessments and Migrations to Azure

Hello Folks!

If you have ever been asked to move all our file shares to the cloud ASAP.  You already know that storage migration is one of those projects that looks easy on a slide and gets ugly in reality. In this session at the Microsoft Azure Infra Summit 2026, Anusha Subramanian and Madhuri Narayana Rao (both Product Managers on the Azure Storage team) walked through a guided roadmap for discovering, assessing, and moving large-scale storage to Azure without the homegrown scripts and the late-night reruns.

📺 Watch the session:

Why IT Pros Should Care

In short, this session matters because data migration is consistently underestimated. Anusha put it well: customers focus on migrating applications and workloads, and the big chunk of storage those apps depend on tends to be an afterthought. That afterthought is where projects go sideways. Wrong target tier, wrong tool, wrong sizing, and suddenly you are unwinding an architecture six months in.

Here is what you get out of the new tooling Anusha and Madhuri covered:

  • A first-party, end-to-end path from discovery to assessment to cutover, all inside services you already pay for.
  • File share discovery and assessment now generally available in Azure Migrate, so you stop guessing about your on-premises estate.
  • A fully managed online migration service (Azure Storage Mover) that handles retries, logging, bandwidth, and scheduling for you.
  • An offline option (Azure Data Box) for when your network is the bottleneck and you are staring down hundreds of terabytes.
  • A partner program (the Storage Migration Program) that covers the edge cases first-party tools do not yet cover, with the ISV software cost picked up by Azure.

If you manage file servers, NAS, or large object stores and you have a migration on your roadmap, this is your toolkit.

What This Toolkit Does: Technical Overview

The session framed large-scale storage migration as a guided roadmap with clear phases. You discover what you have on premises, assess how it is used, pick the right cloud target, decide on a migration strategy, execute in phases, and then run post-migration checks before you cut over. The point of the new tooling is to make each of those steps repeatable instead of bespoke.

Three services do most of the heavy lifting:

  • Azure Migrate file share assessment (generally available). Azure Migrate has been Microsoft’s first-party migration platform for a while, but until recently it was very compute-focused (think VMware, Hyper-V, and physical server lift-and-shift). The new capability extends that same discovery appliance to the file shares hosted on those servers. You get share inventory, OS type, protocol, capacity, and basic performance metrics like IOPS and throughput, all flowing back into your Azure Migrate project automatically.
  • Azure Storage Mover. This is the fully managed online migration service. It moves files and folders to Azure without custom scripts or migration infrastructure that you have to babysit. It supports on-premises SMB and NFS sources, cloud-to-cloud moves within Azure (for example, Blob container to Blob container), and AWS S3 to Azure Blob today (with more clouds on the roadmap).
  • Azure Data Box. The offline path. Ruggedized, encrypted, shipped to your datacenter, copied locally, shipped back, and ingested into Azure Storage. The current SKUs include 7 TB disks, 120 TB devices, and 525 TB devices, with 256-bit AES encryption end to end.

How It Works Under the Hood

For Azure Migrate file share assessment, you download (or update) the Migrate appliance and deploy it on your VMware, Hyper-V, or physical server estate. Grant the required permissions, and the appliance starts collecting share metadata and performance telemetry. That data flows back into your Azure Migrate project, and you see file shares appear as first-class entities in the Infrastructure tab right alongside servers. From there you can tag shares, scope them into groups, and generate assessments that map each share to a recommended Azure Files SKU, give you a TCO estimate, surface readiness blockers, and recommend a migration tool. You can export the whole thing to Excel or PowerPoint, which is exactly what you need when finance asks for the business case.

For Storage Mover, the key architectural detail is that the data path is separate from the management path. You deploy a Storage Mover agent close to your source (on premises, in another cloud, or wherever the data lives). The Storage Mover resource in Azure can sit in any region. The agent pulls data from SMB or NFS, then pushes it via REST API directly to the target storage account. Only logs and metadata flow through the service itself. That means migration velocity is governed by the proximity between the agent and the target storage account, not by the region of the management resource. SMB credentials are stored in Azure Key Vault, the agent fetches them at runtime, and one central Storage Mover resource can manage agents deployed globally.

Data Box is conceptually simpler. Order the device through the Azure portal, receive it, copy locally over your LAN at LAN speeds, ship it back, and Azure ingests the data into the storage account you specified. The Data Box family is documented at the Microsoft Learn link in the Resources section below.

Real-World Value

Where does this actually pay off? A few scenarios came up in the session.

  • Lift-and-shift of file servers. Discover with Azure Migrate, assess, get target SKU recommendations and TCO, then move with Storage Mover. Permissions, metadata, and folder structure are preserved during the copy.
  • Cloud-to-cloud (AWS S3 to Azure Blob). The session demoed the multi-cloud connector workflow: deploy a Storage Mover resource, add an AWS connector with an Inventory and Storage Data Management solution, run the AWS CloudFormation template, then create a project, a job definition, and start the job. It is portal-driven from beginning to end.
  • Petabyte-scale offline lift. When you cannot saturate your production WAN for weeks, Data Box gets your seed data to Azure. Then Storage Mover handles the automated delta sync so the cutover window stays small.
  • Recurring incremental sync. Storage Mover now supports recurring schedules (one-time, daily, weekly, or monthly) combined with bandwidth management for peak and off-peak windows. That is useful when data is being collected continuously on premises and you want predictable, throttled transfers.
  • Sovereign cloud. Storage Mover is now available in Azure US Government, so federal and public sector customers can run the same workflow inside their sovereign environment.
  • Specialized scenarios. For source-target pairs the first-party services do not cover yet (say, on-premises NetApp to Azure NetApp Files, which Anusha confirmed in the live Q&A is not yet in Azure Migrate’s scope), the Storage Migration Program brings in partners like Atempo, Data Dynamics, Cirrus Data, and Cirrata. The ISV software cost is covered by Azure.

The honest tradeoff: Storage Mover assumes a reasonable network connection between the agent and the target. If the pipe is tiny and the dataset is huge, the math does not work and you should be ordering Data Box hardware. The session was clear about this, and that kind of “use the right tool” guidance is exactly what saves projects.

Getting Started

If you are kicking off a storage migration, here is the practical sequence.

  1. Stand up (or update) an Azure Migrate project and deploy the Migrate appliance on premises. If you already have one, just update to the latest version so file share discovery lights up automatically.
  2. Let discovery run, then create an Azure Files assessment scoped to the shares you care about. Pick your region, redundancy, performance look-back window, and percentile utilization. Export the results to Excel or PowerPoint and use it to build your business case.
  3. Decide online vs offline based on your dataset size and available bandwidth. Most projects can use Storage Mover. The biggest ones, or the ones with constrained WAN, start with Data Box seed data and then incremental sync with Storage Mover.
  4. For Storage Mover, create the resource, deploy the agent close to your data, register it, define endpoints, create a project and job definition, and start the job. Configure bandwidth schedules so your production traffic does not suffer.
  5. For specialized source-target pairs, reach out via the Storage Migration Program contact (azstoragemigration at microsoft.com) and engage a listed partner.

Resources

Keep Learning at the Summit

Catch the full Microsoft Azure Infra Summit 2026 session playlist here

Cheers!

Pierre Roman

  This article was originally published by Microsoft's ITOps Talk Blog. You can find the original article here.