Application Portfolio Assessment: Migration Readiness Scoring Framework

Why Assessment Before Migration Is Non-Negotiable

A financial services company starts migrating without a portfolio assessment. The infrastructure team picks applications based on perceived simplicity — "this one looks easy." Application #3 turns out to depend on a shared database that 12 other applications also use. Migrating it requires migrating the database, which means migrating the 12 dependent applications simultaneously — or building a complex hybrid connectivity layer. What was "easy" becomes a 6-month cross-team initiative that delays the entire migration program. Application #7 is migrated to a cloud VM, but post-migration performance testing reveals it requires GPU compute that costs 4x the budget. Application #15 is migrated, and then someone discovers it processes HIPAA-regulated data that has data residency requirements the target Azure region doesn't meet.

Every one of these surprises was discoverable in a 3-week assessment. The assessment costs 3% of the total migration budget. Skipping it produces surprises that cost 30-50% of the budget in rework, delays, and redesign. Assessment isn't optional — it's the highest-ROI phase of the entire migration program.

Application Discovery: Finding What You Actually Have

Most enterprises don't have an accurate application inventory. The CMDB says 250 applications. The actual count — including shadow IT, departmental tools, legacy systems nobody documented, and the 15 spreadsheet-based "applications" that Finance depends on — is 350+. Discovery closes this gap before scoring begins.

Automated Discovery

Azure Migrate Discovery: Deploys an appliance in your datacenter that scans VMware/Hyper-V environments, discovering: VMs and their resource utilization (CPU, memory, disk, network), installed applications and dependencies, database instances and versions, and performance data over 30 days. The 30-day performance data is critical — it shows actual utilization (not provisioned capacity), revealing which VMs are over-provisioned and which hit capacity constraints.

Network dependency mapping: Captures network connections between servers — which servers communicate with which, on which ports, at what frequency. This reveals application dependencies that no documentation captures: the web server that calls 3 backend APIs, the batch job that reads from 2 databases and writes to a shared file server, and the legacy system that communicates via FTP with 5 partners. Without dependency mapping, migrating one application unknowingly breaks 3 others.

Manual Discovery Supplement

Automated discovery captures infrastructure. Manual discovery captures business context: who owns this application? How many users? What business process does it support? What's the impact if it's unavailable for 4 hours? Is there a SaaS replacement available? This context comes from application owners through structured questionnaires — 15 minutes per application, producing the business context that automated tools can't capture.

The 8-Dimension Scoring Framework

Technical Assessment: Architecture, Dependencies, and Debt

Architecture analysis: Is the application monolithic or modular? Monoliths migrate as units — you can't migrate half. Modular applications (microservices, SOA) can migrate component by component, reducing risk per migration step. Document: application layers (web, API, business logic, data), communication patterns (synchronous REST, asynchronous messaging, shared database), state management (stateless, sticky sessions, local file storage), and external dependencies (third-party APIs, license servers, hardware dongles).

Technical debt scoring: Applications with high technical debt are risky to migrate — the migration may surface bugs that were latent on-premises. Indicators: age of the technology stack (how many versions behind current?), test coverage (does automated testing exist?), documentation (can someone other than the original developer maintain it?), and deployment process (automated CI/CD or manual copy-paste?). High-debt applications need stabilization before migration — or a deliberate decision to refactor during migration.

Dependency mapping detail: For each application, document: upstream dependencies (what feeds data to this application?), downstream dependencies (what consumes this application's output?), shared resources (shared databases, file shares, message queues), and integration patterns (API calls, file transfers, direct database reads, message bus). Dependencies determine migration groups — applications that share a database migrate together, not independently.

Business Assessment: Value, Cost, and Strategic Fit

The business assessment determines whether the application is worth migrating at all — and if so, how much investment is justified.

Business value quadrant: Plot each application on two axes: current business value (revenue impact, user count, process criticality) and future strategic importance (is this application part of the company's future or being replaced?). High-value + strategic = invest in proper migration (replatform or refactor). High-value + legacy = migrate efficiently (rehost) while planning replacement. Low-value + any = retire if possible, rehost cheaply if necessary.

Total cost of ownership analysis: For each application, calculate current TCO (infrastructure, licensing, support personnel, downtime cost) and projected cloud TCO (compute, storage, networking, managed services, support). The TCO comparison should include: right-sized cloud resources (not 1:1 mapping of on-prem specs), reserved instance pricing for steady-state workloads, and elimination of on-premises overhead (datacenter, hardware refresh, OS patching). Applications where cloud TCO exceeds on-prem TCO by more than 20% should be flagged for architecture review — there may be a more cost-effective cloud architecture, or the application may be a retain candidate.

Score-to-Strategy Mapping: Which R for Each Application

Dependency Mapping: Migration Groups, Not Individual Apps

Applications don't migrate individually — they migrate in dependency groups. A dependency group is a cluster of applications that share resources (databases, APIs, file stores) and must migrate together to avoid cross-environment communication complexity.

Group identification process: start with the dependency map from discovery, identify shared resources (each shared database creates a group), merge groups that share resources transitively (if A shares a DB with B, and B shares an API with C, then A/B/C are one group), and size each group (number of applications, total infrastructure, estimated migration effort). Small groups (2-3 apps) migrate in a single wave. Large groups (10+ apps) may need internal sequencing — migrate components in sub-waves with temporary hybrid connectivity.

Assessment Deliverables: The Migration-Ready Portfolio

The assessment produces four deliverables that drive all subsequent migration activity:

Go Deeper

Continue building your understanding with these related resources from our consulting practice.