Azure Migration and Modernization Blog articles

Production Cutover in Cloud-Native Migrations

dhruti — Thu, 16 Apr 2026 00:05:46 GMT

Migration Planning vs Runtime Reality

Migration to container orchestration platforms such as Azure Kubernetes Service (AKS) typically involves:

Containerizing application workloads
Configuring cluster networking
Migrating data to managed storage services
Updating application integrations
Validating deployment pipelines

Even with these practices in place, runtime validation often reveals issues that are not directly related to deployment or application code.

For example, it is common to encounter scenarios where:

Services deploy successfully but terminate under production memory allocation thresholds
Configuration repositories do not reflect region‑specific runtime parameters
Messaging consumers fail to bind to cloud‑based ingestion pipelines
External integrations continue referencing legacy endpoint mappings

These runtime discrepancies typically surface only after traffic routing begins — highlighting the distinction between deployment success and operational readiness.

Dependency Transition in Distributed Architectures

Modern enterprise workloads operate across multiple runtime layers:

Compute – Container orchestration policies
Networking – Firewall and endpoint routing
Messaging – Event stream synchronization
Storage – Listener configuration
Analytics – Workspace connectivity
Batch Processing – Scheduled ingestion continuity

In practice, this requires ensuring that all runtime dependencies transition in a coordinated manner.

For instance, a service deployment may succeed in production environments but fail to initialize if:

Storage listeners still reference legacy infrastructure
Analytics workspaces are restricted by updated networking policies
Configuration endpoints are not aligned with Disaster Recovery runtime

As system complexity increases, production cutover becomes less of a deployment task and more of a runtime orchestration challenge.

Disaster Recovery in Migration Execution

Production cutover workflows frequently include:

Regional database switchover
Storage endpoint failover
DNS routing updates
Suspension of compute resources in primary regions
Replica alignment in containerized workloads

Additionally, failback procedures must ensure that:

Primary workloads restart in the correct configuration state
Listener registries are reassigned without duplication
DNS routing reflects restored endpoints
RTO and RPO parameters are met
Smoke testing validates runtime stability

Batch Workloads and Background Processing

Batch pipelines often support:

Historical transactional ingestion
Scheduled synchronization tasks
Downstream analytics processing

Migrating these workloads without phased prioritization can result in:

Delayed ingestion cycles
Messaging queue desynchronization
Reporting inconsistencies

Ensuring continuity of background processing therefore becomes an essential component of production cutover planning.

Treating Cutover as an Orchestration Event

Production cutover must now be approached as a coordinated transition of system state across:

Compute
Data
Networking
Integration
Messaging
Batch execution
Security policies

This ensures that infrastructure provisioning is complemented by runtime alignment across all dependent system layers.

Section	What the Link Reinforces	Recommended Microsoft Learn Link
Production Cutover Definition	Establishes cutover as a distinct operational phase involving traffic redirection, validation, smoke testing, and post‑cutover checks—not just deployment completion.	How to cut over a cloud workload
End‑to‑End Migration Context	Positions cutover within the full migration lifecycle (plan → migrate → operate → govern), reinforcing that success continues post‑go‑live.	Microsoft Azure Migration Hub
AKS Migration Patterns	Shows that AKS migration success depends on runtime behavior, HA/BCDR planning, and workload characteristics—not just container deployment.	Migrate to Azure Kubernetes Service (AKS) Azure Kubernetes Service documentation

Conclusion

Cloud migration success is no longer determined solely by where applications are deployed, but by how effectively runtime dependencies are aligned during production cutover.

Fast cloud migration, measurable ROI: Forrester Total Economic Impact study of Azure VMware Solution

BritneyCretella — Wed, 22 Apr 2026 17:39:32 GMT

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¹ found:

341% ROI over three years²
$5.6M net present value (NPV)³
<6 months payback⁴

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

¹Composite organization: Forrester designed a composite organization based on characteristics of the interviewees’ organizations.

²Return on Investment (ROI): A project’s expected return in percentage terms. ROI is calculated by dividing net benefits (benefits less costs) by costs.

³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.

⁴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.

Discover and assess File Shares for migration to Azure Files with Azure Migrate

ankitsurkar — Tue, 07 Apr 2026 07:00:08 GMT

When organizations migrate to the cloud, applications are at the center of every decision. And behind every application is data, stored in file shares, accessed by users and services, and critical to keeping the application running. Moving that data seamlessly is not optional; it is a fundamental part of any successful migration.

That is why we are excited to announce that Azure Migrate now supports discovery and assessment of SMB and NFS file shares hosted on Windows and Linux servers, giving you a complete, data-driven picture of your file share estate and a clear path to Azure Files.

Overview

File shares are the backbone of day-to-day operations for many enterprises, storing project files, user data, application content, and shared resources across teams. Yet when it comes to cloud migration planning, these workloads are often assessed manually through scripts or spreadsheets, leading to incomplete inventories and inaccurate cost estimates.

With this new capability in Azure Migrate, you can now:

Discover SMB and NFS file shares across Windows and Linux servers, automatically and agentlessly

Assess readiness of each file share for migration to Azure Files

Get right-sized recommendations mapped to the correct Azure Files tier, Standard or Premium

Visualize cost estimates before you commit to migration

All of this from the same Azure Migrate portal you already use. No new tools, no extra agents.

Customer Value Unlocked

Previously, customers planning a migration of file shares to Azure Files had to rely on manual discovery methods, running scripts, compiling spreadsheets, or engaging consultants just to understand what they had. This created uncertainty, slowed decisions, and led to costly surprises post-migration.

Now, with Azure Migrate’s file share discovery and assessment:

Applications migrate as a whole, not in pieces. File share data is an integral part of your application. Azure Migrate helps you treat it that way, giving you visibility into the file shares your applications depend on so nothing gets left behind.

No more manual inventory. The Azure Migrate appliance automatically discovers all SMB and NFS file shares across your Windows and Linux servers.

No more sizing guesswork. Assessments analyze actual usage data and recommend the right Azure Files tier for each share, so you do not over-provision Premium tier where Standard suffices, or under-provision where performance matters.

No more migration risk. Readiness checks surface compatibility issues, unsupported configurations, and permission gaps before you migrate, not after.

Faster planning, faster execution. What used to take days of manual effort is now automated, giving your team a migration-ready inventory in hours.

How to Use the Feature

Getting started is straightforward with the existing Azure Migrate appliance:

Step 1: Set up or update your Azure Migrate appliance

Deploy the Azure Migrate appliance in your on-premises environment if you have not already. If you have an existing appliance, update it to the latest version to enable file share discovery.

Step 2: Run discovery

The appliance automatically discovers SMB and NFS file shares across your environment, along with metadata including storage consumed, file counts, and access patterns. Discovery typically completes within a few hours depending on the size of your environment.

Step 3: Create an Azure Files assessment

Once discovery is complete, select the discovered file shares you want to include in scope and configure your assessment settings: region, pricing tier preference, and redundancy options.

Step 4: Review readiness and recommendations

The assessment classifies each share as Ready, Ready with Conditions, or Not Ready for Azure Files, and provides:

Recommended Azure Files tier (Standard or Premium) per share

Monthly cost estimates

Readiness blockers to address before migration

Step 5: Plan and execute migration

Use the assessment output to prioritize your migration waves and execute the data transfer using Azure Storage Mover or AzCopy.

Ready to Get Started?

Your applications depend on their data. Make sure that data moves with them.

Start leveraging file share discovery and assessment in Azure Migrate today and migrate to Azure Files with confidence.

Learn more and get started with Discovery and Assessment of fileshares to Azure Files

From Discovery to Executive Presentation: Plan Your Migration with Azure Migrate in Hours

Shikher — Fri, 03 Apr 2026 18:06:11 GMT

The migration planning bottleneck

Every migration starts with the same question: what do we have, and where should it go? Getting from that question to a clear, executive-ready answer has traditionally taken weeks. You scan the environment, export spreadsheets, manually classify workloads, run assessments and business case for cost analysis and readiness, and then stitch everything together into a deck that's outdated by the time you present it.

Azure Migrate now collapses that entire process into a single workflow. Starting with the Azure Migrate Collector, you can scan your estate offline, enrich the inventory with tags and application groupings, and generate a PowerPoint report that summarizes modernization and lift-and-shift recommendations, security posture, and cost insights ready for your next stakeholder meeting.

Note: Although the blog describes the workflow using collector, the presentation, data enrichment and auto-application discovery work with Azure Migrate appliance as well.

Here's how it works.

Step 1: Scan your estate with Azure Migrate Collector

The Azure Migrate Collector is a lightweight Windows Server tool that discovers servers, software, databases (SQL Server, PostgreSQL, MySQL, MongoDB*), file shares, and web apps - .NET on IIS, Java on Tomcat, across VMware, and any cloud or Hyper-V or bare-metal infrastructure.

What makes the Collector different from the full Azure Migrate appliance is speed and simplicity. There's no Azure connectivity required during scanning. You run the Collector, it captures server configuration, historical performance data from vCenter, software inventory, and workload metadata. When you're done, you export a ZIP file and upload it to your Azure Migrate project.

For a typical VMware estate, data collection takes 2-4 hours depending on scale and number of credentials. For organizations that need quick pre-sales assessments or have network restrictions that make continuous appliance-based discovery impractical, the Collector gets you from zero to discovered inventory in a single session.

*coming soon

Step 2: Enrich your inventory with tags

Raw discovery data tells you what exists. Tags tell you what it means. Before generating reports, you may want to classify your workloads using Azure Migrate's tagging system.

Two tag families matter most:

Environment tags (AzM.Environment: Dev) -- Mark servers and workloads running in dev/test environments. Anything without this tag is treated as production by default, which affects sizing and cost calculations.
Migration intent tags (AzM.MigrationIntent: Retain or AzM.MigrationIntent:Retire) -- Set to Retain for workloads that stay on-premises, or Retire for workloads you plan to decommission. Untagged workloads are automatically considered for migration or modernization.

Tag consistently: if a server hosts two databases and needs to be retained, tag the server and both databases for accurate recommendations. You can tag using the portal or at scale using the csv import mechanism, we recommend the latter.

You can also apply general-purpose tags for department, business unit, datacenter, or any other dimension your organization uses. These tags carry through the migration journey, enable you to filter/ classify workloads and applications, scope business case, assessment and presentation reports, and help stakeholders understand the estate in their own terms.

Step 3: Organize workloads into applications

While tagging is underway, the auto-discovery of applications runs in the background for Collector-based inventory. Azure Migrate groups servers and workloads into logical application entities using naming patterns, inferred environments, and derived server roles. Each auto-discovered application gets a confidence score indicating how accurate the grouping is.

You can review these system-defined applications and adjust them: rename, add or remove workloads, set properties like business criticality and complexity, or create entirely new applications manually. If you prefer to define/update/edit applications at scale, export all inventory as CSV (same file referenced in the image above), add/update application names next to each workload, and import it back.

Further, you can also add/update application properties such as application type – packaged/custom, complexity and criticality, at scale using the application CSV.

Grouping workloads into applications is what turns a flat inventory into something meaningful for planning. Instead of "427 servers and 82 databases," you can now talk about "12 business-critical applications and 35 departmental tools."

Step 4: Generate an executive-ready report

With your inventory tagged and organized, you're ready to generate an Azure Migrate report. Select the Azure modernization and migration report type, and choose your migration preference:

Modernize (PaaS-preferred) – SQL databases get Azure SQL recommendations, web apps get App Service or AKS recommendations, and general servers get Azure VM recommendations. This option surfaces workloads that are candidates to become AI-ready on Azure PaaS.
Migrate (IaaS) – Lift-and-shift to Azure VMs, or to Azure VMware Solution for VMware estates.

The report generates a PowerPoint deck that covers:

Workload and application summary across your estate
Security insights and vulnerability posture
Total cost of ownership and return on investment
Readiness and target recommendations per workload
Estimated Azure costs by migration strategy
A high-level migration wave plan

This is the deliverable you hand to leadership. No manual slide building, no copy-pasting from multiple tools. The report pulls from the assessments Azure Migrate creates in the background and consolidates everything into one narrative.

Step 5: Drill into application-level details with application assessment

The executive report gives the big picture. For deeper analysis, application assessments let you drill into any specific application to understand exactly what happens to each workload.

