Discover your existing workload inventory

This section applies to organizations with existing IT workloads outside Azure (on-premises or other clouds) that need migration to Azure. A comprehensive workload inventory is the foundation of a solid cloud adoption plan for such organizations. You can’t make decisions about how or whether to migrate a system if you don’t know it exists or understand its characteristics. Your cloud adoption plan must include steps to discover all workloads, gather key data about each, and prioritize them for migration.

Discover workload inventory

A complete inventory of your technical assets forms the foundation of your cloud adoption plan. Your inventory identifies all systems, applications, and infrastructure components across your environment. You need this inventory to decide which cloud migration strategy is the best fit.

1. Define each workload and its boundaries. A workload is a collection of IT components, such as servers, virtual machines (VMs), cloud services, applications, code, data, or appliances, that support one or more business processes. You need to define each workload to understand its business value and technical footprint. This clarity helps prioritize migration and modernization efforts. Use network traffic monitoring and dependency mapping tools to identify workload boundaries and visualize relationships between components.

2. Use automated discovery tools. Azure Migrate provides free discovery capabilities for on-premises and cloud environments. This tool automatically identifies servers, applications, and their interdependencies. You must use automated discovery to accelerate inventory creation and reduce manual errors. If Azure Migrate doesn't fully support your environment, use tools like Dr Migrate or CloudPilot that extend Azure Migrate capabilities.

3. Include all components across all environments. Your inventory must capture infrastructure and application components across all platforms. You need to include servers, VMs, applications, databases, communication patterns, integrations, identities, and cloud services from Azure, AWS, Google Cloud, and other providers. This comprehensive view ensures that no critical asset is overlooked during planning or migration.

4. Use manual discovery when automation isn't possible. Some environments restrict automated discovery tools due to security policies or technical limitations. Use the Azure Migrate import template to manually document assets in restricted environments. Manual documentation ensures you capture assets that automated tools can't access.

Prioritize workloads by business value and feasibility

A long inventory list can be overwhelming. The plan should include a method to prioritize which workloads to tackle first in the cloud adoption effort. Not all workloads are equally important or equally suitable for immediate migration, so use a prioritization framework.

1. Use business criticality. Rank workloads by how critical they're to business operations, revenue, or customer experience. Often, a few workloads are mission-critical (if they go down, major business losses) while others are less critical. High business value systems might be high priority to ensure they benefit from cloud scalability or resilience, or sometimes lower priority if risk of migrating them is too high.

2. Estimate cloud readiness. Make quick, high-level estimates of how ready each workload is for cloud migration, based on what you already know. A detailed technical assessment comes later, but for now, consider factors like technical complexity, legacy components, and known risks. Some workloads might be easy wins, while others might require significant rework. You might prioritize simpler workloads to build momentum, or choose a moderately complex but high-value system to maximize early success.

3. Note dependencies. At this stage, assess dependencies at a high level using existing knowledge. A full dependency mapping is done later, but for now, identify workloads that are tightly coupled with others. Systems with many connections might need to be migrated together to avoid disruptions. In some cases, a lower-priority workload might need to move earlier because a higher-priority system depends on it. Use this insight to group related workloads into logical migration waves.

4. Consider strategic alignment. If certain workloads are key to strategic initiatives, you might prioritize them to move sooner. On the other hand, workloads slated to be retired or replaced soon should be deprioritized for migration.

5. Create a prioritized backlog. This backlog can be a list or table with categories like "Wave 1: Workloads A, B, C. Wave 2: Workloads D, E." Ensure you validate this order with stakeholders. Business and IT owners should review and agree that the sequence makes sense. You want to get their buy-in and avoid pushback later. For example, if you schedule a department’s critical app last without their input, they might object. Adjust the plan based on feedback to balance technical logic with business needs.

Gather business details per workload

For each workload identified, the plan should capture key business context and requirements. This information guides migration strategy (next section) and ensures decisions align with business needs. Important details to document

1. Owners and stakeholders: Document "owns" the workload from a business perspective (VP of Sales for a CRM) and from an IT perspective (application owner, infrastructure owner). List all stakeholders who must be involved in planning its move.

2. Business function and criticality: Document what the workload does, and how important it is. Record a short description of its purpose and classify its criticality level (high/medium/low). Criticality often ties to how much downtime can be tolerated.

3. Data sensitivity and compliance: Note the classification of data the system handles (public, internal, confidential, highly confidential). Document compliance requirements (PCI, HIPAA, GDPR) that apply to this workload. For instance, if data residency is required in a certain region, that influences the cloud architecture for it.

4. Operational constraints: Document specific maintenance windows, blackout periods (high-traffic periods), and uptime requirements. Document any such constraints because they affect migration scheduling and target architecture (high-availability needs).

5. Projected timeline or deadlines: If there’s a desired timeline for migrating this workload, note that as well. For example, maybe you have contract renewals or data center lease ending. These factors feed into the overall roadmap scheduling.

For an example, see Migration adoption plan.

Azure discovery and assessment tools and resources

Next steps