The cost of skipping this homework is measurable. A global survey of nearly 450 CIOs and IT leaders found that coordination gaps push migration spending 14% above plan each year, and 38% of companies saw migrations delayed by more than a full quarter, according to McKinsey's research on cloud migration missteps.
An application migration portfolio assessment replaces guesswork with evidence. It tells you what you actually have, what it's worth, what depends on it, and how it should move, before you commit a budget or a migration date. This guide walks through what the assessment covers, why it matters, and how to run one.
Key Takeaways
- Score each application on business value, technical health, risk, dependencies, cost, and cloud readiness
- Use those scores to choose rehost, replatform, refactor, repurchase, relocate, retain, or retire for each workload
- Incomplete inventories and hidden dependencies are the leading cause of unreliable migration plans
- Ship a prioritized roadmap with waves, owners, dependencies, and success criteria instead of a static report
What Is an Application Migration Portfolio Assessment?
An application migration portfolio assessment is a structured evaluation of your entire application estate. It determines which workloads should move to the cloud, how they should move, when, and whether some should be replaced or retired instead.
This is different from an application inventory. An inventory simply records what exists: names, owners, servers, versions. An assessment goes further. It interprets that data against business value, technical condition, risk, and cost to produce a migration decision for each application.
Where It Fits in the Migration Lifecycle
The assessment sits after discovery and before migration execution:
- Discovery – gathering raw data on applications and infrastructure
- Portfolio assessment – evaluating each workload and choosing its migration path
- Business-case validation – confirming the financial and strategic rationale
- Mobilization – assembling teams, tools, and environments
- Migration planning – sequencing applications into waves
- Modernization and governance – ongoing portfolio management after go-live
Common Assessment Approaches
Organizations typically combine several methods rather than relying on one:
- Manual stakeholder questionnaires and interviews
- CMDB and existing discovery tool data
- Application performance and usage telemetry
- Dependency mapping tools
- Architecture reviews
- Automated analysis platforms such as AWS Migration Evaluator for on-premises TCO reporting
Why Application Migration Portfolio Assessment Is Critical
A thorough assessment directly shapes business outcomes: controlled spending, reduced disruption, sharper prioritization, and better security decisions. These five areas show where the impact shows up first.
Finding Applications You Don't Need Anymore
Most IT portfolios carry more dead weight than leadership realizes. AWS notes it's "not unusual" to find more than 10% of workloads in an enterprise portfolio that are no longer useful and could simply be turned off.
That cut reduces what you still have to migrate, secure, and operate. Application rationalization work points the same way: align apps with business goals, and you shrink redundancy and technical debt.
Mapping Dependencies Before They Break Things
Applications rarely live in isolation. Mapping connections across applications, databases, networks, identity systems, and third-party services prevents the scenario where one team migrates a system, only to discover a batch job or hardcoded file path still points to the old environment.
In Cloudtech's work with SMB clients, this isn't theoretical. One regional medical practice missed an on-premises directory dependency during a patient-management migration, locking staff out of critical systems for hours. A pilot migration at a second clinic location caught the same dependency early, leading to a proper AWS Directory Service deployment before the main cutover.
Reviewing Technical Health
A technical health review surfaces the things that quietly inflate migration effort:
- Legacy runtimes and unsupported components
- Scalability and performance constraints
- Accumulated technical debt
- Integration patterns incompatible with target AWS services
Accounting for Regulatory and Business Risk
Industry obligations change what "ready to migrate" actually means. For healthcare organizations handling electronic protected health information, HHS guidance on cloud computing and HIPAA makes clear that a covered entity or business associate must understand its cloud environment well enough to conduct its own risk analysis before migrating.
Financial institutions face similar due-diligence expectations from the FFIEC around provider security and control allocation.
A pre-migration checklist should flag applications or data touching HIPAA, GDPR, or PCI-DSS requirements before a disposition is assigned.
Comparing Current and Future Costs
Cost decisions require more than a gut feeling. A detailed business case compares current application and infrastructure spending against the proposed AWS operating model. Factor in licensing transferability, modernization effort by workload, and parallel-run costs during cutover.
Skipping this step is how organizations end up with cloud bills that surprise finance three months in.
How the Assessment Works
A reliable assessment blends technical discovery with business validation. Skip ownership confirmation, dependency validation, or a post-assessment review, and you're left with a roadmap nobody trusts.
Step 1: Define the Assessment Objective and Scope
Start by naming the business driver: AWS migration, a data-center exit, cost optimization, a security improvement mandate, merger integration, or retiring end-of-life technology. Then define:
- Decision criteria and application population
- Stakeholders who need to sign off
- Target cloud environment and timeline
- Required deliverables
Step 2: Build and Validate the Application Inventory
For each application, capture:
- Owner and business capability
- User base and support model
- Vendor or development model
- Hosting location and lifecycle stage
- Technology stack, data types, and integrations
Pull from discovery tools, CMDB records, architecture docs, usage data, contracts, and interviews, then reconcile conflicts. Flag shadow IT, undocumented integrations, and unclear ownership for follow-up. That is often where the real risk hides.
Step 3: Map Dependencies and Assess Technical Health
Document connections among applications, databases, APIs, identity systems, file stores, batch jobs, and external providers. Evaluate architecture, performance, scalability, observability, security posture, and compatibility with target AWS services.
Record a confidence level for each finding. Verified evidence and untested assumptions should never look the same on paper.
Step 4: Evaluate Business Value, Risk, Cost, and Complexity
This step pulls everything together:
- Business criticality — revenue impact, user importance, downtime consequences
- Cost — current licensing, infrastructure, staffing versus migration effort
- Risk — security, privacy, compliance, vendor, and technical-debt exposure, scored on a transparent scale
- Complexity — architecture, data volume, integration count, testing needs, organizational readiness
Step 5: Assign a Migration Disposition
Map each application to one of the 7 R strategies, based on AWS's framework:
| Strategy | What It Means |
|---|---|
| Rehost | Move without changes ("lift and shift") |
| Replatform | Move with light optimization for cost or cloud capability |
| Refactor | Re-architect for cloud-native agility and scalability |
| Repurchase | Replace with a different product or SaaS version |
| Relocate | Move servers to a cloud version of the platform as-is |
| Retain | Keep in its current environment for now |
| Retire | Decommission or archive |
Not every application should default to lift-and-shift. Choose based on business value, technical feasibility, risk, and time-to-value. Flag items that need deeper analysis, a pilot, or executive sign-off before you lock the decision.
Step 6: Prioritize Applications and Create Migration Waves
Group applications by shared dependencies, business unit, technical pattern, and readiness. Each wave needs prerequisites, owners, test environments, rollback criteria, and a cutover window. Define success criteria for functional continuity, performance against baseline, and security validation.
Step 7: Validate, Execute, and Reassess
Present findings to application owners, security, finance, and engineering so disputed assumptions get corrected before execution, not during it. Establish governance to track decisions, exceptions, and architecture changes throughout the program.
The portfolio is not a one-time document. Reassess it after major business, regulatory, vendor, or cloud-cost changes.
Example Walkthrough: A Customer-Facing Application
Here is how the seven steps look on a single app.
Picture a customer-facing stack: web front end, database, authentication service, reporting integration, and a third-party payment API.
During assessment, the team confirms the business owner (unclear after a reorg), maps dependencies, and finds the reporting path depends on a nightly batch job missing from the CMDB. A technical review also shows the authentication service runs on an unsupported runtime.
Given high business criticality and moderate-to-high technical debt, the provisional disposition is replatform: move the database to Amazon RDS, update authentication, and defer a full refactor until usage patterns are confirmed.
Before finalizing, the team requires a security review of the payment API integration and sign-off from the finance stakeholder who owns transaction SLAs.
The wave plan then includes:
- A staging environment that mirrors production
- A rollback trigger if transaction latency exceeds baseline by more than 15%
- A 30-day post-migration review of cost and performance against projections
How Cloudtech Can Help
Cloudtech is a boutique AWS consulting partner based in New York City, working with U.S. SMBs, startups, and mid-market companies across healthcare, financial services, manufacturing, and SaaS. We don't run enterprise-scale engagements with months of overhead. Our assessments are built for teams that need clear answers, fast.
Our AWS-certified solutions architects, most of them former AWS employees, combine portfolio discovery, dependency analysis, technical health review, security considerations, and wave planning into one coordinated engagement. We use AWS-native tools such as Application Discovery Service, Migration Evaluator, and Systems Manager Inventory to build evidence rather than guesswork. Those findings become a disposition and roadmap your team can act on.
A few things that shape how we work:
- Assumptions stay documented, so nothing gets treated as fact until it's validated
- Recommendations match your actual constraints, not a generic enterprise template
- Work runs alongside your stakeholders as an extension of your team, not a vendor slide-deck handoff
If you're staring at a mixed application portfolio and don't yet know what should move, wait, or retire, let's talk through an application portfolio assessment. We can map what an AWS migration roadmap could look like for your business.
Conclusion
An application migration portfolio assessment gives you the clarity to decide what to migrate, what to modernize, what to replace, and what to leave alone. That clarity holds only when it rests on technical evidence and validation from the people who own the applications.
Treat the resulting roadmap as a living document. Review it when the business changes, when regulations shift, or when your cloud costs stop matching projections.
Your next step is small:
- Define the assessment scope
- Pull together the application inventory
- Identify key stakeholders
- Validate your first batch of migration candidates
Frequently Asked Questions
What are examples of portfolio assessment?
Examples include evaluating an application's business value, technical health, dependencies, cost, risk, lifecycle status, cloud readiness, and eventual migration disposition. Each is assessed individually, then compared across the portfolio.
What is the purpose of a portfolio assessment?
It supports informed decisions on investment, modernization, migration, consolidation, replacement, retention, and retirement. The goal is to replace assumptions with documented evidence before spending or scheduling anything.
What is included in an application migration portfolio assessment?
A complete assessment includes the application inventory, business and technical evaluation, dependency mapping, risk and cost analysis, a migration strategy per application, prioritization, and a wave-based roadmap.
How do you assess an application before migrating it to the cloud?
Start with discovery and stakeholder interviews, then map dependencies and review technical and security posture. Model costs, select a disposition, and plan the migration wave with clear success criteria and rollback steps.
What are the 7 Rs of application migration?
The 7 Rs are rehost, relocate, replatform, refactor, repurchase, retire, and retain. The right choice for each application depends on its business value, technical condition, and future-state needs.