The assessment breaks down every workload in the application across the 5Rs:

Replatform – Move to a managed Azure service with minimal code changes (e.g., SQL Server to Azure SQL Managed Instance)
Refactor – Restructure application code to run natively on Azure PaaS. For code-level insights, connect CAST Highlight or use GitHub AppCat to scan source code and identify what needs to change.
Rehost – Lift and shift to Azure VMs with no application changes
Retain – Keep on-premises (flagged by your migration intent tags)
Retire – Decommission the workload

Each workload gets readiness status, recommended Azure target, right-sized SKU, and monthly cost estimate. You can customize assessment settings per workload type and compare alternative targets side by side.

This is where sellers and partners dig in during customer workshops, and where IT teams build their detailed migration plans workload by workload.

Get started today

The full workflow from discovery to executive presentation runs in Azure Migrate today. Here's how to begin:

Set up Collector - Download and configure the Azure Migrate Collector on a Windows Server in your datacenter
Choose your discovery method - Compare Collector, appliance, and import-based approaches for your scenario
Tag your workloads - Follow tagging best practices for accurate recommendations
Organize applications - Define and manage applications from your discovered inventory
Generate your report - Build an Azure Migrate report and export to PowerPoint
Dive deeper - View application assessments for application and workload-level migration plans

Whether you're a partner running a pre-sales assessment or an IT team planning your own migration, this workflow gets you from "we need to move to Azure" to "here's the plan" faster than any manual approach can.

Resolving MachineWithSameBiosIdAndFqdnAlreadyExists During Azure Migrate Mobility Agent Registration

vihegde — Wed, 01 Apr 2026 00:24:27 GMT

While working on an Azure Migrate project, we encountered a failure during Mobility Agent registration with the error:

<ErrorCode>MachineWithSameBiosIdAndFqdnAlreadyExists</ErrorCode>

This error code is identified in C:\ProgramData\ASRSetupLogs\ASRUnifiedAgentConfigurator.log file on Source Server.

This issue surfaced after a server was initially onboarded using credential-based discovery, followed by a manual Mobility Agent installation via credential-less discovery.

In this blog, we’ll walk you through:

Why this issue occurs
What it means technically
The exact step-by-step resolution

🚨 Problem Statement

Here’s what happened in our scenario:

A source server was successfully discovered using credential-based discovery via Azure Migrate.
Later, the Mobility Agent was manually re-installed and re-registered using credential-less discovery.
During registration, the Mobility Agent failed with the error: MachineWithSameBiosIdAndFqdnAlreadyExists
Logs confirmed the issue at: C:\ProgramData\ASRSetupLogs\ASRUnifiedAgentConfigurator.log
As a result, Mobility Agent Registration with Azure Migrate Vault could not be completed and further replication steps were blocked.

Fig 1: 'ASRUnifiedAgentConfigurator.log' File with 'MachineWithSameBiosIdAndFqdnAlreadyExists' error

🔍 Root Cause

Azure Migrate uniquely identifies machines using BIOS ID + FQDN.

When the same machine is onboarded using different discovery methods:

It results in multiple registrations for the same physical server
Azure Migrate detects this as a duplicate identity conflict

Fig 2: Duplicate Registration Conflict in Azure Migrate

In this case:

First registration → Credential-based discovery ✅
Second registration → Credential-less discovery ❌
Result → Azure rejects the second registration due to identity duplication

🛠️ Resolution

The fix involves realigning the Mobility Agent with the original machine identity.

✅ Step 1: Generate Agent Config Input (Source Machine)

Open Command Prompt as Administrator:

cd "C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\" AzureRcmCli.exe --getagentconfiginput

👉 This generates a unique Agent Config Input string.

✅ Step 2: Generate Mobility Service Configuration File (Appliance)

On the Azure Migrate appliance:

Open Azure Appliance Configuration Manager
Go to Mobility Service Configuration
Paste the Agent Config Input
Download the generated configuration file

Fig 3: Download Configuration File Option in Azure Migrate Appliance Configuration Manager

✅ Step 3: Copy Config File to Source Server

Copy the downloaded file (example below):

e1fdc8ce-e518-4fd2-b281-cc71433d512e_config.json

Paste it into:

C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\Application Data\etc

✅ Step 4: Validate & Update drscout.conf

Navigate to:

C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\Application Data\etc

Edit drscout.conf file and ensure the following parameters exist under [vxagent]:

[vxagent]
HostId="Collect from support team"
ResourceID="Collect from support team"

Fig 4: How to edit drscout.conf file

⚠️ Important:

Use the original HostId and ResourceID
These correspond to the first (credential-based) discovery
If unavailable, obtain them from the Azure Migrate support team

✅ Step 5: Unregister Existing Mobility Agent

Run:

cd "C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\" AzureRcmCli.exe --unregistersourceagent UnifiedAgentConfigurator.exe /Unconfigure true

👉 This removes the conflicting registration.

✅ Step 6: Regenerate Configuration File

Repeat Step 2 using the same Agent Config Input to generate a fresh config file.

✅ Step 7: Re-register Mobility Agent

cd "C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\" UnifiedAgentConfigurator.exe /SourceConfigFilePath "config.json" /CSType CSPrime

✅ After this:

Mobility Agent registers successfully
Replication works without errors

💡 Key Learnings

Avoid mixing credential-based and credential-less discovery for the same machine
Azure Migrate enforces strict identity uniqueness (BIOS ID + FQDN)
Always align the Mobility Agent with the original HostId and ResourceID
Proper cleanup + re-registration resolves the issue without deleting the machine

🧾 Conclusion

The MachineWithSameBiosIdAndFqdnAlreadyExists error is a classic identity conflict scenario in Azure Migrate.

By:

Cleaning up the incorrect registration
Reusing the original machine metadata
Re-registering the agent correctly

…you can resolve the issue cleanly and safely, without impacting the migration workflow.

AWS to Azure Migration — From the Cloud Economics & FinOps Lens

sakshimalhotra — Wed, 01 Apr 2026 00:09:32 GMT

“ROI fails when FinOps joins late.” That single pattern explains why many cloud migrations deliver technical success but financial disappointment. Workloads move. SLAs hold. Teams celebrate go‑live. Then the CFO asks: Where are the savings we modeled?

In most cases, FinOps was engaged after architecture decisions were locked, licenses were double‑paid, and governance debt had already accumulated. This article frames AWS‑to‑Azure migration through a FinOps lens—not to chase immediate modernization, but to deliver defensible, incremental cost savings during and after migration, without increasing risk.

Azure migration guidance consistently emphasizes a structured, phased approach—discover, migrate like‑for‑like, stabilize, then optimize. From a FinOps perspective, this sequencing is not conservative—it is economically rational:

Like‑for‑like preserves performance baselines and business KPIs
Cost comparisons remain apples‑to‑apples
Optimization levers can be applied surgically, not blindly

The real value emerges in the first 90 days after migration, when cost signals stabilize and commitment‑based savings become safe to apply.

{TLDR: Cloud migrations miss ROI when FinOps joins late. AWS → Azure migrations deliver real savings when FinOps leads early, migrations stay like‑for‑like, and optimization is applied after costs stabilize. Azure enables this through four levers: AI‑assisted planning (Copilot + Azure Migrate), cheaper non‑prod with Dev/Test pricing, license reuse via Azure Hybrid Benefit, and low‑risk long‑term savings with Reservations—across compute and storage. Result: lower migration risk, controlled spend, and sustainable savings post‑move.}

This Article talks about top 4 FinOps Levers in AWS → Azure Migration

1. Azure Copilot Migration Agent + Azure Migrate.

Azure Copilot Migration Agent (currently in public preview) is a planning‑focused, AI‑assisted experience built on Azure Migrate. It analyzes inventory, readiness, landing zone requirements, and ROI before execution. You can interact with the Agent using natural language prompts to explore inventory, migration readiness, strategies, ROI considerations, and landing zone requirements.

From a FinOps perspective, this directly translates into faster decision cycles and lower planning overhead. By simplifying and compressing activities that traditionally required weeks of manual analysis or external managed services support, organizations can reduce the cost of migration planning, accelerate business case creation, and bring cost and ROI discussions forward—before environments are deployed and financial commitments are made.

2. Azure Dev/Test pricing:
Azure Dev/Test pricing provides discounted rates for non‑production workloads for eligible subscriptions, significantly reducing dev and test environment costs (Azure Dev/Test pricing). You can save up to 57 percent for a typical web app dev/test environment running SQL Database and App Service. Unlike other Cloud Providers, this directly reduces environment sprawl costs, which often exceed production waste post‑migration. It also enables wave‑based migration by lowering the cost of parallel environments, allowing teams to migrate deliberately rather than under financial pressure.

3. Azure Hybrid Benefit:
Azure Hybrid Benefit allows organizations to reuse existing Windows Server, SQL Server, and supported Linux subscriptions (RHEL and SLES) on Azure, reducing both migration and steady‑state run costs. It enables license portability across Azure services, helping organizations avoid repurchasing software licenses they already own and redirect savings toward innovation and modernization.

During migration, Azure Hybrid Benefit is especially impactful because it addresses migration overlap costs. The 180‑day migration allowance for Windows Server and SQL Server allows workloads to run on‑premises and in Azure simultaneously, supporting parallel validation, phased cutovers, and rollback readiness without double‑paying for licenses. For Linux, Azure Hybrid Benefit enables RHEL and SLES workloads to move to Azure without redeployment, ensuring continuity and avoiding downtime. From a FinOps perspective, this reduces one of the most underestimated migration cost drivers, delivering up to 76% savings versus pay‑as‑you‑go pricing for Linux and up to 29% versus leading cloud providers for SQL Server, while keeping migration timelines driven by readiness—not cost pressure.

4. Azure Reservations:
Azure Reservations enable organizations to reduce costs by committing to one‑year or three‑year plans for eligible Azure services, receiving a billing discount that is automatically applied to matching resources. Reservations provide discounts of up to 72% compared to pay‑as‑you‑go pricing, do not affect the runtime state of workloads, and can be paid upfront or monthly with no difference in total cost. Importantly, Azure Reservations apply not only to compute and database, but also to storage services like Azure Blob storage, Azure Data Lake Gen2 Storage and Azure Files (for storage capacity) which often represent a significant portion of enterprise cloud spend.

In the context of migration, Azure Reservations matter because they allow FinOps teams to optimize baseline costs across both compute and data layers once workloads stabilize. Unlike AWS, where commitment‑based discounts are largely compute‑centric and storage services such as Amazon S3 do not offer reservation‑style pricing, Azure enables long‑term cost optimization for persistent storage footprints that continue to grow post‑migration. Additionally, Azure Reservations offer greater flexibility—customers can modify, exchange, or cancel reservations through a self‑service program, subject to defined limits. This is particularly valuable during wave‑based migrations, where workload shapes evolve over time. From a FinOps perspective, Azure Reservations allow organizations to commit to predictable savings with broader scope and lower risk, covering both infrastructure and data‑heavy workloads common in migration scenarios.

Successful migrations are no longer measured by workloads moved, but by cost control maintained and value unlocked. Azure’s FinOps‑aligned migration capabilities allow organizations to reduce risk first, optimize deliberately, and ensure that savings are sustained long after the last workload migrates.

Autonomous Self-Healing for Azure VMware Solution Private Clouds

RohanB — Fri, 27 Mar 2026 23:51:43 GMT

Overview

Azure VMware Solution operates a global fleet of production private clouds, each running a full VMware NSX and vCenter Server control plane. As an example, when a VMware NSX Manager cluster loses quorum, NSX can surface multiple related alarms, but the documented impact is more specific than a single simultaneous cascade: management and control-plane updates stop, cluster health may degrade, and some Edge or transport-node symptoms can follow, while existing Tier-0 dynamic routing generally remains operational. In summary, multiple symptoms may share an upstream fault and must be verified against cluster status, service health, storage, Compute Manager state, and transport-node connectivity. Without a model encoding directional dependency relationships between those layers, the alarm set is structurally indistinguishable from multiple independent simultaneous failures. An operator who responds to each alarm independently extends the outage by re-traversing the same propagation path with each action.

