The portfolio spreadsheet has 183 rows. Twelve are marked business critical. Forty-seven have no owner. One application called “Claims Portal 2” appears four times, and nobody in the meeting knows which row pays the current hosting bill.
Do not score it yet.
An application portfolio assessment works better in three passes. The first tests what exists and how confidently the organization knows it. The second spends attention only where better evidence could change a decision. The third turns application decisions into a dependency-aware sequence.
That order prevents a weak inventory from producing a very precise fiction.
Pass one: establish inventory confidence
Begin with identifiers and evidence sources, not workshops about strategy. Collect the application list from several places:
- configuration and asset records
- identity-provider applications and service accounts
- infrastructure and cloud spend
- network and observability records
- source repositories and deployment systems
- vendor contracts and renewal schedules
- support queues and incident records
- department-maintained spreadsheets
Each source sees a different slice. Reconcile them into a record with a stable application identifier. Preserve aliases rather than deleting them. “Claims Portal 2,” its repository name and its cloud account tag may all refer to the same application; that relationship is evidence.
Use confidence beside every material field:
| Field | Value | Source | Confidence | Owner to confirm |
|---|---|---|---|---|
| Business purpose | Claims intake for two products | Product record and interviews | Medium | Claims operations lead |
| Technical owner | Platform team | Repository ownership file | High | Platform director |
| Monthly run cost | Partial cloud allocation | Billing export | Low | FinOps owner |
| Users | Agents and brokers | Identity logs | Medium | Product owner |
| Data | Claim detail and documents | Data-flow review | Medium | Data owner |
| Dependencies | Identity, policy system, document store | Trace and code sample | Medium | Application architect |
Unknown is a valid value. It is more useful than a confident guess because it can become an investigation task.
AWS’s application portfolio assessment guide separates portfolio-level discovery from detailed application assessment. That distinction applies beyond an AWS migration: breadth finds the estate, while depth is reserved for decisions that need it.
Create the first sort without pretending it is final
Use pass-one evidence to place applications into working groups. Avoid a decimal score that hides missing facts.
Four questions are enough for the first sort:
- Does the application support a current business capability?
- Is there an accountable business and technical owner?
- Is a contract, platform limit, incident pattern or business change forcing a decision?
- Can the team explain its main dependencies with evidence?
The result is not the final disposition. It selects the next depth of work.
| Working group | Next action |
|---|---|
| Clear retirement candidate | Verify usage, retention and downstream dependencies |
| Decision forced soon | Run a detailed application assessment |
| Stable and understood | Retain with a review trigger |
| Important but poorly understood | Investigate missing ownership, flow and cost facts |
| Apparent duplicate | Compare users, data, contracts and required differences |
This pass should be quick enough to repeat. The estate changes while the assessment runs.
Pass two: inspect applications that can change the plan
Do not interview every team with the same 90-question form. Select applications where new evidence can alter sequence, cost or risk.
For each selected application, follow one business transaction. A claim moves from submission to review to payment. An order moves from capture to allocation to shipment. A member moves from enrollment to eligibility response.
Trace the transaction through users, interfaces, stores and external services. Then examine six evidence areas:
| Evidence area | Decision it can change |
|---|---|
| Business fit | Retain, replace or retire |
| Change pressure | Act now, defer or stabilize |
| Technology lifecycle | Upgrade, isolate, replatform or replace |
| Data and security | Migration boundary, control work and sequencing |
| Dependencies | Cluster, order and coexistence period |
| Delivery capability | Modernize internally, buy support or change scope |
AWS recommends validating institutional knowledge and static documents with programmatic discovery where possible. Its detailed assessment guidance covers stakeholders, architecture, software lifecycle, performance, licensing, service expectations and migration considerations. Treat that as a source of prompts. A non-cloud portfolio decision may need a different disposition set.
Test dependencies with two kinds of proof
Application owners remember important connections and miss quiet ones. Tooling sees traffic and misses business dependence.
Use both.
Ask people which upstream delay stops the application and which downstream team notices a bad change first. Then compare those answers with network flow, job schedules, identity calls, queue traffic, database links and repository configuration.
Record each dependency with direction and consequence:
| Dependency | Direction | Failure consequence | Evidence | Change owner |
|---|---|---|---|---|
| Identity provider | Inbound | Users cannot start a case | Sign-in trace and config | IAM team |
| Policy system | Inbound and outbound | Coverage cannot be checked or updated | API logs and contract | Policy platform owner |
| Document store | Outbound | Adjusters lose supporting records | Object and access logs | Content platform team |
| Finance export | Outbound batch | Approved payments wait | Job history and control total | Finance systems owner |
A line on a diagram is not enough. The sequence needs to know what breaks, who can change the contract and how coexistence will be tested.
Assign dispositions in local language
Cloud programs often use named “R” models. Those models can help, but the decision record should use words the business and delivery teams understand.
Allow at least these outcomes:
- retain under current ownership
- retire after verified dependency and data work
- replace with a product or shared capability
- migrate with minimal application change
- modernize a bounded part
- stabilize and defer
- investigate before disposition
Write the evidence and the non-fit condition beside the outcome. “Modernize” is not a plan. “Extract document intake because releases to the claims core are blocked by vendor support, while retaining adjudication until replacement funding is approved” is a decision that can be tested.
Do not force every row toward cloud. The portfolio may contain a low-change application that meets its service needs and has no economic reason to move. Retain is a real outcome.
Pass three: sequence dependency clusters
An ordered list of application scores will split systems that must change together. Build clusters from shared data, identity, interfaces, business events, contracts and teams.
Then sequence the clusters against constraints:
| Sequence constraint | Evidence needed |
|---|---|
| Renewal or end-of-support date | Contract or vendor notice and decision deadline |
| Business blackout | Operating calendar and accountable owner |
| Shared platform readiness | Tested capability, capacity and support route |
| Data coexistence | Reconciliation, ownership and cutover method |
| Team capacity | Named people, competing work and skill gaps |
| Recovery | Rollback boundary and rehearsal result |
The first wave should teach the program without gambling a core business flow. Pick a cluster with a real outcome, visible dependencies and a reversal path. Avoid a toy application that proves only that the team can move a toy.
Keep the directional business case honest
Early cost estimates are ranges. Mark what they include: licenses, infrastructure, vendor fees, internal engineering, data work, parallel run, testing, training, support and retirement.
Separate current run cost from change cost. A high run cost does not make an application easy to replace. A cheap application may carry an expensive dependency.
AWS publishes a detailed list of application, infrastructure, network and migration attributes for a complete portfolio view. Its data-requirements table also distinguishes minimum fidelity by use. That is the right instinct: collect detail because a decision needs it, not because a spreadsheet has a column.
Deliver an action board that can age
The portfolio will not stay still. Deliver records that can be updated without rerunning the whole consulting project.
Each action card should name the application or cluster, disposition, evidence confidence, unresolved facts, decision owner, next proof, deadline and event that reopens the decision. Link the card to its source evidence.
Review the board when a contract changes, a platform reaches end of support, a material incident occurs, an owner leaves, a business capability closes or new usage appears. Do not schedule a ceremonial annual review if the real triggers happen monthly.
An application portfolio assessment is done when the organization can explain what it knows, what it does not know and which owned decision comes next. A color-coded inventory with no sequence is still an inventory.