Adding network intelligence into a network-ready Azure migration plan

Sudha Mahajan, Partner PM Azure Networking, Vijay Mamtani, CVP Azure Networking | September 2026

Lift-and-shift succeeds when the network moves with the application 

For many VMware customers, the immediate migration goal is practical: move workloads to Azure quickly, preserve application behavior and connectivity, reduce execution risk, keep it secure, and build a costed plan that leaders can approve. Compute and storage sizing are necessary, but it is not the whole migration plan. Applications depend on IP prefixes, network paths, security policies, load-balancing behavior, shared services, and connections to systems that may move at different times. 

Azure Migrate is critical to making this work manageable. It provides the foundation for discovering the estate, assessing migration readiness, developing the business case, and translating collected evidence into a plan. With Network Planning, that foundation becomes network-aware, combining server inventory with insights into how application connectivity can be represented in Azure.

Networking is the hidden critical path 

Network planning often begins late. A team may group and size virtual machines, then assume the target network can be designed near cutover. That approach overlooks the dependencies that determine whether an application will function after migration. 

The required information for networking is fragmented. Workload inventory may sit in vCenter; network constructs and flows may be reflected in NSX; policy intent may be distributed across firewalls; application delivery may depend on load balancers; address constraints may live in spreadsheets; and operational knowledge may be divided among application, infrastructure, security, and network teams. Each system provides part of the answer, but no single view naturally explains what an application needs in Azure. 

Common mistakes follow - planning by individual servers rather than application, missing dependencies, carrying forward rules without understanding their intent, overlooking shared services, estimating compute while omitting network costs, or designing target topology before the source environment is fully understood. These gaps create additional analysis, redesign, stakeholder review iterations, and cutover uncertainty. Networking becomes the hidden critical path - not because teams lack expertise, but because the evidence needed for decisions is incomplete and disconnected. 

Network planning bridges discovery and decisions 

Network planning is designed to close that gap within the Azure Migrate. Its purpose is to turn discovered network evidence and customer migration intent into an actionable, Azure-oriented planning view. 

Beginning September, Azure migrate enters public preview with network-aware assessment and networking incorporated into business-case and assessment functionality. 

Visualize and validate source network resources: Discovered VMware network information provides context for workload placement, connectivity, dependencies, and applicable destination constructs. 

Azure-native recommendations: Network Planning translates source findings into recommended Azure networking building blocks and guidance, including topology considerations (hub-and-spoke), security intent considerations (mapping on-prem firewall rules to NSG and Azure FW) and application delivery considerations (Application load balancing and WAF rules), instead of requiring customers to manually map every source construct. 

Readiness and issue visibility: Assessments surface network-related readiness considerations and planning issues that require attention before migration, allowing teams to separate straightforward moves from items needing design decisions or remediation. 

Networking in the business case: Network-cost estimates are included alongside the broader migration analysis, helping decision-makers evaluate a more complete cost picture. 

Security-rule planning context: Where source data supports it, translated security-rule information can help teams reason about security requirements and prepare for target policy design and validation. 

FROM DISCOVERY TO A NETWORK-READY MIGRATION PLAN 

What changes for customers and partners 

Network planning does not eliminate the need for engineering judgment or automate network design. Its value is a more structured starting point, grounded in discovered data and presented in the same Azure Migrate workflow used for assessment and business-case development. 

Customers can bring application, network, security, and migration stakeholders to a shared planning view. They can identify missing information sooner, connect network requirements to migration groups, review readiness before cutover planning, and include network considerations in financial discussions. Partners can use the same evidence to guide workshops, validate assumptions, focus design effort on exceptions, and produce a plan that is easier for customer teams to review. 

The result is a more practical migration conversation: not simply "Which virtual machines can move?" but "What does this application require, what must be addressed, what Azure is the recommended network approach , and what should be included in the costed plan?" 

Launch scope first, roadmap second 

The August preview of network planning in Azure Migrate is intentionally focused on the lift-and-shift planning path. Items such as application modernization, third-party virtual appliances, advanced topologies, infrastructure-as-code generation, and IP-retention scenarios remain future roadmap areas. Keeping that boundary clear allows customers to evaluate the preview for what it delivers now while Microsoft continues to shape later capabilities from feedback. 

Key takeaway 

For customers preparing VMware lift-and-shift migrations, begin by enabling and validating discovery in Azure Migrate, then choose a representative application or migration group. Review its workloads, dependencies, source network context, readiness findings, Azure recommendations, and estimated network costs with the teams responsible for application ownership, networking, security, and migration execution. 

For partners, use Network planning to anchor planning conversations in evidence rather than assumptions and to connect technical findings directly to the business case.  

A successful migration plan should describe more than where servers will run. It should explain how applications will remain connected, what issues must be resolved, what the target approach will require, and what it is expected to cost. Network planning brings those networks decisions into Azure Migrate - where lift-and-shift planning already begins. 

For further reference- you can refer to our website.