At production scale, NSX fault propagation outpaces manual triage consistently. Azure VMware Solution Private Cloud Autonomous Self-Healing system is a closed-loop control architecture built to address this class of failure directly. The system correlates control-plane signals causally using a live runtime dependency graph, enforces a full policy gate stack before any automated action, acquires scoped mutual exclusion before execution begins, and verifies recovery independently before closing any incident. This article describes the architecture of the system and the design decisions that shaped it.

Architectural Components

Azure VMware Solution is a VMware validated first party Azure service from Microsoft that provides private clouds containing VMware vSphere clusters built from dedicated bare-metal Azure infrastructure. It enables customers to leverage their existing investments in VMware skills and tools, allowing them to focus on developing and running their VMware-based workloads on Azure.

The diagram below describes the architectural components of the Azure VMware Solution.

Figure 1 – Azure VMware Solution Architectural Components

Each Azure VMware Solution architectural component has the following function:

Azure Subscription: Used to provide controlled access, budget and quota management for the Azure VMware Solution.
Azure Region: Physical locations around the world where we group data centers into Availability Zones (AZs) and then group AZs into regions.
Azure Resource Group: Container used to place Azure services and resources into logical groups.
Azure VMware Solution Private Cloud: Uses VMware software, including vCenter Server, NSX software-defined networking, vSAN software-defined storage, and Azure bare-metal ESXi hosts to provide compute, networking, and storage resources. Azure NetApp Files, Azure Elastic SAN, and Pure Cloud Block Store are also supported.
Azure VMware Solution Resource Cluster: Uses VMware software, including vSAN software-defined storage, and Azure bare-metal ESXi hosts to provide compute, networking, and storage resources for customer workloads by scaling out the Azure VMware Solution private cloud. Azure NetApp Files, Azure Elastic SAN, and Pure Cloud Block Store are also supported.
VMware HCX: Provides mobility, migration, and network extension services.
VMware Site Recovery: Provides Disaster Recovery automation, and storage replication services with VMware vSphere Replication. Third party Disaster Recovery solutions Zerto DR and JetStream DR are also supported.
Dedicated Microsoft Enterprise Edge (D-MSEE): Router that provides connectivity between Azure cloud and the Azure VMware Solution private cloud instance.
Azure Virtual Network (VNet): Private network used to connect Azure services and resources together.
Azure Route Server: Enables network appliances to exchange dynamic route information with Azure networks.
Azure Virtual Network Gateway: Cross premises gateway for connecting Azure services and resources to other private networks using IPSec VPN, ExpressRoute, and VNet to VNet.
Azure ExpressRoute: Provides high-speed private connections between Azure data centers and on-premises or colocation infrastructure.
Azure Virtual WAN (vWAN): Aggregates networking, security, and routing functions together into a single unified Wide Area Network (WAN).

What Autonomous Self-Healing Delivers

Table I describes the five system-guaranteed correctness properties introduced by Autonomous Self-Healing. None of these properties existed within the Azure VMware Solution control-plane incident response path as system-enforced behaviors prior to this system.

Table I – System-Guaranteed Properties Introduced by Autonomous Self-Healing

Capability	What Autonomous Self-Heal Does	Prior State
Bounded, verifiable recovery time	Measures time from the first correlated signal to verified stable recovery.	Incidents closed on action completion vs recovery.
Signal integrity at ingestion	Normalizes events, deduplicates sources, and suppresses flapping before correlation.	No normalization pipeline existed. Engineers received the raw alarm stream and established cause through pattern recognition.
Policy-gated execution	Checks freeze windows, risk budgets, blast radius, rate limits, and approvals atomically before execution.	No single atomic gate stack consistently enforced limits or approvals.
Append-only incident evidence	Stores signals, topology, decisions, workflow trace, and verification in a structured record.	Evidence hosted across separate logs and non-trivial to replay.
Progressive trust model	Supports notify-only mode so operators can inspect detections and proposed actions before enablement.	Automation was binary — no mechanism to observe system behavior before granting execution authority.

Design Principles

Autonomous Self-Healing introduces the following seven design elements to Azure VMware Solution private cloud control-plane operations:

Three-plane separation (detection, decisioning, execution) isolating failure surfaces across the control loop
Live runtime dependency graph updated continuously from VMware NSX and vCenter Server event streams, replacing static rule sets that drift from actual topology
Three-input causal correlation model (evidence strength, temporal ordering, dependency directionality) distinguishing causal chains from coincident co-occurrence
Pre-execution blast-radius computation as a gate input, enabling proportional gate enforcement before any action is taken
Phase boundary model (stabilization, execution, verification) converting event-driven oscillation into a damped feedback loop with hysteresis
Execution contract structure (trigger, gate declaration, step specification, verification contract) enforcing scope validity and topology currency as system constraints
Unified append-only ledger producing identical records across automated and human-led resolution paths, enabling governance review and postmortem replay

For in-scope failures, the result is bounded, auditable recovery time — at any hour, without operator involvement. For in-scope failures where automated remediation cannot be authorized, the result is a deterministic evidence bundle replacing engineer recollection with a structured, replayable handoff.

Architecture: Detection, Decisioning, and Execution

Autonomous Self-Healing separates detection, decisioning, and execution into distinct planes with single, testable contracts between them. Coupling these functions — the simpler approach — shares a failure surface across all three: a bug in the execution engine can corrupt evidence the correlation model depends on; a spike in alarm volume can starve the gate evaluator; a misconfigured policy gate can block signal normalization. Separation eliminates these cross-contamination failure modes.

Detection plane: Transforms raw VMware NSX and vCenter Server alarm streams into stable, discrete incident candidates. The pipeline normalizes event formats across sources, collapses redundant signals, and applies a dwell window to filter transient state changes. Candidates crossing the plane boundary are confirmed, stable units — the only form the correlation model can process correctly.

Decisioning plane: Runs causal correlation against the live private cloud dependency graph before gate evaluation, producing a ranked root-cause hypothesis with confidence scores and a computed blast-radius estimate. The plane produces exactly one of two outputs: a gated authorization to execute, or an escalation with a complete evidence bundle.

Execution plane: Acquires a fencing token scoped to the smallest viable failure domain, runs a versioned idempotent checkpointed playbook, and closes the incident only after independent post-condition verification confirms stable recovery across a stability dwell window. Every state transition appends to the incident ledger.

Figure 2 – Detection, Decisioning, and Execution: Autonomous Self-Healing Control Loop

Incident Ledger

Autonomous Self-Healing produces a structured, append-only ledger for every incident regardless of resolution path. Five categories are captured in sequence: raw and normalized signals with suppression outcomes; a topology snapshot at detection time; the full decision record including correlation results, root-cause ranking, blast-radius estimate, and gate evaluation trace; the workflow trace with step metadata and lease identifiers; and the verification outcome with post-condition results and stability dwell disposition. Automated and human-led paths produce the same record structure — a governance requirement, not a design preference. The reconstruction is deterministic: given the same ledger, two reviewers reconstruct the same incident timeline.

Figure 3 – The Incident Ledger: Audit, Replay, and Governance

Summary

Autonomous Self-Healing handles a defined subset of NSX and vCenter control-plane failures within an Azure VMware Solution private cloud. The system does not handle data-plane failures, storage faults, hypervisor crashes, hardware failures, or control-plane failures outside its modeled dependency graph. It does not run arbitrary scripts, bypass RBAC controls, or override tenant isolation boundaries. Bounded scope is the source of trustworthiness within the system — a system attempting to remediate everything carries failure modes proportional to its reach. When Autonomous Self-Healing cannot act, the evidence bundle it produces provides a complete, structured handoff for operator response.

To learn more about Azure VMware Solution:

Author Bio

Rohan Bhosle is a Principal Software Engineering Manager within Microsoft Azure with more than 19+ years of experience leading deeply technical work in hyperscale cloud networking, distributed control planes, and large-scale AI infrastructure. Their background includes SDN, multi-tenant isolation and policy enforcement, datacenter and cloud network architecture, traffic engineering, routing, load balancing, telemetry, and large-scale reliability engineering and operations. Their work also includes networking infrastructure for hyperscale AI/GPU clusters, with a focus on the performance, resilience, and operational rigor needed to support next-generation AI systems.

Porting C++ from IBM Power to x86: Solving Silent Endianness Corruption with C++and Github Copilot

OsvaldoDaibert — Tue, 17 Mar 2026 07:36:07 GMT

Migrating C++ applications from IBM Power Systems to Azure x86 involves a subtle but critical architectural difference that is the byte order. When legacy code compiled for Big-Endian hardware is recompiled for Little-Endian x86 without modification, multi-byte integers silently corrupt. There are no compile errors, no runtime exceptions, just wrong values in production. This guide walks through the endianness challenge, demonstrates a practical refactoring workflow using GitHub Copilot, and provides a companion repository you can use immediately.

Why this migration is different

C++ code written for IBM Power (OS/400, IBM i) compiles for virtually every platform. The language is not the problem. The problem is how decades of development on a Big-Endian, vertically scaled, single-system architecture produced code that makes deep assumptions about byte order, memory layout, and OS-level services that do not exist on x86 Linux.

When that code is recompiled for x86 the architecture behind X86 binary data corruption is silent. A transaction ID that should be 1 becomes 16,777,216. An amount of $50.00 becomes $22 million. The code compiles cleanly, runs without exceptions, and produces confidently wrong results.

This is not a problem you can catch with a compiler upgrade or a static analysis pass. It requires systematic identification and refactoring of every point where the code reads or writes multi-byte binary data. Microsoft's Cloud Adoption Framework describes different migration strategies that could be rehosting, refactoring, and re-platforming. This migration falls squarely into refactoring: the code must change to run correctly on the new architecture.

Understanding the core problem: The Endianness

Endianness is the direction a CPU uses to store multi-byte data in memory. A 4-byte integer like 0x00000001 (decimal 1) can be stored two ways:

Big-Endian stores the most significant byte first: 00 00 00 01. This is how IBM Power Systems, mainframes, and network protocols (TCP/IP) store data.
Little-Endian stores the least significant byte first: 01 00 00 00. This is how Intel/AMD x86/x64 processors and Azure Virtual Machines store data.

Property	IBM Power (Source)	Azure x86 (Target)
Byte order	Big-Endian	Little-Endian
Text encoding	EBCDIC	ASCII / UTF-8
Architecture	RISC	CISC
Scaling model	Vertical	Horizontal
Compiler	IBM XL C/C++	GCC / Clang / MSVC
Primary OS	IBM i (OS/400)	Linux / Windows

The danger becomes clear when you look at how legacy code reads binary data. Consider a Point-of-Sale transaction record stored as a Big-Endian binary buffer, exactly as it would arrive from an iSeries flat file or Data Queue export:

// Simulated Big-Endian binary buffer from an OS/400 system:
const char buffer[] = {
    0x00, 0x00, 0x00, 0x01,         // txnId       = 1
    0x00, 0x00, 0x13, (char)0x88,   // amountCents = 5000 ($50.00)
    0x00, 0x64,                     // storeNumber = 100
    0x00, 0x07,                     // pumpNumber  = 7
    'V',  'I',  'S',  'A'          // cardType    = "VISA"
};

On an IBM Power system, reading these bytes directly into a struct produces the correct values. On x86, the same bytes produce:

Field	Expected value	x86 result	What happened
txnId	1	16,777,216	Bytes `00 00 00 01` read as `0x01000000`
amountCents	5000 ($50.00)	2,282,946,560 ($22.8M)	Bytes reversed
storeNumber	100	25,600	Bytes `00 64` read as `0x6400`
pumpNumber	7	1,792	Bytes `00 07` read as `0x0700`
cardType	VISA	VISA	Correct — char arrays are unaffected

Notice that cardType is correct. Single-byte data (character arrays, strings) is unaffected by endianness. Only multi-byte integers — uint32_t, uint16_t, int32_t, and similar types — are corrupted.

The three silent killers in cross-architecture migration

When moving C++ from a Big-Endian system to Azure, three issues surface:

Binary data corruption. Every memcpy or memmove that copies raw bytes into a struct containing multi-byte integer fields will produce wrong values on x86. This is the most common and most dangerous issue because it produces no errors, only silently incorrect results.

EBCDIC vs. ASCII text encoding. IBM i systems use EBCDIC encoding, where the letter A is 0xC1 instead of 0x41 (ASCII). When binary records contain both integer fields and text fields, the migration requires both byte-swapping for integers and character-set conversion for text. The iconv library handles this translation.

