Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsAssess an application portfolio in stages: establish business goals and ownership, build a reliable inventory, measure workloads and dependencies, validate the findings with application teams, then prioritize and assign provisional next steps. The result should be a defensible sequence of decisions—not an assumption that every application belongs in the cloud or needs to be rebuilt.
1. Set the assessment’s goals, boundaries, and owners
Begin by agreeing what the modernization program is meant to achieve. Goals might include improving resilience, reducing operating costs, increasing delivery agility, meeting compliance requirements, or enabling business transformation. Different goals can lead to different priorities, so record them before comparing applications.
As an Amazon Associate I earn from qualifying purchases.
Define which business units, applications, environments, and supporting infrastructure are in scope. Name the people who can make portfolio decisions and the owners who can validate individual workloads. Identify the records and systems that will supply data, and note where that data is incomplete or unreliable. AWS frames portfolio assessment as an input to business cases and migration plans, while also treating it as an ongoing activity: AWS Prescriptive Guidance on portfolio assessment.
Recommended Free Tools
2. Build an inventory that connects applications to the business
A list of application names is not enough to make sound decisions. Capture business purpose and ownership alongside technical details, so teams can see what a workload supports and who can explain its requirements. AWS recommends mapping applications to business capabilities and enriching metadata in collaboration with application owners: AWS guidance on portfolio discovery.
#1 Best Overall
For each application, record the information needed to assess value, feasibility, risk, and sequencing:
- Business context: purpose, supported business capability, business owner, technology owner, criticality, and lifecycle status.
- Data and obligations: data sensitivity, compliance context, security requirements, and recovery objectives.
- Technical footprint: architecture, infrastructure, operating-system and database versions, configuration, scaling approach, and licensing.
- Operating context: dependencies, service expectations, estimated costs, and any known support or maintenance constraints.
Keep the inventory in a shared, maintained location rather than scattering assessment facts across individual spreadsheets and team documents. Record when information was last checked and who confirmed it; this makes uncertainty visible instead of disguising it as a complete baseline.
3. Measure how workloads actually run
Configuration records tell you what is installed; operating data helps show what the workload needs. Where available, collect representative measurements for CPU, memory, storage, network use, concurrency, response time, throughput, and service levels. Note the measurement period and operating conditions so an unusual peak or quiet period is not mistaken for normal demand.
Rank #2
Use this baseline to inform capacity estimates, compatibility checks, target architecture, and cost analysis. Also record scaling behavior, software versions, licensing requirements, and security constraints. Microsoft’s workload-assessment guidance describes assessing servers, databases, and applications and validating automated findings with subject-matter experts: Microsoft Learn: assess workloads for Azure. Azure Migrate is one Azure-specific discovery and assessment option listed there; its suitability depends on the environment and workload coverage required.
4. Map dependencies, then validate the map with owners
Automated discovery can reveal infrastructure components and runtime connections, but treat the output as a draft to confirm—not a complete account of how the business operates. Ask workload owners and operators to check the map and identify undocumented or informal links.
Look beyond direct application-to-server connections. Include external services and APIs, shared databases, identity systems, messaging, scheduled batch jobs, data pipelines, and operational dependencies. A central dependency map helps distinguish workloads that can move independently from those that need to be coordinated. Microsoft likewise emphasizes visibility into components, dependencies, and requirements before moving workloads to Azure in its modernization preparation guidance.
5. Record constraints and risks with owners and mitigations
For each workload, identify issues that could block or complicate a move, a platform change, or continued operation. Assess technical compatibility and end-of-support exposure alongside security, compliance, operational readiness, recovery objectives, performance needs, vendor integrations, database relationships, and available organizational skills.
Maintain a risk register that states the issue, its impact, the mitigation, the person responsible, and when it needs resolution. Microsoft’s preparation guidance recommends tracking risks with mitigations, owners, and resolution timing. A named owner and due point make a risk actionable; a bare label such as “legacy technology” does not.
6. Prioritize by business value, technical risk, and urgency
Do not rank applications on technical health alone. Compare business value with technical risk, then account for urgency and practical dependencies. Microsoft describes value signals such as revenue impact, mission criticality, customer experience, compliance, and broad internal dependency. Risk signals include technical debt, outdated technology, high maintenance, poor reliability, and limited scalability. Its prioritization matrix is an illustrative decision aid, not a universal scoring formula: Microsoft Learn: assess applications for modernization.
| Portfolio signal | Questions to ask |
|---|---|
| Business value | Does the application support revenue, a mission-critical process, customer experience, compliance, or many internal teams? |
| Technical risk or need | Is it difficult to maintain, unreliable, outdated, hard to scale, or burdened by technical debt? |
| Urgency | Is there a support deadline, compliance requirement, resilience concern, or other time-sensitive trigger? |
| Dependencies and readiness | Can it move independently, and are its owners, data, and prerequisites ready? |
As a broad decision pattern, high-value and high-risk workloads merit early attention. High-value, lower-risk workloads may need monitoring rather than immediate intervention; lower-value cases may be handled individually or deferred. The matrix should guide discussion, not replace context about business timing, dependency groups, or the program’s agreed goals.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.7. Assign a provisional strategy—not a permanent verdict
Once the evidence is sufficient for an initial decision, assign a strategy at the application level and, where useful, to separate components. AWS uses seven labels to describe migration options:
- Retain: keep the workload where it is for now.
- Retire: decommission an application that is no longer needed.
- Rehost: move it with limited changes.
- Re-platform: move it while making selected platform changes.
- Repurchase: replace it with a different product, often a software service.
- Refactor: change the application more substantially to meet new requirements or take advantage of a different architecture.
- Relocate: move it to another environment with minimal application changes, such as moving a virtualized workload to a compatible cloud environment.
These labels are options, not quality rankings. Choose an initial path based on business outcomes, dependencies, compatibility, costs and licensing, and the intended target architecture. AWS’s portfolio-analysis guidance describes these strategy categories. Revisit an assignment when inventory completeness or assessment confidence improves; an early label is a planning hypothesis, not a promise to migrate or rebuild.
8. Sequence work in waves and keep reassessing
Build a directional business case and use the strategy assignments, dependency groups, migration complexity, criticality, and readiness to propose a sequence. Group workloads that share runtime or operational dependencies when moving them separately would create avoidable risk. Account for business cycles and required platform or security prerequisites.
Use progressively deeper analysis rather than waiting for a perfect inventory before planning anything. A portfolio-level view can support initial prioritization; near-term candidates need more detailed application-level design. AWS describes assessment as four continuing stages: discovery and initial planning, prioritized application assessment, portfolio analysis and migration planning, and continuous assessment and improvement. Its example week ranges are indicative and vary by program, so they should not be treated as a universal schedule: AWS Prescriptive Guidance on portfolio assessment.
Keep the inventory, dependency map, risks, and strategy assignments current during migration and after workloads move. Post-move assessment can identify optimization or further modernization opportunities; it is not merely an upfront gate.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →What a defensible assessment should let you decide
By the end of an initial assessment, decision-makers should be able to explain which applications matter most, why they matter, what is known and uncertain about their technical condition, which dependencies shape the work, and what evidence supports each provisional next step. They should also be able to distinguish an application that is ready to move from one that needs more discovery, risk reduction, or a business decision first.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
