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

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:

1. 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.
2. 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:

1. 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.
2. Migrate (IaaS) – Lift-and-shift to Azure VMs, or to Azure VMware Solution for VMware estates.

The report generates a PowerPoint deck that covers:

1. Workload and application summary across your estate
2. Security insights and vulnerability posture
3. Total cost of ownership and return on investment
4. Readiness and target recommendations per workload
5. Estimated Azure costs by migration strategy
6. 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:

1. Set up Collector - Download and configure the Azure Migrate Collector on a Windows Server in your datacenter
2. Choose your discovery method - Compare Collector, appliance, and import-based approaches for your scenario
3. Tag your workloads - Follow tagging best practices for accurate recommendations
4. Organize applications - Define and manage applications from your discovered inventory
5. Generate your report - Build an Azure Migrate report and export to PowerPoint
6. 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.