Struct padding differences. IBM XL C/C++ and GCC may pad struct members differently. A struct that is 16 bytes on one compiler might be 20 bytes on another if the compiler inserts alignment padding. A static_assert on the struct size catches this at compile time, before it causes data corruption in production.

A practical modernization workflow

The modernization follows a seven-step pipeline that takes existing C++ source compiled with IBM XL C/C++ on Big-Endian and produces a portable codebase that compiles with GCC or Clang on Linux x86:

Inventory. Identify all C++ source files that perform binary I/O, pointer arithmetic on multi-byte integers, or use IBM XL C++ extensions.
Refactor endianness. Insert portable byte-swap utilities at every point where the code reads or writes multi-byte binary data. Use if constexpr (std::endian::native == std::endian::little) so the swap is resolved at compile time with zero runtime cost.
Replace OS/400 APIs. Substitute IBM-specific system calls — Data Queues, User Spaces, Message Queues, record-level file access — with POSIX equivalents or standard C++ libraries.
Convert text encoding. Translate EBCDIC literals and data streams to UTF-8 using iconv or an equivalent library.
Recompile. Build the codebase with GCC or Clang using -std=c++20 (or later) and run the full test suite on an x86 Linux target.
Containerize. Package the compiled application into a Linux container image and push it to Azure Container Registry.
Deploy. Deploy the container to Azure Kubernetes Service (AKS) for horizontal scaling, or to Azure Virtual Machines for a single-partition replacement.

Choose a deployment model based on your scalability and operational requirements:

Deployment Model	Azure Service	Best For
Single VM	Azure Virtual Machines (Dv5 / Fsv2)	Direct replacement of the Power partition. Simplest path.
Containers	Azure Kubernetes Service (AKS)	Horizontal scaling, rolling updates, microservice decomposition.
Serverless Containers	Azure Container Apps	Event-driven workloads or APIs without managing Kubernetes.
Platform as a Service	Azure App Service (Linux)	Web-facing APIs with built-in TLS, autoscaling, deployment slots.

For high-volume transaction systems, AKS provides the best balance of performance, scalability, and operational control. Use Azure Monitor and Application Insights for observability once deployed.

Accelerating the refactoring with GitHub Copilot

Manually auditing every memcpy, every binary file read, and every pointer cast across a large codebase is slow and error-prone. GitHub Copilot changes the economics of this migration by identifying endianness-sensitive patterns and generating portable replacements.

The workflow is straightforward: select the legacy function in VS Code, prompt Copilot with the migration context, review the generated code, then compile and test on x86.

Before: Legacy OS/400 code

This is the standard OS/400 pattern for reading binary record buffers. The memcpy copies raw bytes directly into the struct with no byte-order conversion which works correctly on Big-Endian, but silently corrupts every integer field on x86:

void processTxn(const char* rawBuffer) {
    TxnRecord txn;

    // Direct memory copy — NO byte-order conversion.
    std::memcpy(&txn, rawBuffer, sizeof(TxnRecord));

    std::cout << "Txn ID     : " << txn.txnId       << "\n";
    std::cout << "Amount ($) : " << txn.amountCents / 100.0 << "\n";
    std::cout << "Store      : " << txn.storeNumber  << "\n";
    std::cout << "Pump       : " << txn.pumpNumber   << "\n";
}

Output on x86 (wrong):

Txn ID     : 16777216       ← should be 1
Amount ($) : 2.28295e+07    ← should be 50
Store      : 25600          ← should be 100
Pump       : 1792           ← should be 7

Copilot-generated portable byte-swap utility

When prompted, Copilot generates a pair of byte-swap functions that use C++20 std::endian for compile-time detection and compiler intrinsics for single-instruction byte reversal. The if constexpr check is resolved at compile time, there is no runtime branching cost:

#include <bit>  // C++20: std::endian

inline uint32_t fromBigEndian32(uint32_t v) {
    if constexpr (std::endian::native == std::endian::big)
        return v;  // No-op on Big-Endian hosts (zero overhead)

    #if defined(__GNUC__) || defined(__clang__)
        return __builtin_bswap32(v);
    #elif defined(_MSC_VER)
        return _byteswap_ulong(v);
    #else
        return ((v >> 24) & 0x000000FF)
             | ((v >>  8) & 0x0000FF00)
             | ((v <<  8) & 0x00FF0000)
             | ((v << 24) & 0xFF000000);
    #endif
}

inline uint16_t fromBigEndian16(uint16_t v) {
    if constexpr (std::endian::native == std::endian::big)
        return v;

    #if defined(__GNUC__) || defined(__clang__)
        return __builtin_bswap16(v);
    #elif defined(_MSC_VER)
        return _byteswap_ushort(v);
    #else
        return static_cast<uint16_t>((v >> 8) | (v << 8));
    #endif
}

After: Modernized code (correct on all platforms)

The refactored function keeps the same memcpy pattern preserving compatibility with existing binary data but adds byte-order conversion for every multi-byte integer field. Character arrays like cardType are left untouched because single-byte data is unaffected by endianness:

// Compile-time guard: catch unexpected padding
static_assert(sizeof(TxnRecord) == 16,
    "TxnRecord size mismatch — check struct alignment/padding");

void processTxn(const char* rawBuffer) {
    TxnRecord txn;

    // Step 1: Raw copy (identical to OS/400 code)
    std::memcpy(&txn, rawBuffer, sizeof(TxnRecord));

    // Step 2: Byte-order conversion — Big-Endian source → host order
    txn.txnId       = fromBigEndian32(txn.txnId);
    txn.amountCents = fromBigEndian32(txn.amountCents);
    txn.storeNumber = fromBigEndian16(txn.storeNumber);
    txn.pumpNumber  = fromBigEndian16(txn.pumpNumber);
    // cardType: char array — no conversion needed

    // Step 3: Process as normal
    std::cout << "Txn ID     : " << txn.txnId       << "\n";
    std::cout << "Amount ($) : " << txn.amountCents / 100.0 << "\n";
    std::cout << "Store      : " << txn.storeNumber  << "\n";
    std::cout << "Pump       : " << txn.pumpNumber   << "\n";
}

Output on x86 (correct):

Txn ID     : 1
Amount ($) : 50
Store      : 100
Pump       : 7

What Copilot changed

Step	What changed	Why
1	Added `#include <bit>`	Enables C++20 `std::endian` for compile-time detection
2	Created `fromBigEndian32()` and `fromBigEndian16()`	Portable byte-swap using compiler intrinsics
3	Inserted swap calls after `memcpy`	Converts Big-Endian source data to host byte order
4	Skipped `cardType`	Single-byte sequences are unaffected by endianness
5	Added `static_assert` on struct size	Catches compiler padding mismatches at compile time

What to watch for

Three gotchas that Copilot alone will not catch:

Packed decimals (COMP-3). IBM-specific encoding where each byte holds two digits plus a sign nibble. This is not an endianness issue, it requires a dedicated parser. If your codebase processes COBOL-originated data, you will encounter this.
EBCDIC text in the same pipeline. When a binary record contains both integers and EBCDIC text, you need byte-swapping and character-set conversion in the same processing function. Prompt Copilot separately for an EBCDIC-to-UTF-8 utility.
Struct padding. IBM XL C++ and GCC may pad struct members differently. Always add a static_assert(sizeof(YourStruct) == expected_size) to catch mismatches at compile time rather than in production.

Try it yourself

A companion repository contains the complete working example, both the legacy code that demonstrates the bug and the modernized code that fixes it:

github.com/odaibert/os400-cpp-modernization

The repository includes:

Before/after C++ source code: compile and run both to see the bug and the fix side by side
Solution guide: endianness theory, architecture mapping, Azure deployment options, VM sizing tables, and Well-Architected Framework considerations
Copilot modernization guide: step-by-step walkthrough with ready-to-use prompts
Replication task plan: 11 tasks to reproduce the entire solution from scratch in approximately two hours

Build and run:

g++ -std=c++17 -o pos_legacy  src/pos_transaction.cpp
g++ -std=c++20 -o pos_modern  src/pos_transaction_x86.cpp
./pos_legacy    # wrong output on x86
./pos_modern    # correct output

Final thoughts

Modernizing Big-Endian C++ for x86 is a solvable problem when approached systematically. The endianness bug is silent and insidious, but the fix portable byte-swap utilities with compile-time detection is well understood and adds zero runtime overhead. The combination of modern C++20 patterns and GitHub Copilot-assisted refactoring compresses what would otherwise be months of manual audit into an accessible, repeatable workflow.

For organizations planning this migration, Azure Accelerate provides expert guidance, and the Cloud Adoption Framework offers a structured planning methodology.

Share your experiences in the comments. Have you migrated workloads from IBM Power or mainframe environments to Azure? What strategies worked? What challenges did you encounter? Your insights help others navigate similar journeys.

If specific aspects of this migration are unclear or you would like deeper exploration of particular topics like packed decimal handling, EBCDIC conversion pipelines, or container deployment patterns let me know. The best content comes from addressing real practitioner needs.

#Azure #CloudMigration #Modernization #CPlusPlus #GitHubCopilot #IBMPower #OS400 #Endianness #AzureMigration #TechCommunity

Azure Copilot Migration Agent

shashban — Thu, 12 Mar 2026 17:21:59 GMT

Migration and modernization are complex, involving multiple decisions that determine cost, risk, and long‑term success. The timelines stretch and momentum is lost due to fragmented tools and manual planning. For most organizations, this is a continuous motion driven by shifting demands, security pressures, and the need to innovate faster without disrupting what already works.

With the release of Azure Copilot Migration Agent, this process is now guided and accelerated with insight‑driven decisions. The migration agent collaborates with GitHub Copilot to support faster and at-scale modernization.

Migration Agent delivers three core capabilities that simplify and accelerate migration planning.

Confidence before you move: Quick Insights without exposure

A successful transformation starts with clarity. Discovering a large enterprise environment is often challenging in the early stages of migration when traditional discovery tools require network changes or direct connectivity to Azure. These prerequisites can slow down projects before they begin.

The Migration Agent facilitates agentless discovery of VMware environment, delivering comprehensive insights without the need for intrusive appliances or exposure of sensitive networks. Azure Migrate Collector (also in public preview) supports inventory collection without requiring direct connectivity to Azure. Operating locally, the collector identifies servers, workloads, and performance metrics from the environment, and packages this data for import in Azure Migrate.

Conversational analysis and categorization of discovered infrastructure, databases, and web applications make it much easier to understand the overall estate and see how these elements function as business systems.

Within hours, business leaders receive 6R recommendations based on real environmental data, enabling confident decisions. Right-sizing ensures Azure solutions match performance and budget needs, while modernization recommendation identifies opportunities for cloud-native optimization.

Execution at scale: Speed with governance built in

Clear insights drive successful execution. Building a secure, compliant Azure foundation is often one of the biggest migration blockers. The Migration Agent accelerates setting up the foundation by automating platform landing zone creation, aligned with Microsoft’s Cloud Adoption Framework and other best practices. It configures networking, identity, policies, and resources. Using the Migration Agent or Azure MCP Server, the generated templates can be understood for otherwise overwhelming concepts and edited for custom requirements.

Structured wave plans allow prioritized sequencing of workloads and applications, ensuring predictable execution with progress tracking and rollback. The agent coordinates handoffs between infrastructure, database, application, and security teams, keeping humans involved throughout the process.

Modernization without handoffs: Secure flow to developers

Through the Migration Agent, Azure Migrate securely invokes relevant tools at the right juncture, including GitHub Copilot for application modernization. Developers can plan upgrades conversationally, generate code and automate routine modernization tasks across .NET, Java and cloud-native workloads without breaking the flow between assessment and execution.

Integrations with tools like CAST Highlight provide deeper analytics to target the right refactors and reduce modernization risk. Instead of a one-time migration event, modernization becomes a continuous, developer-centered loop; compressing timelines while improving application quality.

Get started today

Azure Copilot migration agent and the Azure Migrate Collector are now publicly available. Start using it to simplify and guide your migration process.

Simply open Azure Migrate in the Azure portal and click on accelerate migration.
Note: You need to enable Agent’s preview in Azure Copilot to use the Azure Copilot migration agent. Learn more

Learn more about Azure Migrate and for expert migration help, please try Azure Accelerate.

