Enhanced data protection for Azure Files
Organizations rely on Azure Files for business-critical workloads such as VDI, SAP, and general-purpose file shares that hold their enterprise data. For these workloads, backup and disaster recovery are day-one requirements. Customers need a simple, scalable way to recover from an accidental change to production data, a regional disruption or a ransomware attack, both within a region and across regions. Today, we’re announcing new capabilities, in Public Preview, that expand business continuity and disaster recovery (BCDR) capabilities for Azure Files. They help customers recover from operational issues, strengthen regional resilience and protect critical file data from cyber threats: Vaulted backup for NFS shares: Protect NFS file shares with isolated recovery points through Azure Backup for protected, trusted recovery from cyber incidents. Revert snapshot: Roll an existing file share back to a known-good point in time, in place, without changing the endpoint or mount path for fast. This gives you fast recovery from operational issues. Azure Files-to-Azure Files copy and sync with Storage Mover: Use Azure Storage Mover to maintain a secondary copy of your SMB file share data in the Azure region of your choice, with scheduled incremental transfers to keep it current for disaster recovery. Together, these capabilities let customers build Azure Files resiliency in layers: roll back quickly, maintain secondary copies and recover from protected backups. Vaulted backup for Azure Files NFS shares Cyber recovery introduces another dimension to resiliency: When ransomware or another security incident compromises the production environment, organizations need protected recovery points and may need to validate recovered data before reconnecting it to production. Azure Files already supports vaulted backup for SMB shares. With this preview, that protection extends to NFS shares. Vaulted backup for Azure Files NFS shares adds an additional protection layer through Azure Backup. Recovery points are maintained separately from the production file share and managed through backup policies designed to support long-term retention, immutability, and cyber recovery objectives. Vaulted backup helps customers protect critical file data when: Recovery points need protection separate from production: Maintain protected recovery points separately from the production file share, adding another layer of protection for critical file data. Backup strategies require immutability: Support immutable backup strategies as part of the broader approach to protecting recovery points and meeting cyber recovery objectives. Data must be retained long term: Manage recovery points through backup policies designed to support long-term retention and meet the organization’s retention requirements. Ransomware resilience is a priority: Strengthen resilience with protected recovery points for recovery when ransomware or another security incident compromises the production environment. To participate in the Vaulted backup for NFS shares preview, sign up here. Roll back quickly with Revert snapshot Operational mistakes are among the most common reasons applications need data recovery. A deployment can modify the wrong files, a configuration rollout can affect an entire namespace, or an administrator can accidentally overwrite critical content. Azure Files Revert Snapshot initially provides in-place recovery for data and applications hosted on SMB file shares, with NFS support coming next. Customers can select a point-in-time snapshot and restore the existing file share to that state while applications continue using the same file share, endpoint, and mount path. Common scenarios include: Failed application deployments: Roll back after a deployment modifies the wrong files. Incorrect configuration changes: Restore the share after a configuration rollout affects the namespace. Accidental mass modifications: Return to a point-in-time snapshot after unintended changes or overwrites. Development and test environment resets: Reset the file share to a selected snapshot. Azure Backup offers an integrated experience in the Azure portal restore blade to revert snapshots it manages. To participate in the Revert Snapshot preview, sign up here. Azure Files-to-Azure Files copy and sync with Storage Mover From disaster readiness and regional expansion to workload relocation and storage consolidation, customers need a simple, scalable way to copy and sync file data across storage accounts and Azure regions. Common use cases include Virtual Desktop Infrastructure (VDI) users maintaining secondary copies of FSLogix profiles and user data to support regional continuity, SAP and enterprise applications moving application data during regional expansion, organizations consolidating distributed content to simplify administration, and AI workflows placing datasets closer to AI and analytics compute to support distributed development and processing. Azure Files-to-Azure Files copy and synchronization with Azure Storage Mover gives customers a fully managed Azure service to copy data between SMB file shares across storage accounts, regions, and subscriptions (within the same tenant). They can also schedule incremental transfers to keep destination shares up to date. Customers can: Maintain secondary copies for business-critical workloads to an Azure region of choice. Schedule incremental synchronization of application data, user profiles, and shared content to another Azure region, helping organizations strengthen business-continuity and recovery planning. Copy or migrate file share data between regions: Copy data for regional expansion, datacenter transitions, or workload relocation. Consolidate file shares: Bring data together across storage accounts and regions to simplify management. Operate at scale with less overhead: Centrally schedule, monitor, and audit transfers instead of maintaining scripts or copy infrastructure. Azure Storage Mover reduces operational overhead with centralized scheduling, monitoring, auditing, metadata preservation, and orchestration for recurring file transfers. Figure: Storage Mover (West Central US) copies File share 1 in East US to File share 2 in West Central US. Preview support for Azure Files to Azure Files data copy is now available for SMB shares, with NFS support coming soon. To participate in the preview program, sign up here. Together, these capabilities help customers protect critical file data, recover quickly from operational issues and strengthen continuity across regions. Vaulted backup for NFS shares, Revert Snapshot and Azure Files copy and synchronization with Storage Mover provide complementary layers for a more resilient BCDR strategy. Learn more About Azure Files backup - Azure Backup | Microsoft Learn Use Azure Files Share Snapshots | Microsoft Learn Get started with Azure Files-to-Azure Files data copy in Azure Storage Mover (preview) | Microsoft Learn For questions or feedback, please reach out to the team at azurefiles@microsoft.com.
Discover and assess on-premises Network Attached Storage (NAS) shares using Azure Migrate
Network-attached storage (NAS) holds much of an enterprise’s data; home directories, project shares, media libraries, application data, and analytics datasets, often spanning tens or hundreds of terabytes across protocols and administrative boundaries. Moving this estate to Azure starts not with copying data, but with understanding what you have, where each share should go, and what it will cost. Building on the file share assessment capability we announced in May, today we’re announcing the public preview of NAS share discovery and assessment in Azure Migrate. It connects directly to Dell PowerScale/Isilon and NetApp ONTAP clusters, inventories every SMB, NFS, and S3 share, and assesses each against Azure Files, Azure Blob Storage, and Azure NetApp Files—providing readiness, right-sized configurations, cost estimates, and migration tooling guidance. Your NAS assets now join servers, applications, and databases in the same Azure Migrate project, inventory, and business case. Why does this matter NAS planning has historically been done with spreadsheets, vendor-specific tools, and a lot of manual reconciliation. Storage ends up being assessed separately from the servers and applications that depend on it, which makes it hard to sequence a migration or defend a budget. This capability is designed to help you: Replace manual inventory with automated discoveries across Dell and NetApp platforms, so you can go from "we think we have a few thousand shares" to a verified, per-share inventory. Effectively plan your NAS shares alongside everything else. NAS clusters and their shares appear in the same Azure Migrate inventory as your VMware, Hyper-V, and physical servers, databases, and web apps. Make your informed decision before you migrate. Each share gets a readiness verdict, a recommended Azure service and SKU, and a monthly cost estimate. What's available in public preview Add Dell or NetApp NAS clusters: Discover Dell PowerScale / Isilon (OneFS) and NetApp ONTAP AFF / FAS clusters, and inventory every SMB, NFS, and S3 shares they host — including shares exposed through more than one protocol. Explore and review on-prem shares and workloads: Review cluster and share details in the portal: model, nodes, total and used capacity, protocol versions, volume, and estimated size. Group and filter shares by tag — by business unit, cost center, or application — so related workloads can be planned together. Suitable Azure storage targets: Assess each share against Azure Files, Azure Blob Storage, and Azure NetApp Files, with control over target region, sizing criteria, comfort factor, redundancy, media type, access frequency, and workload type. Alternative migration paths: Compare various migration paths side by side — a recommended mixed path that sends each share to its best-fit service, alongside single-service alternatives — with readiness, monthly cost, and estimated emissions for each. Business case: Build a business case for a NAS-only estate or for a mixed estate of VMs and NAS, comparing a modernization approach against lift-and-shift. End-to-end experience The experience follows the same guided workflow you already know from Azure Migrate. 1. Enable the feature Install the latest Azure Migrate appliance or turn on auto-update, so your existing appliance picks up the new capability. Unlike file shares hosted on Windows and Linux servers, NAS clusters need to be added explicitly: in the appliance configuration manager, add a credential of source type NAS Server, then add a discovery source of type NAS Server with your cluster's FQDN and port. The account needs read-only permission at cluster level — Azure Migrate only reads metadata and never writes to your storage. 2. Discover your NAS estate Create an Azure Migrate project, deploy the appliance on VMware, Hyper-V, or a physical server, and point it at your clusters. The appliance connects to each cluster's management endpoint and collects system and share metadata, vendor, product and model, operating system version, cluster nodes, total and used capacity, share and bucket paths, protocols and protocol versions; followed by performance signals such as IOPS and throughput. Discovered clusters and their shares appear as first-class inventory objects, listed alongside the Windows and Linux file servers the appliance already finds. Filter by type, search, tag, and export the inventory at whatever scale your estate demands. Discovery runs a daily cycle and updates existing items as new metadata arrives, so the picture improves over time rather than being a one-shot snapshot. 3. Create an assessment Select the shares you care about — individually, by tag, or a whole cluster at a time — and create an assessment. The share is the unit of assessment, so every SMB, NFS, or S3 share receives its own verdict rather than inheriting one from its host. Assessment settings let you shape the recommendation to your environment: choose the target Azure region, pick as-is or performance-based sizing, set a comfort factor for headroom, and configure redundancy, Azure Files media preferences, and Azure Blob access frequency. A workload type setting from general purpose file shares through to AI/ML and mission-critical, helps Azure Migrate recommend an appropriate performance level. Azure NetApp Files is added to the evaluation automatically when the source share is detected on NetApp NAS. Settings can be changed, and the assessment recalculated at any time. 4. Review results and build the business case Results are organized as migration paths. The recommended path routes each share to its best-fit Azure service and is shown next to single-service alternatives, so you can compare readiness and cost on the same basis. Key insights include: Readiness for every share — Ready, Ready with conditions, or Not ready — with the warnings that need attention before you move. A recommended Azure configuration per share. For example, a multi-protocol NetApp volume is recommended for Azure NetApp Files, while a general-purpose SMB share is recommended for Azure Files with a specific media type and redundancy. Provisioned size, IOPS, and throughput behind the recommendation, plus the reasoning Azure Migrate used to select the SKU and access tier. Monthly cost estimates per share and per path, an on-premises versus Azure TCO comparison, and estimated carbon savings. Next, you can generate a wave plan to sequence the migration or build a business case that helps you with cost modernizing Azure storage services. Assessment results showing the recommended path, source-to-target mappings, estimated Azure TCO, and carbon savings. Note: All screenshots in this post are from a sample environment. Cluster and share names, capacity values, readiness distributions, cost and TCO estimates, and emissions figures are illustrative and shown for reference and indicative purposes only. They are not a price quote. Your own results depend on your discovered environment, the assessment settings you choose, your target Azure region, and the pricing and offers that apply to your subscription. Prepare for migration with the right tool Assessment tells you where each share should go; Azure Migrate then points you at the tool to get it there. Azure Storage Mover is the recommended path for moving shares to Azure Files and Azure Blob Storage. For ONTAP volumes heading to Azure NetApp Files, the Azure NetApp Files migration assistant is recommended, and Azure File Sync remains the option for active sync and hybrid scenarios with Windows file servers. To learn more about our recommendations for unstructured data migration, visit https://aka.ms/migratemydata. Get started Update your Azure Migrate appliance, add your first NAS cluster, and let a discovery cycle run. Within a few hours you'll start to see a per-share picture of your NAS estate; you can then create an assessment to view the right target service to migrate to Azure. Learn more in our documentation. Connect and discover your NAS appliance Review discovered NAS resources Create a fileshare assessment of NAS shares Review NAS File share assessment recommendations Write to us at azurestoragemigrations@microsoft.com with questions or feedback, or to suggest additional NAS systems you’d like this capability to support. We look forward to hearing from you!Simplify On-prem File share Migration to Azure: Discover & assess suitability using Azure Migrate
UPDATE as of 20th May 2026: We are happy to announce that this capability is now GA worldwide. Migrating on‑premises file servers to the cloud is a complex infrastructure transformation—not just a data move. Many organizations lack the visibility needed to decide whether to rehost or modernize file shares spread across Windows and Linux servers. Azure Migrate now extends its discovery and assessment capabilities to SMB and NFS file shares, enabling a data‑driven approach to modernizing on‑premises file workloads with Azure Files, or alternatively rehosting to deployment within an Azure VM. We are pleased to introduce the public preview of Azure Migrate’s new comprehensive discovery and assessment of on-premises SMB and NFS file shares for migration to Azure Files. This enhancement simplifies the migration process by integrating discovery and evaluation tools for SMB and NFS shares across both Windows and Linux platforms. Users can efficiently identify file shares, analyze their compatibility, and compare cost benefits for transitioning to Azure Files, all within an intuitive and streamlined interface. Why does this matter File shares remain a foundational service for most workloads - supporting applications, analytics, user home directories, and shared content. Planning such a vast amount of data for migration can be slow, manual, and fragmented. This new Azure Migrate capability is designed to help with: Reduce migration planning from months to weeks through automated discovery and assessment of SMB and NFS file shares. Perform holistic migration planning of your data and storage alongside servers, applications and data bases from within Azure Migrate experience. Modernize confidently to Azure Files with tailored SKU recommendations, readiness assessments, and comprehensive cost insights, enabling you to build a clear business case by comparing ongoing on-premises and Azure Files costs. What’s available in public preview Discover and view details of all on-premises SMB, NFS shares hosted on Windows and Linux servers Group, tag, filter shares by Production, non-production, project, business group for better planning. Create and review assessment for each share, its target Azure Files SKU based on region, redundancy, pricing options and media type. Generate a business case for selected group of shares running on Azure Files against on-premises cost. How do you get this feature? Install the latest Azure Migrate appliance, or enable the auto update feature for the appliance will receive this new capability. All existing SMB, NFS file shares will be reported in the Azure Migrate portal along with their Windows and Linux hosts. You do not need to perform any additional steps to discover the shares. End-to-end experience The experience is fully integrated into Azure Migrate and follows a familiar, guided workflow as below. 1. Discover on‑premises file servers and file shares You can start by creating an Azure Migrate project in the Azure portal and enabling discovery using the Azure Migrate appliance. The appliance can be deployed in connected or disconnected mode and runs on VMware, Hyper‑V, or physical servers. Once deployed, the appliance automatically discovers file servers and the file shares they host, including: Operating system (Windows or Linux) File share protocol (SMB or NFS) Associated volumes Estimated capacity Basic performance metrics such as IOPS and throughput (when performance collection is enabled) Discovered file shares appear directly in Azure Migrate inventory views, where they are surfaced as inventory items under respective Windows or Linux systems. This makes it easy to filter, tag, and review all shares at scale. 2. Build a business case The next step is to create a business case. This offers a clear comparison of on-premises costs versus Azure, highlights long-term savings and operational benefits, and justifies modernizing to Azure Files rather than rehosting file servers on virtual machines. This allows IT leaders to make data-driven decisions confidently. 3. Create and review an Azure Files assessment Once you have finalised your business case and decided to move to Azure Files, you can initiate an Azure Files assessment right from the Azure Migrate platform. The assessments are adaptable, allowing you to focus solely on file shares, include their parent servers, or even expand to scenarios that cover VMs, databases, and file shares—reflecting real-world planning needs. Each assessment reviews readiness and provides recommendations based on inventory and performance metrics gathered. Furthermore, you can tailor assessment settings, including selecting a target Azure region, pricing and savings preferences, media type, redundancy options, and choosing either performance-based or as-is sizing. The assessment offers a detailed overview of migration readiness and economic factors, supporting well-informed decisions for subsequent actions. Key insights include: Readiness states for each file share (Ready, Ready with conditions, or Not ready) Recommended Azure Files SKU based on performance and suitability. For example, Azure Files provisioned v2 premium SSD for a NFS 4.1 share as target. Monthly cost estimates for the recommended SKU. On‑premises vs Azure TCO comparison, helping customers understand long‑term cost implications Azure Migrate also identifies potential warnings and provides necessary remediation guidance. For example, when a redundancy type is not available in an Azure region, it is flagged as ready with conditions and recommend choosing an alternative redundancy type and fallback to next available option. Prepare for migration with appropriate tools Once you are ready to migrate, Azure Migrate also highlights recommended migration tools as part of the assessment. Azure Storage Mover is the default recommended path for file share migrations—providing a first party, managed service to move data efficiently to Azure Files. To learn more about Microsoft’s recommendations to unstructured data migration using other tools, please visit: https://aka.ms/migratemydata. Learn more about creation of assessment and review assessment to get started with understanding your on-premises file shares estate today. Write to us at migratemydata@microsoft.com for any questions or feedback - we look forward to hearing from you!Agentic Migrations and Modernization: How the Azure Migrate Agent Keeps Your Intent Alive End to End
Hello Folks! If you have ever tried to move a few hundred VMs, a pile of databases, and a couple of web apps from on-prem to Azure, you already know the hard part is not the tooling. The hard part is keeping context, intent, and momentum alive across weeks of planning, hand-offs, and decisions. In session MAIS15 at the Microsoft Azure Infra Summit 2026, Ankur Gupta (Senior Product Manager on the Azure Migrate team) walked us through the new Azure Migrate agent, an AI layer that sits on top of Azure Migrate and carries your intent from “I have an idea” all the way to “the landing zone is deployed.” Why IT Pros Should Care Ankur opened with a line that stuck with me. Infrastructure complexity has far outpaced human scale. We have MySQL here, PostgreSQL there, web apps, storage devices, networking gear, multiple dashboards, multiple alerts, and we are all expected to move faster than ever, with fewer mistakes. In short, migrations rarely fail because someone picked the wrong tool. They fail because the system between the stages breaks. Here is why the agentic approach matters for the folks in the trenches: It keeps context across the entire lifecycle, so the intent you set on day one is still the intent at execution. It guides you when you are stuck, instead of leaving you to figure out which of three discovery methods is the right one. It compresses tasks that used to take days of analysis (think side-by-side business cases) into a few hours. It connects IT ops, architects, and developers through a single thread of information, including a clean handoff to GitHub Copilot for code work. It builds on the Azure Migrate portal you already know, so nothing you have learned goes to waste. That last point is important. The portal does not go away. The agent is a layer on top. You can still do everything you do today. What the Azure Migrate Agent Is, technical overview Azure Migrate has always been Microsoft’s hub for discover, assess, and migrate. What Ankur showed at MAIS15 is the next evolution. Azure Migrate is becoming a migration control plane that spans the whole lifecycle (Decide, Plan, Execute), and the Azure Migrate agent is the conversational, guidance-oriented layer that ties it all together. In Ankur’s words, the agent is educational and guidance-oriented. You ask one natural-language question, like “how should I plan moving my VMware workloads to Azure,” and you get the next steps you actually need to take. Behind the scenes, the agent is doing three things very well. It maintains state across the entire lifecycle. Preferences you set early stay with you. It carries context across discovery, plan, and execute. You can jump around, repeat steps, change your mind, and the agent remembers what your goal was. It recommends the right next move based on what it has learned about your intent. This is the heart of the “agentic” part. The agent is not a chatbot grafted onto a portal. It is a stateful workflow runner that remembers you. How It Works, under the hood The session walked through a full VMware-to-Azure scenario, and the flow is worth seeing because it shows how the pieces snap together. The agent supports three discovery methods today: appliance-based discovery, RV Tools, and the new Azure Migrate collector. The collector is the new lightweight option. It ships as a set of PowerShell scripts you run on a machine that can reach your vCenter, it produces a zip file, and you upload that zip to your Azure Migrate project. No appliance to deploy, no inbound network plumbing. Once the inventory lands, the agent reads it. Ankur asked for a summary and got a card showing 207 VMs, 177 SQL databases, one PostgreSQL instance, and some web apps. He then asked for all servers with an out-of-support OS, got a list of around 50, and tagged them right inside the conversation so he could refer back to them later. Next came the business case. Ankur asked the agent to generate one based on a modernize preference. A few minutes later, he had Azure cost, on-prem cost, and projected savings. Then he asked for a second business case for lift and shift, and a side-by-side comparison. The agent ran it, showed that the on-prem cost in the lift-and-shift comparison was higher and that lift-and-shift TCO savings were actually higher in that specific scenario, and gave him the data points he needed to bring the decision to leadership. From there, Ankur moved to application assessment, this time back in the portal. He created an assessment for two apps (Airsonic and Parts Unlimited), let the high-confidence plan run, and got a modernize recommendation with 100% readiness and a target cost of about $580 per month, plus an emissions estimate of 32 kgs of CO2. App Service for the web tier, Azure Database for PostgreSQL for the data tier. Both were flagged “ready with conditions,” with clickable links into why. Then came one of my favorite parts. Ankur connected GitHub for a Copilot Assessment, which adds code-level insights on top of the infrastructure readiness assessment. The system recalculated, and the migration effort estimate sharpened up. Finally, the agent built a wave plan from the assessment, then generated a platform landing zone aligned with Azure best practices. He could ask the agent about chosen defaults, request changes to the deployment mechanism, swap in a third-party firewall, or apply naming conventions. The agent produced a downloadable Infrastructure-as-Code template and handed it to a cloud architect, who refined it in their IDE using GitHub Copilot. That last handoff is the bridge between Azure Migrate’s planning world and the developer world. Real-World Value (use cases, ROI, scenarios) So where does this actually pay off? A few scenarios stood out. Pitching the business case to leadership. Ankur framed the demo around “I need to pitch a migration proposal to the planning committee.” Generating modernize, lift-and-shift, and Azure VMware Solution business cases used to be days of spreadsheet work. With the agent, it is hours. Cleaning up legacy debt. Tagging out-of-support servers in one conversational step lets you plan upgrades without exporting CSVs and slicing them by hand. Mixed estates with web apps and databases. The agent surfaces App Service and Azure Database for PostgreSQL targets, gives SKU recommendations, and flags the warnings worth investigating. Closing the IT-to-developer gap. The GitHub Copilot Assessment and the IaC handoff to the IDE means developers and architects work from the same context. Reducing intent drift on long migrations. Multi-week journeys lose their original intent. The agent remembers. In short, the ROI here is measured in calendar time, not just dollars. And honestly, in fewer late-night calls when something goes sideways because nobody remembered the original decision. Tradeoffs worth flagging: the agentic capabilities are landing in preview, and outputs are advisory. You still need human review, testing, and governance on every recommendation. That is by design. Getting Started (concrete first steps) Here is a practical onramp. Stand up an Azure Migrate project in the Azure portal if you do not already have one. Pick a discovery method that fits your environment. If you cannot deploy an appliance, try the new collector. Download the PowerShell scripts, run them from a host that can reach vCenter, and upload the zip. Bring in the Azure Migrate agent from inside the portal and ask it to summarize your discovered inventory. Generate at least two business cases (modernize and lift-and-shift). Compare them. Run an application assessment on a small, representative set of apps. Connect GitHub and add a Copilot Assessment for code-level insight. Ask the agent to build a wave plan and a platform landing zone template, then push the IaC to your repo for the architects. Start small, build the muscle, and scale out. Resources Azure Migrate documentation (Microsoft Learn) About Azure Migrate, including the Azure Copilot migration agent (Microsoft Learn) GitHub Copilot modernization overview (Microsoft Learn) GitHub Copilot modernization agent overview (Microsoft Learn) GitHub Copilot modernization documentation (Microsoft Learn) Assess and migrate a .NET project with GitHub Copilot modernization (Microsoft Learn) GitHub Copilot modernization overview for .NET (Microsoft Learn) Keep Learning at the Summit Catch the full Microsoft Azure Infra Summit 2026 session playlist here Microsoft Azure Infra Summit 2026 Cheers! Pierre RomanReplicate workload from VMWare to Azure using Azure Site Recovery(ASR)
Hello, I am working on a project to replicate worklooad hosted on a VMWare to Azure Site Recovery for disaster recovery purpose. Current Environment: More than 80 VMs hosted on VMWare managed by VMWare Sphere running both Linux and Windows OS.. Databases: Oracle DB, Microsoft SQL and MySQL Requirements: seamless failover and disaster recovery requirements. scalable setup No down-time integrate identity and access mgt. integration with Microsoft Entra ID. RTO < 2 hrs and RPO > 15 minutes Backup: critical database backup every 3 hours App servers: Daily*incremental) and weekly (full) Transaction Logs: every 10 mins backup config. should be Daily Questions I have confirmed ASR supports fail back from Azure- on premise(VMWare specifically). Hence ASR(Azure site recovery) will be used for the project. However, what is the seamless method to replicate the databases(Oracle, Microsoft SQL and MySQL). https://learn.microsoft.com/en-us/azure/site-recovery/vmware-azure-failback What is the best approach to replicate the Application Servers? integrating existing on-premise 3rd party network security tool for firewall etc instead of the azure cloud native security tool. recommendation?? cost optimization techniques/recommendations Best practices for conducting non-destructive DR drills.
File share migrations simplified with Azure Copilot Migration Agent
Building on our earlier announcement of discovery and assessment support for SMB and NFS file shares in Azure Migrate, we are extending the experience to support end-to-end file share migrations within the same workflow. With Azure Copilot Migration Agent, customers can move from discovery and assessment to migration through a single guided experience in Azure Migrate. By bringing planning and execution together, the agent helps organizations streamline migration activity, reduce handoffs, and maintain continuity across stages. Overview Since the release of file share discovery and assessment in Azure Migrate earlier this year, customers have indicated that while visibility into their file share estate improved, the transition to execution remained fragmented. In many cases, teams still had to work across separate workflows for inventory, readiness planning, and migration, increasing operational friction and the risk of losing context between stages. Azure Copilot Migration Agent helps address this gap by bringing discovery, assessment, planning, and execution into a single guided journey. Azure Migrate provides visibility and recommendations, while Azure Storage Mover supports execution in a connected, agentic experience. The result is a more consistent migration path that reduces complexity, preserves context, and helps teams move file shares to Azure with greater operational confidence. Customer Value This update streamlines the migration journey by connecting each stage of the process and reducing operational overhead. Natural language guidance helps teams start and manage migration activities much faster, often in hours or days instead of weeks. The experience supports the following scenarios: End-to-end discovery, assessment, and migration for on-premises Windows and Linux file shares (SMB) to Azure Files. Discovery and assessment for on-premises Windows and Linux file shares (NFS). Data transfers from one Azure Blob container to another container. Design principles The experience preserves continuity across inventory, readiness insights, and execution planning, enables direct movement of validated shares when heavyweight orchestration is unnecessary, maintains approval and sequencing controls, and supports the file and object movement patterns commonly required in production environments. Getting Started with Storage Migration in Azure Copilot Migration Agent (ACMA) Launch Azure Migrate: Sign-in to the Azure portal, open Azure Migrate. From the Getting Started page, open Azure Copilot Migration Agent, then select or create an Azure Migrate project. Describe the migration in natural language. The agent detects storage migration intent and assists with storage migration planning and routes execution requests seamlessly. Examples scenarios and prompts Migration of on-premises Windows Server data over SMB to Azure Files 2. Prompt: Help me transfer data from one Azure blob container to another blob container Call to action Storage integrated capability is launching in Limited Preview at Microsoft Build. Sign up for the Preview here. For questions, contact storagemigrationcopilotagent@microsoft.com. Learn More File share discovery and assessment in Azure Migrate Azure Copilot Migration Agent Azure Storage Mover
Cutover Strategy for Azure PaaS Services: A Step-by-Step Guide to Near Zero-Downtime Migrations
"In most Azure migrations, infrastructure is the easy part. The real risk — and the real engineering challenge — lies in the cutover." Why Cutover Strategy Matters Migrating mission-critical applications to Microsoft Azure — especially PaaS-based systems — requires more than provisioning resources. The real complexity lies in executing a safe, controlled transition of traffic and data while maintaining high availability and disaster recovery (HA/DR) at every stage. In enterprise environments: Applications are deeply interconnected Systems run 24×7 under strict SLAs Downtime is rarely acceptable A poorly executed cutover can lead to: Authentication failures (token/config mismatches) Data inconsistencies (split-brain scenarios) Message loss (queue gaps during switchover) Degraded user experience (latency spikes, partial failures) Goal: Shift traffic — not risk. Choosing the Right Cutover Strategy Strategy Downtime Risk Rollback Complexity Timeline Best For Big Bang High High Hard Low 1–2 days Simple, low-dependency apps Blue-Green Low Medium Easy Medium 1–2 weeks Stateless apps Canary Release Very Low Low Very Easy Medium 2–3 weeks Gradual validation Phased Parallel (Recommended) Helps achieve near zero Low Instant High 3–6 weeks Complex PaaS systems Recommendation: Use Phased Parallel Cutover for enterprise PaaS migrations involving messaging, databases, and multi-team ownership. HA vs DR — Quick Clarity Aspect High Availability (HA) Disaster Recovery (DR) Goal Prevent downtime Recover from failure Scope Same region (zone redundancy) Cross-region (geo-failover) RTO Seconds–minutes Minutes–hours Example Zone-redundant App Service Azure SQL Failover Groups During cutover, you should design for both simultaneously. A cutover without HA/DR is a recipe for a production incident. End-to-End System Topology Before diving into the phased cutover, it's important to understand the full landscape of PaaS components involved in the migration: Layer Azure Service Role Cutover Complexity Traffic Azure Front Door Global routing, weighted traffic split Low (config change) Compute App Service / AKS Application hosting Medium (stateless, replaceable) Messaging Azure Service Bus Async communication, event-driven flows High (message loss risk, ordering, relay) Database Azure SQL / Cosmos DB System of record Medium–High (failover groups) Cache Azure Managed Redis Performance layer (non-authoritative) Low (rebuild on miss) Storage Azure Blob Storage File/object persistence Low–Medium (GRS handles it) Identity Microsoft Entra ID Authentication & authorization Low (shared across environments) Config App Configuration + Key Vault Centralized settings & secrets Low (read-only, dual-read capable) Observability Azure Monitor + App Insights Metrics, tracing, alerting N/A (must be in place before cutover) Phased Parallel Cutover (with HA/DR Built-In) Note: The phase diagrams below focus specifically on Azure Service Bus (messaging) — the most complex cutover component. Messages are transient (an undelivered message is permanently lost), ordering matters, dual-write risks split-brain, and consumers maintain processing state that can't simply be switched. Other PaaS services (SQL, Storage, Redis) have well-established, largely automated cutover mechanisms (failover groups, GRS, cache rebuild) and are covered in the text sections. Phase 1 — Initial Validation (Safe by Design) What Happens Small percentage (5%) of traffic routed to new system via Azure Front Door weighted routing New compute runs in Azure (App Service / AKS) Still depends on old backend (messaging + database) HA/DR Strategy Old system acts as active fallback + DR Maintain full capacity in old environment Validate failback using Azure Front Door origin groups Validate auth parity via Microsoft Entra ID (App Registrations, token issuers) Go/No-Go Criteria to Proceed to Phase 2 Criteria Threshold Error rate on new system < 0.1% for 24 hours Latency (P95) Within 10% of old system Auth success rate Target: full parity with old system Monitoring coverage All key metrics visible in Application Insights Rollback tested Successfully reverted traffic split at least once ✔ Low risk · ✔ Instant rollback Phase 2 — Parallel Run + Replication (Highest Risk Phase) What Happens Old and new systems run in parallel (80/20 split favoring new) Data and messages replicated via stateless relay Both systems serve consumers HA/DR Strategy Relay must be stateless and scalable → Use Azure Functions (Consumption plan with auto-scale) Messaging resilience → Azure Service Bus with: Retries (exponential backoff) Dead-letter queues (for poison messages) Duplicate detection (message deduplication window) Monitor → Azure Monitor + Application Insights tracking: Replication lag Throughput (messages/sec) Relay failures Consumer processing time Risks & Mitigations Risk Mitigation Data inconsistency Single-write model — one system of record at a time Message duplication Idempotent consumers (deduplication by message ID) Relay failure Circuit breaker pattern, dead-letter fallback Split-brain scenarios Clear ownership boundaries per service Go/No-Go Criteria to Proceed to Phase 3 Criteria Threshold Traffic on new system ≥ 80% stable for 48 hours Data sync lag Target: real-time parity (no measurable lag) Message loss rate Target: zero loss (validated via monitoring) Relay error rate < 0.01% DR failover tested At least 1 successful region failover drill ⚠ Highest risk phase — requires continuous observability Phase 3 — Full Cutover (HA/DR Fully Owned by New System) What Happens All traffic routed to new environment Old system moved to standby, then decommissioned after validation DR ownership transfers fully to new system HA Strategy Zone redundancy (App Service, AKS, Service Bus) Autoscaling (CPU/memory-based + custom metrics) Global routing via Azure Front Door with health probes DR Strategy Service DR Mechanism Azure SQL Database Failover groups (auto-failover) Azure Cosmos DB Multi-region writes Azure Storage GRS / RA-GRS (geo-redundant) Azure Service Bus Geo-DR namespace pairing Azure Managed Redis Active geo-replication Old system should be decommissioned only after DR validation passes — run a full region failover drill before removing old infrastructure. Core Principles for PaaS Cutover Cache — Azure Managed Redis Non-authoritative (cache is disposable) Do NOT migrate cached data — let it rebuild Expect and design for cache misses during cutover Pre-warm critical keys if latency-sensitive Messaging — Azure Service Bus Help ensure durability (premium tier, geo-DR pairing) Avoid dual writes (one producer → one queue at a time) Use relay pattern carefully with circuit breakers Dead-letter monitoring is critical and should not be skipped Storage — Azure Storage Dependency-driven migration (move what services need) Treat as shared contract (APIs, blob containers) Use AzCopy or Storage Data Movement library for bulk transfer Databases — Azure SQL Database / Azure Cosmos DB Systems of record — integrity over speed Use online migration (Azure Database Migration Service) for minimal downtime Validate data checksums post-migration Data Consistency Patterns Pattern Risk Use When Single Write (Recommended) Low One system is the authority; others read via replication Event Replication Medium Both systems need near-real-time data; eventual consistency acceptable Dual Write High — Avoid Leads to split-brain; only viable with distributed transactions Common Pitfalls (and How to Avoid Them) Pitfall Prevention Auth failures Pre-validate tokens, verify config parity across environments Hidden dependencies Centralized configuration (Azure App Configuration) Message duplication Idempotency + Service Bus deduplication window Data inconsistency Single-write model with clear ownership Cache issues Pre-warm cache; design for miss tolerance Background jobs Audit all scheduled tasks; redirect to new system explicitly Lack of monitoring Deploy observability BEFORE cutover, not after Observability During Cutover Tools Azure Monitor — Infrastructure metrics, alerts Application Insights — Distributed tracing, dependency maps Azure Log Analytics — Centralized query across all resources Azure Service Bus Explorer — Queue depth, dead-letters Key Metrics to Track Metric Why It Matters Latency (P50, P95, P99) Detect degradation early Error rates (4xx, 5xx) Catch failures before users notice Dependency health Identify cascading failures Queue backlog / depth Messaging throughput bottlenecks Replication lag Data consistency validation Active connections Connection pool exhaustion If you can't observe it, you can't safely cut over. Rollback Strategy Old system remains active and at full capacity throughout Phase 1–2 Quick switch via Azure Front Door origin group weight (route all traffic back to old in seconds) Avoid irreversible writes to new system early in the process Test rollback at least once before entering Phase 2 Document rollback runbook with clear decision criteria Rollback triggers: Error rate > 1% sustained for 5 minutes Latency P95 > 2x baseline Data sync lag > 30 seconds Any message loss detected Tooling & Automation Concern Recommended Tool Infrastructure as Code Bicep / Terraform CI/CD Pipelines Azure DevOps / GitHub Actions Traffic Management Azure Front Door (weighted routing) Configuration Azure App Configuration + Key Vault Secrets Azure Key Vault (managed identity access) Monitoring Azure Monitor + Application Insights Alerting Azure Monitor Action Groups Runbooks Azure Automation / manual decision gates Team Roles & Communication Role Responsibility During Cutover Migration Architect Go/no-go decisions, phase transitions Platform Engineer Infrastructure, Front Door config, DNS App Team Lead Application validation, smoke tests SRE / Ops Monitoring, alerting, incident response DBA Data sync validation, failover group health Stakeholder / PM Communication to business, escalation path Communication plan: Dedicated Teams/Slack channel for cutover window Status updates every 30 minutes during active phases Pre-defined escalation matrix Post-cutover retrospective within 48 hours Final Cutover Readiness Checklist [ ] Traffic tested at ≥ 50% on new system [ ] Stable for 24–48 hours at target load [ ] Data sync lag approaching zero (real-time parity confirmed) [ ] Rollback tested and documented [ ] DR tested (region failover drill passed) [ ] All teams briefed and on-call scheduled [ ] Monitoring dashboards reviewed and alerting active [ ] Auth validated end-to-end (Entra ID, certificates, API keys) [ ] Background jobs redirected and verified [ ] Stakeholder sign-off obtained Final Takeaways Use phased parallel cutover — not big bang Incorporate HA/DR into every phase — not as an afterthought Move compute first, data carefully — messaging is the hardest part Design for rollback — until you've proven the new system at full traffic Validate continuously — observability is your safety net Closing Thought A cutover strategy helps ensure a smooth transition. HA/DR helps you survive when things go wrong during that transition. The most successful Azure migrations treat both as one — not separate concerns. We'd Love to Hear From You What cutover challenges have you encountered in your Azure migrations? Have you used a relay pattern for messaging, or found a different approach that worked? Share your experiences in the comments below — your insights help the community learn faster. Further Reading Azure Service Bus Geo-Disaster Recovery Azure Front Door Traffic Routing Methods Azure SQL Database Failover Groups Azure Monitor Overview Azure App Configuration Best Practices Tags: Azure · Migration · Service Bus · PaaS · High Availability · Disaster Recovery · Cutover Strategy · Zero Downtime · Azure Front Door Disclaimer: This guide is based on field experience from enterprise Azure PaaS migrations. Results depend on your specific architecture, workload, and Azure region availability. Traffic percentages, timelines, and thresholds are illustrative targets — not guarantees. This article does not constitute an SLA; refer to Azure Service Level Agreements for official uptime commitments.AHEAD helps us launch the Strategic Azure Storage Services Partner Program
AHEAD becomes the first Azure Storage Strategic Channel Partner by demonstrating their expertise in helping customers select the ideal Azure Storage, or Azure Storage ISV, Service to offer the ideal price / performance solution for their application and helping customers to migrate to Azure quickly and safely.Fast cloud migration, measurable ROI: Forrester Total Economic Impact study of Azure VMware Solution
Many organizations are balancing near-term continuity for VMware-based workloads with longer-term cloud modernization goals – all while managing cost, security, and resiliency. Azure VMware Solution (AVS) is built for this moment: a Microsoft-managed service verified by VMware that enables running VMware Cloud Foundation (VCF) workloads (vSphere, NSX-T, vSAN, HCX) on dedicated Azure infrastructure. It gives organizations a practical way to move or extend VMware environments into Azure while maintaining operational consistency and leveraging the skills of existing VMware teams. To help leaders quantify the potential value of this approach, Microsoft commissioned Forrester Consulting to conduct The Total Economic Impact™ (TEI) of Microsoft Azure VMware Solution (March 2026). The study models the financial impact over three years and risk-adjusts results. Access the full study here: aka.ms/AVS-TEI Here’s what the study found and how IT leaders can use it as a framework for decision-making: Topline results from the study Forrester’s risk-adjusted financial analysis for a composite organization 1 found: 341% ROI over three years 2 $5.6M net present value (NPV) 3 <6 months payback 4 These metrics are meaningful on their own, but the bigger story for leadership is where the value comes from: improved operational stability, reduced infrastructure costs driven by data center exit and hardware refresh avoidance, and the ability to redeploy skilled IT resources from maintenance to modernization. The customer journey: why organizations turn to AVS AVS offers a bridge: Lift and shift VMware workloads into Azure without forcing immediate re-platforming then, modernize at a pace aligned to business priorities. In the study, Forrester interviewed decision-makers with experience using AVS. Interviewees described common challenges that led them to invest in AVS, including: Fragmented systems that complicated and slowed operations: Inherited stacks, duplicated tools, and unclear ownership of orphan machines made operations and governance harder. Rising cost and complexity of on-premises operation: Colocation fees, energy and cooling costs, server refresh cycles, and tooling renewals were difficult to justify against cloud economics. Limited capacity and skills to refactor at scale: Teams wanted the cost and agility benefits of the cloud but didn’t have the time or skills to rewrite hundreds (or thousands) of VMs on aggressive timelines. Security and audit pressure: Disparate environments and legacy access models elevated risk and created audit friction. Operational variability and end-user experience: VPN dependencies, inconsistent remote tooling, and endpoint logistics led to slow first-call resolution and downtime risks. Three quantified benefits that drive the business case 1) Reduction in downtime and associated costs by 80% In the study, interviewees reported that moving VMware workloads to AVS improved day-to-day reliability by eliminating fragile on-premises workflows and leveraging Azure’s managed infrastructure. Examples included fewer VPN-related failures, faster issue resolution through centralized tooling, and stronger service-level performance. For leadership teams, this benefit is about more than avoided cost. Better up time protects customer experience, employee productivity, and reduces the operational noise that can slow modernization programs. 2) Reduced infrastructure costs through data center exit, refresh avoidance, and cleanup A second driver is the ability to avoid or eliminate significant portions of data center cost and refresh spend. In the study, interviewees described using AVS to close data centers, avoid upcoming hardware refresh cycles, and reduce ongoing capital and operating costs. Importantly, interviewees also reported that migration waves prompted additional savings through portfolio hygiene by validating each VM, decommissioning redundant systems, and rightsizing oversized workloads. Those actions helped organizations reduce their ongoing compute, storage, and licensing footprint after migration. 3) Redeployment of 50% of IT team members from maintenance to modernization The TEI study quantifies a practical advantage of a managed VMware environment in Azure: fewer hours spent on hardware lifecycle, cluster patching, upgrades, and other routine data center tasks. In practice, many leaders treat this as capacity created rather than budget eliminated: the opportunity to shift experienced engineers toward modernization, automation, cloud governance, proactive incident prevention, and higher-value business initiatives. Unquantified benefits organizations should weigh Beyond the quantified categories, the study also highlights benefits that are strategically important, but not fully quantified in the model: Acceleration of future modernization: With workloads running in Azure via AVS, organizations can integrate platform services across security, identity, data, and analytics and build a runway for new capabilities, including AI-driven scenarios in Azure. Fast, cost-effective migration of legacy workloads: Interviewees described avoiding major consulting or hiring costs that would have been required to refactor complex workloads into cloud-native designs. Improved audit readiness and security posture: Consolidating fragmented environments into governed Azure landing zones can simplify audit preparation and strengthen governance and monitoring. For many leadership teams, these benefits strengthen the business case because they support broader transformation outcomes that extend beyond infrastructure cost alone. Things to consider in your own decision process If you’re building a business case to move workloads to Azure, whether it be lifting and shifting to AVS or replatforming and refactoring to Azure IaaS and managed services, consider mapping your environment across these areas: Data center timelines: Refresh cycles, colocation exit deadlines, and contract constraints. Operating model readiness: How quickly teams can adopt cloud-native services versus preserving VMware operations during transition. Modernization roadmap: Determine which applications are candidates for investment in replatforming, refactoring, replacement, or retirement once in Azure. Next steps Read the full TEI study: aka.ms/AVS-TEI Explore more about AVS: aka.ms/AzureVMwareSolution Get the VMware to Azure VMware Solution Planning Guide: aka.ms/VMwareToAVSguide Learn more about the Azure Copilot migration agent: aka.ms/migrate/AMA Join the AVS Pros group on LinkedIn for the latest updates and news: aka.ms/AVSPros 1 Composite organization: Forrester designed a composite organization based on characteristics of the interviewees’ organizations. 2 Return on Investment (ROI): A project’s expected return in percentage terms. ROI is calculated by dividing net benefits (benefits less costs) by costs. 3 Net present value (NPV): The present or current value of (discounted) future net cash flows given an interest rate (the discount rate). A positive project NPV normally indicates that the investment should be made unless other projects have higher NPVs. 4 Payback: The breakeven point for an investment. This is the point in time at which net benefits (benefits minus costs) equal initial investment or cost.Customer Offerings: Azure Local - Implementation, Migration, and Management
Hi everyone! Brandon here, back once again to talk to you about a couple of new offerings that have just been released to assist our Unified customers with their on-premises virtualization needs! I continue to have the privilege of leading a great program and team helping customers to migrate from VMware to more cost-effective and/or modern solutions. These new offerings are <drum roll>: Hyper-V - Implementation, Migration, and Management Azure Local - Implementation, Migration, and Management NOTE: These offerings do not provide hands on keyboard support, do not create custom documentation for customers, and cannot provide direct support for any 3 rd party products that may be used in the process of migrations. Many customers are reassessing their virtualization strategies and are actively exploring alternatives to VMware that align with long‑term hybrid cloud goals. Azure Local offers a purpose‑built platform that combines proven Windows Server–based virtualization with Azure services and management tooling, enabling customers to modernize on‑premises infrastructure while maintaining tight integration with Azure management, security, and governance capabilities. Whether driven by changing licensing models, cost optimization, or the need for deeper hybrid cloud integration, a successful transition requires more than a technology shift—it requires a structured, outcome‑focused approach. While we are providing these new offerings to customers, you do also have the option of more extended engagements as well that are broader in scope and more tailored to the end goals while we work side by side with you. If you are a Unified customer and looking to move off of VMware to Azure Local, or you just need help with your on-premises Microsoft virtualization technologies in general, have your account manager (CSAM) reach out to me! Planning to go at it alone?? Virtually (no pun intended) every environment reviewed by my team (and that is a LOT) that was set up prior to our review will have configuration issues, at times warranting extensive efforts to correct. Problem 1: There are some potentially significant differences between the way VMware and Azure Local are architected from the start, especially in areas of networking and storage, where mimicking methods used in the VMware world can actually lead to performance degradation in your target Azure Local environment. Problem 2: Your management method must also change. Additionally, if you are converting/migrating to Azure Local, the available methods need to be determined, the terminology and functional differences identified and learned…there can be a lot to unpack in this area. Problem 3: Perhaps the most obvious is that this may be a new platform for your team, and its important for them to gain experience through guided actions and knowledge transfer on the fly for those questions they really have, which is exactly what we aim to provide in guiding implementations and migrations! A Structured Engagement Model Successful Azure Local implementations are built around a guided engagement model rather than a one‑size‑fits‑all checklist. Each engagement is tailored to the customer environment, acknowledging that differences in scale, workloads, hardware, and operational maturity directly influence the migration approach. The framework emphasizes collaboration, clarity of expectations, and incremental progress instead of disruptive “lift‑and‑shift” execution. Whether we are talking about migration from another virtualization platform, or simply trying to reduce costs by implementing a new virtualization infrastructure, we’re here to help! Key Phases of an Azure Local Implementation and/or Migration Most Azure Local implementation and migration engagements progress through a common set of phases: Engagement scoping and technical discovery to understand goals and current state (this is the conversation I, or one of the TZ Leads in the VMware Migration Program have with customers) Planning and design aligned to business and operational outcomes, with a limited scope Deployment and configuration validation to ensure platform readiness Security and migration testing to reduce risk and confirm workload compatibility Feature enablement, including Azure Arc, to extend governance and management While these phases provide structure, the sequence and depth of each stage are adapted based on the customer environment and objectives. Key Outcomes for Customers Organizations that engage in Azure Local implementation or migration efforts commonly achieve: Deeper familiarity with Microsoft virtualization technologies Successful deployment of PoC, pilot, or production environments Validated test migrations of virtual machines Identification and resolution of technical blockers Increased confidence in operational readiness These engagements are advisory and collaborative in nature, prioritizing customer enablement and success. Knowledge Transfer and Operational Readiness A central focus of the Azure Local engagements is ensuring that IT teams are prepared to operate the platform long after deployment completes. Knowledge transfer is embedded throughout the engagement through working sessions and direct participation in implementation activities. This approach helps organizations move confidently into steady‑state operations without relying on long‑term external support. As I mentioned above, if you do feel you will need longer term support, we have your back on that front as well. Looking Beyond Migration An Azure Local migration is often the first step in a broader transformation journey. Many organizations use this transition to enable hybrid management, strengthen security posture, and prepare for future application or cloud modernization initiatives. When approached strategically, Azure Local becomes a platform for long‑term innovation and a step to modernizing your infrastructure, not just a replacement hypervisor. Conclusion Moving from VMware to Azure Local is not simply a technical migration—it is an opportunity to modernize how infrastructure is managed and governed. With structured planning, guided execution, and a focus on operational readiness, organizations can transition with confidence to a virtualization platform built for today’s hybrid cloud realities and tomorrow’s growth. Thanks for reading, and maybe we’ll talk soon!
