Published on · Updated on
Rebuilt the guide around the difference between organizational and application readiness, current AWS discovery services, evidence limits, the 7 Rs, migration cost assumptions, and dependency-aware wave planning.
Application portfolio analysis helps answer three migration questions: what is in scope, what should happen to each workload, and what should move together. It combines business context with technical evidence from inventory, usage, dependencies, and application owners. It is an iterative planning activity, not a one-time scan or an automatic verdict that an application is ready for AWS.
Portfolio analysis is one part of migration readiness. The AWS Migration Readiness Assessment (MRA) looks at the organization through the six AWS Cloud Adoption Framework perspectives: business, people, governance, platform, security, and operations. Portfolio assessment asks workload-level questions. A migration can need both: a useful workload plan and the organizational capabilities to carry it out.
A portfolio view supports prioritization; it does not replace a detailed application assessment, target design, security review, or cutover plan. AWS describes portfolio assessment as a continuous process that grows from initial discovery to higher-fidelity planning over time in its application portfolio assessment guide.
“Readiness” can refer to different things. Keeping these questions separate prevents a server inventory or a broad organizational review from being mistaken for proof that an individual application can move safely.
Use the portfolio view to decide which workloads deserve a detailed assessment first. Revisit both workload and organizational readiness as new risks, dependencies, or resource constraints emerge.
Give every application a stable identifier and accountable business and technical owners. Capture its purpose, users, environment, lifecycle, criticality, release calendar, and known constraints. Link applications to the servers, databases, storage, networks, third-party services, and teams that support them.
Useful sources include a configuration management database (CMDB), asset and monitoring exports, network records, architecture diagrams, contracts and license records, support histories, and interviews with application owners. Record where each fact came from, when it was checked, and whether it is measured, documented, or an estimate. If sources disagree, keep the disagreement visible until an owner resolves it.
For each application, gather the information needed to choose and plan a strategy. A concise first pass should cover:
These fields are a starting set, not a universal checklist. Scale the depth to the decision: an early directional business case can use estimates with stated assumptions, while a committed migration wave needs higher-confidence data and workload-specific validation. AWS provides broader portfolio data requirements for teams building a detailed inventory and business case.
Discovery tools can reduce manual inventory work and reveal observed server relationships. Their results still depend on which environments were included, what permissions and collectors were configured, and when measurements were taken. They do not automatically identify every application, owner, business dependency, contract, or readiness risk.
For example, AWS Transform's network collection can help map observed server-to-server connections. Its documentation says the default collection includes TCP IPv4 connections between servers in the discovered or imported inventory; connections to outside or undiscovered endpoints are omitted by default. Configure coverage deliberately, then compare tool results with application-owner knowledge, architecture records, and other available network evidence. A missing connection in a map does not prove that two systems are independent. See AWS's description of AWS Transform data collection.
Separate measured facts from assumptions and record gaps that could change the strategy or wave. This makes the next investigation useful: collect more data where uncertainty could affect cost, compatibility, security, downtime, or workload grouping.
Manual discovery is useful when the source estate is small, automated access is restricted, or business context is not present in technical tools. Reuse existing records first, then ask owners targeted questions to confirm purpose, usage patterns, interfaces, known failure modes, business dates, and who can approve a migration or retirement.
Compare owner interviews and diagrams with observed traffic, logs, configuration, and deployment records. Ask about low-frequency activity such as month-end processing, annual reporting, disaster recovery tests, vendor support, and manual handoffs. Mark a relationship as confirmed, observed, inferred, or unresolved. This is more useful than presenting every connection as equally certain.
A hybrid approach usually makes the best use of available evidence: import or collect infrastructure and utilization data programmatically, then ask owners and engineers to explain business meaning and verify missing or surprising details. Reconcile identifiers between tools so that a server, database, and business application can be followed through the same inventory.
Keep a record of data coverage, collection dates, assumptions, and open questions. Refresh the evidence when infrastructure changes or when a migration wave approaches. The portfolio should become more precise as decisions become more specific.
AWS Migration Evaluator helps build a business case for running on-premises workloads on AWS. It can use inventory and utilization collected by its agentless collector or imported from other tools, then model projected costs and scenarios. Its output is only as useful as the scope, measurement period, licensing, and assumptions behind it. Treat a projection as an estimate to review, not as a guaranteed saving or a complete application readiness assessment. AWS describes Migration Evaluator's scope and inputs in its feature guide.
AWS Application Discovery Service and AWS Migration Hub stopped accepting new customers on November 7, 2025; existing customers can continue using the services for current projects. AWS recommends AWS Transform for new discovery and migration-planning projects. Check the current AWS service guidance for eligibility and supported workloads before selecting a tool. See the Application Discovery Service availability notice and the Migration Hub availability notice.
AWS Transform's discovery tool supports server inventory from sources including VMware, Hyper-V, and imported server data. Its migration planning can group servers into applications and waves, but the result still needs review against your business rules, technical evidence, and migration capacity. In particular, confirm that discovery includes the platforms and endpoints that matter to your application.
There is no general accuracy or effort ranking that applies to every estate. Compare a tool against the question you need to answer: which platforms it can discover, which measurements it collects, the permissions and setup it needs, its data window, and the output format available for analysis. Manual work can supply context the tooling cannot see; tools can expose inconsistencies that interviews or static records miss.
The 7 Rs describe migration strategies, not an automatic score of readiness. Choose based on business outcomes, technical constraints, cost, risk, time, and available skills. A single application may need different treatment for its application code, database, and data.
| Strategy | What it means | Typical consideration |
|---|---|---|
| Retire | Decommission or archive the application. | Verify ownership, users, integrations, retention requirements, and shutdown consequences before removing it. |
| Retain | Keep the application in its current environment for now. | Use when a dependency, business constraint, or unresolved risk makes a move unsuitable at this time. |
| Rehost | Move the application to AWS with no application changes: lift and shift. | Can defer redesign, but does not itself deliver cloud optimization. |
| Relocate | Move infrastructure to a cloud version of its current platform, or move supported resources between AWS environments, without redesigning the application. | Confirm that the source and target platform support the chosen relocation pattern. |
| Repurchase | Replace the application with a different product or version, often moving from a traditional license to SaaS: drop and shop. | Assess data migration, integrations, security, licensing, user change, and contract terms. |
| Replatform | Move the application with targeted changes or optimizations, such as moving to a managed database. | Validate compatibility and the operational changes the new platform introduces. |
| Refactor or re-architect | Change the application architecture to use cloud capabilities or meet business needs. | Requires a larger design, testing, and delivery effort than a like-for-like move. |
For AWS's fuller definitions and examples, see its guide to the 7 Rs. Record the reason, assumptions, owner, confidence, and conditions for revisiting each decision.
Compare like with like over the same time period. The current-state baseline may include hardware and facilities, software and support licenses, staffing, network and recovery capacity, and the cost to operate current systems. The AWS scenarios may include compute, storage, databases, networking and data transfer, monitoring, security, support, licensing, and the labor to migrate and operate the target.
Include one-time migration work, training, landing-zone and tooling costs, parallel operation during transition, decommissioning, and risks that have a credible cost impact. State the Region, utilization period, purchase options, right-sizing assumptions, and what is excluded. Model more than one plausible scenario when pricing, demand, schedule, or refactoring effort is uncertain. Separate financial savings from benefits such as resilience, delivery speed, or reduced data-center exposure, and show the evidence behind each.
Replace early benchmarks with measured inventory and validated assumptions as the plan matures. Migration Evaluator can inform a directional server-cost comparison; it does not include every application, migration, organizational, or operational cost without the relevant data and analysis.
A wave groups applications and infrastructure that must move together or can be tested and operated together. Use dependencies, business criticality, technical complexity, data volume, release calendars, cutover and rollback constraints, team capacity, and platform, security, and operations readiness to form groups and set order. Keep a clear owner for every application and wave.
Prioritization is portfolio-specific. A low-criticality workload might be a useful early pilot, but only if its dependencies and operational needs are understood. Avoid assuming that low traffic or simple infrastructure automatically means low business risk. AWS's wave-planning guidance likewise combines dependency data, business drivers, cost and risk, skills, and platform readiness rather than applying a universal size or schedule.
When a wave is approved, plan data movement and cutover as separate work. The AWS content migration best practices guide covers transfer choices, destination verification, and rollback considerations for files, objects, and databases.
It produces a maintained view of applications and supporting infrastructure, key ownership and business attributes, known dependencies and data gaps, migration strategy decisions, a costed business case, and a migration wave plan. The required detail grows as workloads move closer to migration.
No. A tool can provide valuable inventory, utilization, and observed connection data, but it may not cover every system, business dependency, operating condition, or compliance requirement. Confirm coverage and validate important findings with owners and workload-specific assessment.
Retire, retain, rehost, relocate, repurchase, replatform, and refactor or re-architect. Relocate generally moves infrastructure or supported resources without redesigning the application. Repurchase replaces the application with another product or version, often SaaS.
Migration Evaluator supports a directional business case by analyzing current workload information and projected AWS costs. Organizational readiness is addressed through an MRA aligned to AWS CAF; application readiness needs a workload-specific technical and business assessment.