Migrating Workloads from AWS to Azure: A Structured Approach for Cloud Architects

rhack — Thu, 19 Feb 2026 06:52:01 GMT

The core migration principle: Like-for-like architecture

The foundation of a successful migration is maintaining a like-for-like architecture during the transition. This means replicating your existing AWS architecture on Azure with equivalent services, preserving the same operational patterns, performance characteristics, and the same known issues that exist today.

This approach may seem counterintuitive. Why migrate if you're not modernizing? The answer lies in risk management. If you attempt to modernize during migration, you introduce potential scope creep, increase complexity, and erode confidence in the workload. Once the workload is stable on Azure and meeting the same KPIs it achieved on AWS, you can pursue optimization and technical debt reduction from a position of stability.

The five-phase migration lifecycle

Successful AWS-to-Azure migrations follow a structured five-phase approach, with each phase building on the previous one:

Phase 1: Plan

The planning phase is where migrations succeed or fail. Incomplete discovery or unclear migration objectives risk misaligned expectations and missed dependencies.

Automated discovery tools provide a starting point, but they cannot capture everything. Subject matter experts throughout your workload team must be engaged to identify critical components that tools often miss—scheduled scripts, undocumented integrations, legacy configurations, and authentication dependencies.

Essential planning deliverables include:

Complete workload architecture documentation with all dependencies mapped
Authentication and authorization configuration details
Performance baselines covering throughput, latency, and error rates
Current monitoring and alerting configurations
Rollback trigger criteria, not just rollback procedures

Service mapping decisions during this phase determine the Azure services that will replace each AWS component. For example, AWS RDS may map to Azure SQL Database or Azure Database for PostgreSQL, while AWS Lambda functions typically map to Azure Functions.

Migration strategy selection is critical. The recommended approach for most workloads is blue/green deployment, where both AWS (blue) and Azure (green) environments run in parallel. While this incurs costs for both cloud providers during the transition, the reduction in risk and operational burden typically justifies the expense.

Migration Strategy	Downtime	Risk Level	Rollback Capability
Big Bang	High	High	Difficult
Phased	Low	Medium	Moderate
Blue/Green	Low	Low	Easy

Phase 2: Prepare

The preparation phase is where readiness becomes tangible. Any misconfigured infrastructure, insufficient testing, or lack of team readiness can result in delays, security vulnerabilities, or failed deployments during execution.

Critical preparation activities:

Infrastructure deployment should use Infrastructure as Code (IaC) to ensure consistency and repeatability. Whether using Bicep, Terraform, or ARM templates, codified infrastructure reduces human error and provides a reliable deployment mechanism.

CI/CD pipeline updates must target Azure while maintaining the ability to deploy to both AWS and Azure during the transition period. This dual-deployment capability is essential for blue/green execution.

Code refactoring involves replacing AWS-specific libraries and SDKs with Azure equivalents or platform-agnostic alternatives. This includes updating AWS SDK calls, replacing CloudWatch logging with Application Insights, and adjusting any AWS-specific service integrations.

Testing with Azure Chaos Studio helps simulate potential faults such as VM failures, network outages, or service disruptions. This proactive testing identifies weaknesses before they impact production.

Operations team preparation requires implementing Azure Monitor and Application Insights with dashboards and alerts equivalent to the AWS CloudWatch setup. Operations engineers must be comfortable with Azure's monitoring tools before cutover.

Phase 3: Execute

The execution phase carries the highest risk of service disruption. Data synchronization issues, network misconfigurations, or unexpected application behaviors can cause outages or data loss.

Your detailed migration runbook becomes the operational guide during this phase. It should define step-by-step procedures, validation checkpoints, and clear rollback criteria.

During cutover execution:

Maintain a real-time health dashboard using Azure Monitor or custom telemetry, actively monitored by the migration team and operations engineers
Keep rollback readiness by maintaining the AWS environment in its pre-migration state throughout your validation window
Ensure stakeholder communication about cutover progress, any timeline impacts, and validation results

Post-cutover verification is not optional. Before declaring success, run regression tests, monitor costs and usage patterns, and ensure all monitoring signals are healthy. Only after thorough validation should you consider the migration complete.

Phase 4: Evaluate

Migration completion and validation completion are not the same thing.

Comprehensive validation includes:

Baseline comparison against the performance metrics documented during planning—throughput, latency, error rates, and resource utilization. The migrated workload should meet or exceed AWS performance.

Cutover validation via AWS CloudTrail logs ensures no unintended workload traffic continues hitting AWS services. This verification confirms the migration is truly complete.

Data cutover confirmation involves stopping continuous replication once Azure holds the authoritative copy of all data. Until this point, data consistency between environments must be maintained.

Operational validation includes performing key management operations such as certificate rotation, backup procedures, and incident response to confirm the operations team has sufficient control.

Formal sign-off should only occur after meeting all predefined success criteria established during the planning phase.

Post-mortem sessions capture lessons learned, discuss what worked well and what could improve, and share findings with other teams planning migrations. These insights become organizational knowledge.

Phase 5: Decommission

The decommissioning phase is often overlooked, yet premature deletion of AWS resources, overlooked dependencies, or insufficient final checks risk data loss, unexpected downtime, or ongoing costs from orphaned assets.

Essential decommissioning steps:

Final backups and snapshots should be taken for archival purposes before any resource deletion.

AWS Config inventory helps ensure no workload-related resources remain active and accruing costs. Orphaned resources—unused volumes, snapshots, or networking components—are common oversights.

Establish a new performance baseline for the Azure-hosted workload, reflecting its steady-state behavior. This baseline will guide future capacity planning and optimization.

Azure Well-Architected Framework Review provides a structured assessment across reliability, security, performance efficiency, cost optimization, and operational excellence. This baseline identifies opportunities for future improvements.

Retire AWS monitoring by removing CloudWatch alarms, dashboards, and logging configurations once you've confirmed all critical monitoring has shifted to Azure.

Who should perform the migration?

A principle often violated in practice: the workload team currently responsible for the workload in AWS and who will ultimately own it in Azure should perform the migration.

Outsourcing the entire migration to external resources can lead to:

Surprise discoveries late in the process when the workload team finally engages
An under-trained workload team inheriting a system they don't understand
A loss of ownership and accountability

The recommended model: External partners with Azure expertise, such as System Integrators or Microsoft's Industry Solutions Delivery team, can lead planning and preparation activities, develop runbooks, and build automation. However, the workload team should execute the production cutover using these partner-developed assets. This approach transfers knowledge while leveraging specialized expertise.

Setting realistic expectations

Migrations require work, coordination, and cooperation across teams. Late-hour verification sessions and unexpected challenges are part of the process.

Success requires:

A concrete, well-documented plan with clear objectives
Relevant stakeholders aligned and committed
A solid target architecture based on like-for-like principles
The right migration strategy for each workload component
A phased approach with clear validation checkpoints

Leverage available expertise. Whenever possible, engage colleagues or Microsoft experts who have successfully migrated AWS workloads to Azure. Their experience helps navigate challenges and adopt proven practices.

Final thoughts

Migrating from AWS to Azure is a strategic initiative requiring careful planning and stakeholder alignment. Without proper preparation, you risk introducing disruption that erodes confidence in your workload.

When executed properly, using a like-for-like architecture, blue/green deployment, comprehensive testing, and operational readiness, migrations can be completed confidently with mechanisms in place to handle issues as they arise.

After successful migration and decommissioning, take time to celebrate the achievement. Then begin the optimization journey.

Modernizing for the AI Era: Accelerating Application Transformation with Agentic Tools

MarcoB — Thu, 12 Feb 2026 23:41:09 GMT

Organizations are entering a new phase of digital transformation where AI is not simply an enhancement—it is a fundamental change in how applications are designed, delivered, and operated. Yet many companies still rely on aging, monolithic, or poorly documented applications that were never built to work in an AI‑driven, cloud‑optimized world. Modernization is no longer optional; it is the prerequisite to participating in the next generation of intelligent app development.

The data underscores this urgency. McKinsey estimates that organizations lose up to $85 billion annually due to delayed modernization and accumulated technical debt.⁽¹⁾ Gartner reports that 40% of developer time is consumed maintaining legacy systems instead of building new capabilities.⁽²⁾ IDC notes that up to 66% of IT budgets intended for innovation get diverted to keeping legacy systems alive.⁽³⁾ In the AI era, this drag on innovation has become untenable.

Why Legacy Applications Hold Organizations Back

Legacy systems often carry years—even decades—of accumulated complexity. Common challenges include:

Outdated frameworks and dependencies that no longer align with modern platforms
Code written by former employees, often without meaningful documentation
Institutional knowledge gaps that leave critical workflows understood by only a few
Fragile integrations that break when making even minor changes

These barriers historically slowed modernization efforts and increased project risk. But AI is uniquely suited to overcoming this complexity. With the ability to analyze large codebases, identify patterns, infer missing context, and propose safe transformation steps, AI agents can accelerate modernization in ways that were not possible with human effort alone.

Agentic Tools: A New Model for Modernization

Emerging agentic tooling from Microsoft is reshaping how organizations approach modernization—reducing timelines from months or years to weeks, while increasing accuracy, safety, and consistency.

GitHub Copilot: End‑to‑End Application Modernization Assistance

GitHub Copilot has expanded far beyond code suggestions. It now acts as a modernization partner capable of:

Analyzing entire codebases to identify outdated libraries, frameworks, and APIs
Guiding applications through platform upgrades (e.g., .NET Framework to .NET 8, Java to Java 21+)
Automating routine modernization tasks such as generating Dockerfiles and cloud‑ready configurations
Detecting security vulnerabilities and recommending or applying fixes
Helping generate CI/CD pipelines for GitHub Actions or Azure DevOps
Providing step-by-step refactoring guidance via explainable pull requests

This agentic model keeps developers fully in control while dramatically reducing manual toil.

Azure Migrate: Intelligent Discovery and Cloud Planning

Modernization starts with understanding what exists across datacenters, and Azure Migrate now brings AI-powered discovery and planning to the forefront. Its capabilities include:

Agentless discovery of servers, VMs, databases, and applications across environments
Automated mapping of application dependencies using network, process, and identity telemetry
Cloud readiness assessments identifying required updates or risk factors
Azure landing zone recommendations aligned to the Cloud Adoption Framework (CAF)
Automatically generated infrastructure-as-code templates (ARM/Bicep/Terraform)
AI‑driven migration sequencing ("waves") based on complexity and business impact

This turns previously manual and error‑prone planning into a predictable, data‑driven process.

Azure Copilot: AI for Cloud Operations

Azure Copilot—announced at Microsoft Ignite—extends agentic intelligence into day‑to‑day cloud management. It assists with optimization, governance, performance insights, and configuration recommendations, creating a more seamless journey from migration to ongoing operations.

Modernization Results Already Emerging

Modernization projects supported by agentic tools are showing substantial measurable improvements:

Application upgrade cycles reduced by factors of 3× to 4× when using AI‑generated upgrade plans and commit suggestions⁽⁴⁾
Organizations reducing manual modernization effort by 60–70%, especially in Java/.NET and middleware migrations⁽⁵⁾
Startups and small engineering teams cutting migration and refactoring workloads by over 60%, enabling them to focus on innovation⁽⁶⁾

These results reflect a broader global trend: AI is compressing modernization timelines significantly while increasing quality and safety.

Why Agentic DevOps Represents the Next Evolution

Modernization, development, and operations have historically been separate motions. Agentic tools collapse these gaps by enabling:

Speed – Automated analysis, test generation, and upgrade planning shorten modernization cycles
Safety – Guardrails such as static analysis, dependency checks, and automated testing reduce risk
Consistency – Best practices are embedded directly into AI agents, making modernization more repeatable
Accessibility – Teams without deep cloud-native or refactoring expertise can modernize confidently
Developer empowerment – Engineers focus on design, architecture, and innovation instead of rote tasks

The result is a new pattern: modernization becomes a continuous, iterative capability—not a one‑time, multi‑year project.

Get Started: Practical Next Steps

Organizations ready to accelerate modernization can begin with the following actions:

Explore modernization learning paths on Microsoft Learn:
https://learn.microsoft.com/training/topics/azure-migration/
Run an Azure Migrate discovery assessment to build a complete inventory and readiness report
Pilot GitHub Copilot modernization assistance on a non‑critical application
Develop or refine your Azure landing zone using CAF-aligned templates
Build team skills through certifications such as:
- Azure Solutions Architect
- Azure DevOps Engineer

Modernizing for the AI era doesn’t have to be overwhelming. With agentic tools across GitHub and Azure, organizations can modernize rapidly, safely, and at scale—unlocking the foundation required to build the next generation of intelligent applications.

References

McKinsey Digital — The Case for Modernizing IT & the Cost of Tech Debt
https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/the-case-for-modernizing-it
Gartner — Top Trends Impacting Infrastructure & Operations
https://www.gartner.com/en/articles/top-trends-impacting-infrastructure-and-operations
IDC — The Cost of Legacy Systems in the Age of AI
https://www.idc.com
Microsoft Developer Blogs — Modernizing .NET Applications with AI‑Driven Tools
https://devblogs.microsoft.com/dotnet
Microsoft Customer Stories — Automating Middleware and Application Modernization
https://customers.microsoft.com
Azure Migration Case Studies — Startup Migration Acceleration Using AI Tools
https://customers.microsoft.com

Azure Landing Zone and compliance for Banks (Indian Banks)

srhulsus — Thu, 12 Feb 2026 23:41:04 GMT

1. Azure Landing Zone for Banks

Azure Landing Zone (ALZ) is a predefined, policy-driven cloud foundation that enables banks to securely host regulated workloads while meeting governance, security, audit, and compliance mandates.

Core ALZ Principles

Subscription isolation by environment and risk tier
Centralized identity and access management
Hub-and-Spoke network architecture
Security-by-default with Zero Trust
Policy-as-code enforcement
Full auditability and traceability

2. Reference Architecture (Banking Grade)

Management Group Hierarchy

Root Management Group (Bank)
Platform MG

o Connectivity Subscription

o Security Subscription

o Management Subscription

Landing Zone MG

o Production Subscriptions

o Non-Production Subscriptions

o DR Subscriptions

Compliance Value: Enforces segregation of duties, blast-radius containment, and audit scope isolation.

3. Identity & Access Management (IAM)

Azure Services

Microsoft Entra ID (Azure AD)
Privileged Identity Management (PIM)
Conditional Access
MFA (Mandatory)

Compliance Mapping

Regulation	Requirement	Azure Control
ISO 27001 A.9	Access control	RBAC, PIM
PCI-DSS 7 & 8	Least privilege, MFA	Entra ID, CA
FFIEC	Strong authentication	MFA, PIM
RBI	Role-based access	RBAC, CA

4. Network Security Architecture

Mandatory Controls

Hub-Spoke VNets
Azure Firewall Premium (IDPS, TLS inspection)
NSGs + UDRs
Azure DDoS Protection Standard
Private Endpoints for PaaS
No direct internet exposure to core workloads

Compliance Mapping

Regulation	Requirement	Azure Control
ISO 27001 A.13	Network security	Firewall, NSG
PCI-DSS 1	Network segmentation	Hub-Spoke
FFIEC	Perimeter defense	Firewall, WAF
RBI	Secure network zoning	Hub-Spoke

5. Data Protection & Cryptography

Azure Services

Azure Key Vault (HSM-backed)
Customer Managed Keys (CMK)
Encryption at Rest & Transit
Azure Disk Encryption

Compliance Mapping

Regulation	Requirement	Azure Control
ISO 27001 A.10	Cryptography	Key Vault
PCI-DSS 3	Cardholder data encryption	CMK
FFIEC	Key management	HSM
RBI	Bank-owned keys	CMK

6. Logging, Monitoring & SIEM

Azure Services

Azure Monitor
Log Analytics
Microsoft Sentinel
Defender for Cloud

Controls Implemented

Centralized log retention (minimum 1 year)
Immutable audit logs
Real-time security alerts
Integration with Bank SOC/SIEM

Compliance Mapping

Regulation	Requirement	Azure Control
ISO 27001 A.12	Logging & monitoring	Azure Monitor
PCI-DSS 10	Audit logging	Sentinel
FFIEC	Continuous monitoring	SIEM
RBI	Incident reporting	Sentinel

7. Vulnerability Management & Threat Protection

Azure Services

Microsoft Defender for Cloud
Vulnerability Assessment
Azure Update Manager

Compliance Mapping

Regulation	Requirement	Azure Control
ISO 27001 A.12.6	Vulnerability mgmt	Defender
PCI-DSS 11	Regular testing	VA
FFIEC	Threat detection	Defender
RBI	Cyber resilience	Defender

8. Business Continuity & Disaster Recovery

Azure Services

Azure Site Recovery (ASR)
Azure Backup
Multi-region deployment (India regions)

Controls

Defined RPO/RTO per application
DR drills (minimum annually)
Separate DR subscriptions

Compliance Mapping

Regulation	Requirement	Azure Control
ISO 27001 A.17	BC/DR	ASR
PCI-DSS	Availability	Multi-region
FFIEC	Resilience testing	DR drills
RBI	BCP compliance	ASR

9. Data Residency & Sovereignty (India)

Controls

Deployment restricted to Azure India regions
Azure Policy to block non-India regions
Geo-redundancy within India only
Controlled cross-border access

RBI Alignment: Data localization, supervisory access, audit rights.

10. Governance, Policy & Compliance Automation

Azure Services

Azure Policy
Policy Initiatives (Regulatory Compliance)
Azure Blueprints (where applicable)

Examples

Deny public IP on VMs
Enforce encryption
Enforce diagnostic logging
Restrict SKU usage

11. Audit, Regulatory & Supervisory Access

Controls

Read-only auditor access via RBAC
Exportable logs and reports
Documented HLD/LLD
Support for RBI / CERT-In audits

12. Exit Management & Data Destruction

Controls

VM export (VHD)
Secure wipe (NIST-aligned)
Certificate of data destruction
Knowledge transfer

13. Summary – Why Azure Landing Zone for Banks

Microsoft CAF-aligned architecture
Regulator-accepted controls
India data residency
Strong audit and exit posture
Proven adoption by Tier-1 banks

Azure Arc Portal Update: Simplifying Onboarding and Management at Scale

MarcoB — Fri, 16 Jan 2026 22:44:00 GMT

Azure Arc extends Azure’s powerful capabilities to resources running outside Azure - across on-premises, multi-cloud, and edge environments. The Azure Arc portal acts as the central hub for discovering, onboarding, organizing, and managing these external resources just like native Azure assets.

As hybrid and multi-cloud adoption accelerates, we know that simplicity and clarity are critical. That’s why we’ve focused on making the Azure Arc experience more intuitive and actionable. Today, we’re excited to introduce a major refresh of the Azure Arc portal, designed to make it easier to get started, onboard resources, and manage your Arc-enabled environments at scale.

What’s New in the Azure Arc Portal?

Improved Learnability & Discoverability

Getting started with Azure Arc used to feel complex because of the wide range of supported resource types and onboarding methods. We’ve addressed this challenge with a redesigned experience:

Redesigned Landing Page: The new portal makes onboarding options easier to compare side by side, so you can quickly identify the path that best fits your scenario.

Guided Onboarding: A short, interactive questionnaire now provides tailored recommendations based on your needs - whether you’re onboarding just a few machines or scaling across multiple environments. This creates a more contextual and user-friendly entry point that helps you move from exploration to onboarding with confidence.

Refreshed Navigation: Based on research into the most common jobs users are trying to accomplish, we reorganized the menu bar into clearer groups. This makes navigation more intuitive and helps you discover key Arc capabilities faster.

Unified Machine Onboarding

Previously, onboarding existing servers or virtual machines required choosing from five different methods - often before knowing which was right for your scenario. We’ve streamlined that experience:

Single, Unified Onboarding Flow: Instead of asking you to make decisions upfront, the new flow captures contextual information along the way. This results in a more consistent and intuitive onboarding experience that works smoothly across all machine types and environments.

More Actionable Arc Portal Dashboards

Once your resources are onboarded, managing them effectively is the next step. Our dashboards have been redesigned to move beyond simple visibility and provide actionable insights:

Adaptive Summary: Service capability cards now respond to your current configuration and surface smart call-to-action prompts to guide you forward in your Arc journey.

Actionable Control Panel: Tiles for Agent Connectivity, Secure Score, and Policy Compliance have been updated for better readability and faster interpretation. Enhanced call-to-action logic transforms the Control Panel into a true action center - helping you quickly move from visibility to meaningful action.

Why This Matters

Hybrid and multi-cloud environments are inherently complex, but managing them doesn’t have to be. These updates make Azure Arc onboarding and management more intuitive, actionable, and scalable, so you can focus on delivering business value instead of wrestling with complexity.

Ready to Explore?

Sign in to the Azure Arc portal to experience the latest updates. For additional guidance, visit the Azure Arc documentation or start with the Plan and deploy Azure Arc-enabled servers at scale

Key Considerations for Modernizing and Migrating Custom Applications to Azure

srhulsus — Fri, 12 Dec 2025 18:04:26 GMT

Understanding the Current Application

A detailed understanding of the existing application is the foundation of a successful migration. Azure Migrate helps discover servers, databases, dependencies, and performance characteristics. It gives insight into everything that must be moved and modernized.
Documentation: https://learn.microsoft.com/azure/migrate/migrate-overview

This step reveals performance bottlenecks, outdated libraries, legacy integrations, and security gaps that need attention during modernization.

Selecting the Right Migration Approach

Once the current state is clear, the next step is to decide how each component should move to Azure. Some workloads can be rehosted on Azure Virtual Machines, while others benefit from modernization using App Services, Kubernetes, serverless functions, or managed databases. The Azure Migration Guide helps map applications to the right strategy.

Microsoft provides guidance through the Azure Migration Guide in the Cloud Adoption Framework.
Documentation: https://learn.microsoft.com/azure/cloud-adoption-framework/migrate/azure-migration-guide

This framework helps you evaluate whether the application should be rehosted, refactored, rearchitected, rebuilt, or replaced.

Modernizing the Application Layer

Azure App Service is a good option for hosting websites and APIs with minimal operational overhead. Azure Kubernetes Service (AKS) supports microservices and container-based applications with strong orchestration capabilities. Azure Functions are helpful for serverless or event-driven workloads.

Azure App Service documentation: https://learn.microsoft.com/azure/app-service/

AKS documentation: https://learn.microsoft.com/azure/aks/
Azure Functions documentation: https://learn.microsoft.com/azure/azure-functions/

Choosing the right compute platform improves scalability, security, and performance.

Migrating and Modernizing Databases

Azure offers several modern database services, including Azure SQL Database, Azure SQL Managed Instance, Azure PostgreSQL, and Cosmos DB. These services reduce administrative overhead and offer built-in high availability. Database Migration Service helps automate schema conversion and data transfer.

Azure Database Migration Service helps streamline schema conversion and data movement.
Documentation: https://learn.microsoft.com/azure/dms/dms-overview

After migration, it is important to validate schema integrity, perform performance testing, and confirm that the application works properly with the new database.

Designing a Secure Cloud Architecture

Security must be at the center of the design. Managed Identities remove the need for storing credentials. Azure Key Vault protects secrets and encryption keys. Defender for Cloud improves security posture and provides threat detection.

Managed Identities documentation:
https://learn.microsoft.com/azure/active-directory/managed-identities-azure-resources/

Key Vault documentation: https://learn.microsoft.com/azure/key-vault/

Defender for Cloud documentation: https://learn.microsoft.com/azure/defender-for-cloud/

A secure application also depends on strong network design. Azure provides tools such as Virtual Networks, Private Endpoints, Network Security Groups, Application Gateway, and Azure Firewall.
Network security guidance: Best practices for network security - Microsoft Azure | Microsoft Learn

Planning for High Availability and Resilience

Moving to Azure gives you the ability to build highly resilient applications. Availability Zones help protect the application from failures in a single data center. Azure Load Balancer and Application Gateway help distribute traffic between instances. Geo-replication keeps data available even during regional disruptions.

Resilience guidance:
https://learn.microsoft.com/azure/architecture/framework/resiliency/overview

Adding retry logic and resilience patterns in the application code ensures that the app can recover from intermittent failures.

Adopting DevOps and Continuous Delivery

Azure integrates well with DevOps practices. GitHub Actions and Azure DevOps Pipelines allow applications to be built, tested, and deployed automatically. Infrastructure can be deployed consistently using Terraform, Bicep, or ARM templates.

Azure DevOps Pipelines documentation:
https://learn.microsoft.com/azure/devops/pipelines/

Automated deployments make it easier to maintain quality and reduce human error during rollouts.

Monitoring, Logging, and Observability

Once the application is running in Azure, monitoring becomes an essential part of operations. Azure Monitor provides metrics and alerting. Application Insights captures performance, tracing, and error data. Log Analytics offers centralized log storage and analysis.

Observability overview:
https://learn.microsoft.com/azure/azure-monitor/

Strong observability ensures issues can be detected early and resolved quickly.

Managing Cost and Governance

Governance is important for long-term cloud success. Azure Policy helps enforce compliance and security standards. Tagging strategies support better organization and cost tracking. Azure Cost Management provides visibility into spending and suggests optimization areas.

Governance documentation:
https://learn.microsoft.com/azure/governance/policy/overview

Using budgets, alerts, and resource organization strategies helps control costs and keeps the environment manageable.

Testing, Cutover, and Post-Migration Optimization

Before switching to production, performance testing, load testing, functional validation, and security scanning should be completed. Azure Load Testing and various open-source tools can help simulate traffic. Once the application is ready, a cutover plan ensures a smooth transition, and a rollback plan prepares the team for unexpected issues.

After going live, ongoing optimization helps improve reliability, reduce cost, and modernize additional parts of the application. Azure’s cloud-native services, such as Service Bus, Event Grid, and Azure AI Studio, can be added to enhance the application further.

Using AI to Improve and Accelerate Azure Migrations

AI can significantly improve the migration journey. It can help automate analysis, enhance decision-making, detect issues early, and modernize application architecture.

Modernizing with AI begins in the assessment stage. Tools like Azure Migrate now include intelligent insights that recommend the right VM sizes, storage tiers, or modernization paths based on workloads. These recommendations are driven by data collected from on-premises systems, helping teams make more accurate decisions. Azure Advisor also uses AI to suggest performance, cost, and reliability improvements after workloads move to Azure.
Documentation: https://learn.microsoft.com/azure/advisor/advisor-overview

AI can also support code modernization. GitHub Copilot helps engineers refactor legacy code, containerize applications, and rewrite outdated components faster and with fewer errors. This is especially useful when moving monolithic applications into microservices or serverless models.

During database modernization, Azure SQL and Cosmos DB use built-in intelligence to index data, tune queries, detect anomalies, and improve performance autonomously.
Azure SQL Intelligent Performance: Automatic Tuning Overview - Azure SQL & SQL database in Fabric | Microsoft Learn

AI improves security as well. Microsoft Defender for Cloud and Sentinel use machine learning to detect unusual behavior, misconfigurations, and threats. This is helpful during migration because legacy apps often contain hidden vulnerabilities.

Sentinel documentation: https://learn.microsoft.com/azure/sentinel/

AI can also support testing and validation by generating synthetic test data, predicting performance bottlenecks, and analyzing logs during trial runs.

In operations, AI-based monitoring in Azure Monitor and Application Insights helps detect anomalies earlier and automatically pinpoint the root cause of issues. This reduces downtime and simplifies troubleshooting.

AI-enabled migration accelerators and copilots across Azure, GitHub, and Visual Studio help teams modernize faster, reduce manual effort, and improve the accuracy of the migration plan.

Migrate from Amazon API Gateway to Azure API Management

dan_lepow — Thu, 04 Dec 2025 21:23:07 GMT

For teams moving from Amazon API Gateway to Azure API Management, we've published a detailed migration guide that addresses the technical considerations and implementation steps for a successful transition: Migrate Amazon API Gateway to Azure API Management.

The guide focuses on helping AWS users map their existing API Gateway configurations to equivalent Azure API Management capabilities while highlighting architectural differences and best practices for the Azure platform.

What the guide covers:

✅ Detailed feature mapping

We provide extensive mapping tables across three categories: infrastructure capabilities, API workloads, and API configurations. For example, you'll find mappings for network isolation (VPC endpoints to virtual networks), WAF integration, custom domains, and observability (CloudWatch to Azure Monitor). For workloads, the guide addresses Lambda proxy integrations, REST APIs, and HTTP APIs. Configuration mappings include stage variables, caching, throttling, CORS, and authentication methods. Where direct equivalents don't exist, the guide explains workarounds and alternative approaches—for example, handling Lambda authorizers in an Azure environment or replicating edge-optimized endpoints using multi-region deployments.

✅ Assessment and preparation

Before you touch any infrastructure, the guide walks you through a systematic assessment and preparation process. This includes evaluating your current deployment against Azure capabilities, identifying services to retain or replace, documenting API configurations, and establishing performance baselines. The guide emphasizes exporting OpenAPI specifications, capturing authentication flows, and understanding data flows—all critical inputs for migration planning.

✅ Migration and validation

We outline a phased migration approach that minimizes risk and downtime. Key phases include selecting an appropriate API Management service tier, planning network topology, configuring parallel environments, validating configurations, and executing DNS cutover. The guide also covers post-migration optimization and continuous improvement practices.

✅ Architecture-focused example

To provide context, the guide shows you a sample migration scenario: a healthcare organization with a multi-backend API system proxied through Amazon API Gateway. The original architecture includes Cognito authentication, WAF filtering, Lambda functions, EC2 instances, and an EKS cluster. The Azure equivalent architecture shows how to achieve comparable functionality using Microsoft Entra ID, Azure Application Gateway with WAF, Azure Functions, AKS, and private endpoints—all while maintaining network isolation and monitoring capabilities.

More resources

While this guide focuses on API Management, many organizations are migrating multiple workload types from AWS to Azure. The Azure Migration Hub provides comprehensive guidance for migrating various components, including compute, databases, storage, and applications.

Explore the full migration guide on Microsoft Learn and let us know how it helps you in your migration journey!

Best Practices for Migrating COTS Applications to Microsoft Azure

srhulsus — Wed, 26 Nov 2025 20:43:14 GMT

Understanding the Nature of COTS Migrations

Migrating Commercial Off-The-Shelf (COTS) applications to Microsoft Azure requires more care than a standard application migration. These workloads usually depend on strict vendor requirements, fixed upgrade cycles, licensing limitations, and specific operating systems or databases. Because of this, the first step in any COTS migration is a detailed discussion with the software vendor to confirm what Azure services, operating systems, and database platforms they officially support. Many vendors already provide Azure-ready architecture or publish marketplace templates that simplify deployment. Following vendor-supported patterns helps prevent support issues later and ensures the application remains fully certified in the cloud.

Microsoft’s general migration planning guidance is available in the Cloud Adoption Framework: https://learn.microsoft.com/azure/cloud-adoption-framework.

Determining the Level of Change Required

An important part of planning is understanding how much the application needs to change during the migration. Some COTS products can be deployed directly to Azure Virtual Machines without modification, while others benefit from a modernised database platform, such as Azure SQL Managed Instance, or a broader architecture update.

Microsoft explains the different migration approaches, such as rehosting, refactoring, and re-platforming, in its migration strategy guidance:
https://learn.microsoft.com/azure/cloud-adoption-framework/strategies/migrate .

Creating a Stable Azure Landing Zone

A reliable landing zone is essential before hosting any COTS workload. This includes identity integration with Microsoft Entra ID, a secure and segmented virtual network, governance rules, monitoring, and disaster-recovery readiness. A well-built landing zone provides a consistent and compliant foundation that does not need rework once the application goes live.

Microsoft’s recommended design principles for landing zones can be found here:
https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone.

Checking Infrastructure Requirements with the Vendor

COTS vendors typically define specific infrastructure rules, including CPU types, memory profiles, operating system versions, storage performance levels, and expected throughput. For applications that cannot be redesigned, Azure Virtual Machines or Azure VMware Solution are often the most suitable choices. Azure VMware Solution, in particular, is helpful for older or sensitive COTS systems because it preserves an environment similar to the existing on-premises setup.

Details about Azure VMware Solution are available at: https://learn.microsoft.com/azure/azure-vmware/introduction.

Reviewing Licensing and Cost Implications

Licensing for COTS applications can be complex, especially for products that calculate pricing based on physical cores, vCPUs, named users or concurrent users. Moving to Azure may change how these licenses apply, so it is important to verify this with the vendor and understand Microsoft’s guidance on licensing in the cloud.

The general licensing overview for Azure workloads is described at:
Core-Based Licensing Models Guidance.

Modernising Supporting Services Around the Application

Even if the COTS application itself cannot be changed, the surrounding ecosystem usually can. Azure provides several services that can modernise integration, automation and monitoring without altering the main application. For example, Azure API Management can help secure and standardise interfaces (https://learn.microsoft.com/azure/api-management), Logic Apps can automate backend workflows (https://learn.microsoft.com/azure/logic-apps), and Azure Monitor and Microsoft Sentinel can strengthen observability and security (Azure Monitor: https://learn.microsoft.com/azure/azure-monitor, Sentinel: https://learn.microsoft.com/azure/sentinel). These improvements help create a more efficient and reliable environment around the COTS workload.

Designing a Reliable High-Availability and DR Strategy

Both the software vendor and Microsoft should guide the high-availability and disaster-recovery design. Azure supports several resilience models, including Availability Zones, paired regions, disk replication and Azure Site Recovery. Choosing the correct approach depends on vendor support and the criticality of the application.

Azure’s disaster-recovery guidance is available here:
https://learn.microsoft.com/azure/site-recovery/site-recovery-overview.

Running a Pilot Before Full Migration

Before shifting the entire workload, running a pilot migration helps validate performance, integration behaviour, authentication flows and operational processes. A pilot makes it easier to identify gaps early and reduces the risk of problems during cutover. Azure Migrate provides tools to assess and validate workloads before moving them:
https://learn.microsoft.com/azure/migrate.

Aligning Operations After Migration

Once the application is running in Azure, day-to-day operations should be adjusted to match cloud practices. This includes defining monitoring thresholds, incident-response steps, backup routines and runbooks.

Microsoft’s Well-Architected Framework offers guidance for building stable, secure and efficient cloud operations: https://learn.microsoft.com/azure/well-architected.

Continuous Optimization After Stabilization

After the environment settles, organisations can gradually optimise performance, improve security, tune resources and reduce cost. Azure Advisor provides recommendations for cost savings, reliability and performance improvements based on real usage data.

More details can be found at: https://learn.microsoft.com/azure/advisor/advisor-overview.

Summary:

Migrating COTS applications to Azure is not a simple lift-and-shift task. It requires careful alignment with the vendor, proper landing zone preparation, validation of infrastructure requirements, modernisation of supporting services and strong operational processes. With the right planning and use of Microsoft’s guidance, organisations can reduce risks, improve reliability and build a long-term foundation for analytics, automation and future AI-driven capabilities.

Azure Copilot Migration Agent - Bringing Agentic Migration and Modernization to life

shashban — Wed, 19 Nov 2025 12:36:16 GMT

Enterprises today need more than speed they need confidence. Migration projects often stall because of complexity, fragmented tools, and unclear ROI. With Migration Agent in Azure Copilot, we’re changing that equation. This new capability brings AI-driven intelligence to every stage of migration and modernization, helping you move from discovery to execution in hours, not weeks. and completing the journey with confidence.

Migration is no longer just about moving workloads. It’s about unlocking innovation, reducing costs, and modernizing applications to stay competitive. Yet, many organizations struggle with lengthy assessments, manual landing zone setup, and database modernization challenges. Migration Agent addresses these pain points head-on, combining automation with actionable insights so you can accelerate outcomes without compromising governance or security.

Watch it in action

Rehost from VMWare to Azure with Migration Agent

Modernize applications with Migration Agent and GitHub Copilot

Migration Agent, now integrated into Azure Copilot, introduces three key capabilities designed to simplify and speed up your migration journey:

Discovery to ROI analysis in hours

Migration planning shouldn’t take weeks. With the Migration Agent, AI-powered discovery automatically maps your on-premises estate, infrastructure, databases, and applications without manual effort. Within a few hours, you get a tailored business case that includes migration costs, projected savings, and ROI, all calculated from your real usage. Right-sizing recommendations ensure Azure targets fit your performance and budget, while modernization guidance highlights where you can refactor or optimize for cloud-native benefits.

Landing Zone setup in hours

Setting up a secure, compliant Azure environment is now a matter of hours, not weeks or months. The agent automates landing zone creation, aligning with Microsoft’s Cloud Adoption Framework. Networking, identity, policies, and resource organization are configured for you, reducing manual steps and risk. Structured migration waves let you sequence workloads for predictable execution, with built-in progress tracking and rollback options. Every configuration is validated against best practices, so you can move forward with confidence.

Modernize OSS Databases and Linux seamlessly

Modern workloads demand modern support. Azure Migration Agent now covers the latest Linux distributions: RHEL 9.5, Rocky Linux 9.5, Ubuntu 24.04, Alma Linux 9.5 ensuring compatibility from day one. Integrated assessment and migration for PostgreSQL and MySQL databases means discovery, readiness checks, and modernization steps are consolidated into a single workflow. Actionable recommendations help you upgrade, consolidate, and tune databases, unlocking cloud-native features and cost efficiencies.

How it works

Migration Agent operates within Azure Copilot, your AI-powered assistant for cloud operations. It guides you through:

Discovery and assessment using AI models.
Business case generation with ROI insights tailored to your environment.
Landing zone deployment aligned with governance best practices.
Modernization workflows for databases and applications all in a single experience.

This integration means you’re not juggling multiple tools or scripts. Instead, you have one intelligent interface that learns from your environment and adapts recommendations to your goals.

Get Started Today

With Migration Agent in Azure Copilot, you can move faster, modernize smarter, and realize value sooner. Start today and transform migration from a challenge into a competitive advantage.

Learn more about Azure Migrate and for expert migration help, please try Azure Accelerate.

Migration Agent - Unlocking transformation

SShastri — Tue, 18 Nov 2025 15:45:00 GMT

IT Modernization is far more than adopting a new technology—it’s a transformative, ongoing journey that reshapes processes and culture. It has no finish line, and when embraced fully, it delivers lasting strategic advantage. Modernization unlocks agility, resilience and innovation to keep up with customer expectations and shifts in the competitive landscape. Cloud-native architectures are best positioned to support modernization while securely providing access to innovations such as AI. The new Migration Agent based on Azure Migrate is at the heart of this transformation, aligning IT capabilities with business priorities and unlocking new opportunities in Azure through a unified, agentic platform that guides you through the journey.

Clarity and confidence before you start:

Imagine beginning your cloud journey with complete certainty. The Migration Agent turns raw data into actionable, application-focused insights, giving you the power to plan with precision. Its agentless discovery and assessment tools provide deep insights into utilization while the new offline collector allows for a quick, frictionless inventory—ideal for restricted environments. The result? A clear, comprehensive map of your IT landscape without exposing sensitive networks, so you can move forward with confidence. Please see this demo video for more details.

With application awareness, you don’t just see a list of virtual machines (VM's), you see how your Java storefront, PostgreSQL database, and Linux services interconnect as living business systems. Every assessment includes a security vulnerability report, surfacing misconfigurations and outdated components, with clear, actionable fixes aligned to Microsoft Defender for Cloud (MDC). Here is ar brief demo to illustrate the depth of security insights and guidance on offer.

Evidence-backed 6R recommendations—Rehost, Refactor, Rearchitect, Rebuild, Replace, Retire—allow you to explore available options before deciding on the best path forward for each workload. Analysis time shrinks, internal debates disappear, and stakeholders get to see a decision maker ready business case with full risk visibility grounded in your data, before committing. Every dependency is mapped, every risk addressed, so you move forward with confidence and clarity.

Rapid execution and reliable outcomes:

Clarity is just the beginning. The real magic happens when you execute with precision and speed. The Migration Agent automates the creation of platform landing zones using agentic Infrastructure as Code (IaC)—so identity, networking, security, and governance based on best-practices are deployed consistently, every time. Whether you’re using Bicep or Terraform, IaC ensures your environments are validated and production ready.

Wave planning lets you migrate by application groups, not just VMs. It allows business and IT stakeholders to align their priorities with strategic goals. Early waves can target high-impact or low-risk workloads, delivering quick wins while later waves can address more complex or less critical systems. The Migration Agent keeps humans at the center during orchestration, seamlessly coordinating handoffs between personas across infrastructure, database, application, and security—while continuously tracking progress and readiness from initial assessment through final cutover. With these capabilities, you achieve speed with governance. Compliance is built-in, and every migration wave repeats the last successful pattern. Manual errors and slow deployments disappear—IaC codifies best practices for scale and auditability. Complex migrations become orchestrated, confident moves, with every stakeholder on the same page.

Modernize continuously without limits:

In many cases, migration is the runway for modernization. Migration Agent integrates with GitHub Copilot, enabling developers to plan upgrades conversationally, generate code, and automate routine tasks for .NET, Java and cloud-native workloads. Integration with CAST Highlight provides deep analytics, helping teams target the right refactors and reduce risk. This is where developer velocity meets business agility. GitHub Copilot and CAST integration compress upgrade timelines and accelerate the journey to cloud-native. Modernization becomes a continuous, developer-centered flow, not a one-time event. You unlock innovation and agility, turning cloud transformation into a strategic advantage for your business.

Azure is more than a destination—it’s your launchpad for transformation. With the Migration Agent powered by Azure Migrate, you’re not just moving to the cloud—you’re accelerating toward a smarter, faster, and more secure future.

Learn more

Start with a free Azure account if you are new. Learn more about the workload agnostic method of Azure Migrate and for expert migration help, please try Azure Accelerate. You can also contact your preferred partner or Microsoft field for next steps. Get started in Azure today!

Assess Security risks with Insights in Azure Migrate

Nikita_Bajaj — Wed, 01 Apr 2026 05:05:22 GMT

Why Security matters in Migration

Migrating to the cloud is not only about speed and cost efficiency, it's also about building a secure foundation on Azure. As organizations move workloads to Azure, security often slips down the priority list, overshadowed by migration tasks and timelines. But here’s the truth: addressing security risks early in your migration strategy not only prevents costly surprises but also strengthens compliance, reduces risk exposure, and instills confidence across your business. A proactive approach ensures your cloud journey is smooth, secure, and future-ready.

That’s why we introduced Insights (preview) in Azure Migrate, to help you identify security risks before they become roadblocks during the migration journey.

What are Insights?

Security Insights in Azure Migrate provides an integrated dashboard that surfaces potential risks in your on-premises environment during migration planning. Here are the key capabilities:

Identify Windows and Linux servers with end of support operating system and software, pending updates and plan upgrade.
Review and plan upgrade of databases running on end of support database platform and web apps with end of support runtime.
Detect vulnerabilities in discovered databases, web apps, software and take action to remediate risks.
Identify unprotected servers without security or patch management software.
Explore multiple security tools in the datacenter and plan to consolidate with Microsoft Defender for Cloud and Azure Update Manager.

How are Insights derived

Azure Migrate identifies potential security risks in your datacenter using software inventory data collected through the Azure Migrate appliance discovery process. When you run a discovery of your on-premises environment, you usually provide guest credentials for your Windows and Linux servers. This allows the tool to collect information about installed software, operating system configuration, and pending updates. Azure Migrate processes this data to generate key security insights without needing additional credentials or permissions.

Azure Migrate does not install additional agents or runs a deep scan of your environment. Security insights are limited to software and operating system data discovered through the Azure Migrate appliance quick discovery. It analyzes the collected software inventory data and cross-references it with publicly available vulnerability and support lifecycle databases to highlight security risks in your datacenter.

Security risks are derived through a series of following analyses:

End-of-support software: Azure Migrate checks the versions of discovered OS, database platform, web app runtime and software against the publicly available endoflife.date repository. If an OS, database platform or web app runtime is found to be end of support, it is flagged as a security risk. Identifying unsupported resources early helps you plan upgrade or mitigations as part of your cloud migration.
Vulnerabilities: Azure Migrate identifies installed software and operating system (OS) for each server. It maps the discovered software, OS, database platform and web app runtime with publicly available National Vulnerability Database (NVD), managed by NIST to identify vulnerabilities. Each vulnerability is categorized by risk level (Critical, High, Medium, Low) based on the CVSS score provided by NVD. You can take appropriate action to remediate risks for a secure migration.
Pending updates for servers: Azure Migrate identifies machines that are not fully patched or updated based on Windows Update metadata for Windows servers and Linux package manager metadata for Linux servers. It also retrieves the classification of these updates (Critical, Security, Other updates) and shows them for further consideration.
Missing security and patch management software: Azure Migrate classifies software by processing its name and publisher into predefined categories and sub-categories. It identifies unprotected servers that lack Security & Compliance software identified through software inventory. For example, if the software inventory indicates a server without software in categories such as, antivirus, threat detection, SIEM, IAM, or patch management, Azure Migrate flags the server as a potential security risk. By identifying fragmentation in Security software, you can plan consolidation with Azure security services.

Note: Security insights in Azure Migrate help guide and highlight potential security risks in the datacenter. They are not meant to be compared with specialized security tools. We recommend adopting Azure services such as, Microsoft Defender for Cloud and Azure Update Manager for comprehensive protection of your hybrid environment.

Let's get started

Use appliance-based discovery in Azure Migrate to review Insights. Ensure guest discovery features are enabled on the appliance(s). It might take up to 24 hours after discovery to generate Insights. Go to the Azure Migrate portal and create a new project or select an existing project. Visit Explore inventory > Insights (preview) to get a summary of the security risks across Servers and Software. Visit Manage > Reports (preview) to download an exec-ready PowerPoint file for Security insights. Explore the documentation and demo video for detailed guidance and start assessing and mitigating security risks during migration planning.

Accelerate Cloud Migration with Wave Planning in Azure Migrate

ShubhamJain92 — Tue, 11 Nov 2025 16:46:02 GMT

Introduction

Migrating to the cloud is more than a technical upgrade - it's a strategic leap toward agility, scalability, and innovation. Yet, for many organizations, the journey can feel overwhelming, with complex dependencies and business risks threatening to slow progress.

Today, we’re excited to announce the public preview of wave planning in Azure Migrate - a new capability designed to make large-scale migrations more manageable and predictable. With wave planning, you can now organize your migration journey into logical, iterative waves, enabling your teams to plan, execute, and track progress with greater speed, confidence, and control.

Key Benefits:

Accelerate migrations: Quickly identify and prioritize “quick win” workloads and applications by surfacing relevant information from discovery and assessments.
Reduced risks: Group systems that work together using application grouping, dependency analysis and tags allowing safer iterative planning.
Increased predictability: Visualize migration progress and timelines centrally, enabling continuous feedback and proactive adjustments.
Application-centric migrations and modernization: Plan, execute, and track every step at the application level for greater control and business alignment.

Wave Planning in Azure Migrate

Concepts and Stages

Planning Stage

During the planning stage, you can organize their applications and workloads into waves and determine the order in which these groups will be migrated. By doing so, you can establish a comprehensive plan that outlines the specific steps, timelines, and resources required for each wave, ensuring a structured and efficient approach to migration and modernization.

Key aspects of the wave planning in this stage includes:

Group and sequence applications and workloads using tags, dependency analysis, and workload data.
Set Azure targets and migration tools based on Azure Migrate assessment recommendations.
Outline planning steps, timelines, and create a wave plan for application migration and modernization.

Execution Stage

Using wave planning you can perform the migration and modernization activities of the application withing the wave, as per the plan and track the progress as workloads are moved, tested, and migrated / modernized in Azure.

Key aspects of wave planning at this stage includes:

Centrally track migration and modernization activities for all applications and workloads within the wave. You can start migrating servers and databases using Server migration and Azure database Migration Service using in-product integrations.
Integrated end-to-end workflows to facilitate server migrations from on-premises environments and various public clouds to Azure Virtual Machines.
Monitor and visualize wave timelines in relation to planned migration and modernization dates and implement corrective actions as required based on status updates.

In a nutshell, wave planning transforms migration from a one-time event into a continuous journey of improvement. By iterating, learning, and adapting, organizations build institutional knowledge, reduce risk, and unlock the full benefits of cloud adoption.

Getting Started

Ready to accelerate your migration? Get start today:

Learn more about using Azure Migrate – Wave planning.

Explore wave planning guidance through the Cloud Adoption Framework.

Learn more about Azure Migrate.

Checkout application-centric migration in Azure Migrate.