Legacy Application Assessment Services

Section 01

The Challenge

Legacy application assessment solves a visibility problem before it becomes an execution problem: organizations that begin modernization programs without a rigorous portfolio inventory migrate the wrong applications in the wrong order, or miss critical security vulnerabilities in systems they didn't know existed. Skipping a formal assessment raises the risk of wave failures and remediation rework.

The CMDB accuracy problem compounds the visibility gap. Central configuration management databases go stale as teams provision resources outside formal change management processes. CMDB-only portfolio inventories commonly miss running applications, including "zombie applications" (running but not used) and "shadow IT" (deployed by business units without IT knowledge). These undiscovered applications are disproportionately likely to run EOL software, because they were forgotten before patching routines captured them.

Portfolio assessment is a well-understood, lower-risk engagement compared to migration execution. When it fails, the cause is almost always post-assessment: organizations commission assessments without pre-committed budget for remediation, resulting in a risk register that stays on a shelf.

Section 02

How to Evaluate Providers

Legacy application assessment providers differentiate on discovery methodology, scoring rigor, and deliverable quality. The key question is: how do they find applications you don't know about?

Discovery methodology comparison:

Coverage, time and cost depend on your environment; ask each provider to state expected coverage and how they would verify it.

Red flags:

• Assessments that rely exclusively on CMDB exports (misses applications outside the central inventory)
• No business criticality scoring methodology beyond IT perspective (business owners know which systems drive revenue, not just IT)
• T-shirt sizing effort estimates without methodology documentation (effort estimates with no rationale cannot be challenged or calibrated)
• Deliverables in read-only PDF format (assessment outputs must be editable so teams can maintain them post-engagement)

What to look for: Providers with specific automated scanning tool expertise (CAST Highlight for large portfolios, Veracode for security-focused assessments), case studies from similar portfolio sizes and industries, and deliverables that include unlocked Excel and interactive dashboards.

Section 03

Implementation Patterns

Successful legacy assessments combine automated scanning with business owner interviews. Automated tools provide coverage and objectivity; interviews provide business context that tools cannot infer from code.

Phased discovery pattern:

1. Automated inventory (week 1–2): Network scanning identifies all running applications. Static code analysis tools (CAST Highlight, SonarQube) produce objective code quality metrics (cyclomatic complexity, technical debt ratio, security vulnerability counts). This phase is non-disruptive: no code changes, no downtime.
2. Business criticality interviews (week 2–3): Application owners scored on business impact (revenue dependency, regulatory criticality, user count), business value (strategic vs commodity), and change frequency (how often does business need updates). IT perspective alone systematically underestimates business criticality for applications used by specific business units.
3. 7 Rs disposition (week 3–4): Apply the 7 Rs framework to each application using combined technical scores (from automated analysis) and business scores (from interviews). The disposition framework: Retire (decommission), Retain (keep in the source environment, don't migrate), Rehost (move to cloud as-is), Relocate (move infrastructure to the cloud without changing the applications, for example hypervisor-level moves), Replatform (minor cloud optimizations), Repurchase (replace with SaaS), Refactor (significant code changes).
4. Prioritized roadmap (week 4–6): Sequence migration waves by combining: quick wins (high value + low complexity), risk reduction (critical security vulnerabilities), and strategic alignment (applications blocking digital transformation goals).

Zombie application identification: Applications that generate network traffic but have no active business users are candidates for immediate retirement. Portfolios often contain some of these: running, licensed, and patched for systems nobody needs. Count them in your own estate; retiring them before migration reduces migration scope and produces immediate licensing and hosting savings.

Technical debt quantification: Assessment deliverables should include a $ estimate of technical debt, not just a "high/medium/low" rating. The SQALE method (CAST, SonarQube) estimates technical debt as the engineering hours required to bring code to acceptable quality standards. This enables direct ROI comparison, such as the one-time cost of fixing an application's technical debt against the annual fee for a SaaS replacement over your planning horizon.

Section 04

Total Cost of Ownership

Legacy assessment is a high-leverage modernization engagement because it can prevent misallocation of much larger migration budgets. Organizations that act on assessment findings can avoid migration waste (migrating the wrong applications, encountering undiscovered dependencies, redundant remediation). Ask each assessor to estimate the avoidable waste for your portfolio and show the calculation.

Cost model by portfolio size:

Hidden costs beyond the engagement fee:

Zombie app retirement savings: Assessments often surface applications that are retirement candidates. Price each candidate's annual licensing, hosting and maintenance cost from your own records, and net it against decommissioning effort to test whether the assessment cost is recovered within the first year.

Section 05

Post-Engagement: What Happens Next

After a legacy assessment, you own an application portfolio inventory, technical debt heatmap, 7 Rs disposition plan, and a sequenced modernization roadmap. The next step is committing budget to act on findings.

Typical post-engagement sequence:

• Week 1–4 post-assessment: Review findings with executive team. Approve budget for modernization program. Assign internal application owners to each application in the disposition plan.
• Month 1–3: Retire zombie applications (immediate cost savings, zero migration risk). Begin Wave 1 (highest-priority, lowest-complexity applications).
• Month 3–12: Execute migration waves following the assessment roadmap. Reassess changed applications if major scope changes occur.
• Month 12–24: Mid-program review. Validate that TCO projections from assessment are tracking actual results. Adjust wave sequencing if business priorities have shifted.

Keeping the assessment current: Portfolio assessments go stale as applications are deployed, retired, and changed. Plan a lightweight refresh assessment on a regular cadence (every year or two is a reasonable starting point), or after major events (M&A, major cloud migration, significant new application deployments).

Connecting assessment to execution: The assessment roadmap should directly inform your migration program's Wave 1 scope. Organizations that let assessment deliverables sit for many months often have to re-commission assessments before acting — paying twice for the same analysis.

Evidence note: Earlier versions of this page cited project counts, median costs and timelines, and success rates that could not be reproduced from available records; they have been withdrawn. Cost and timeline ranges are editorial scoping ranges, not supplier quotes. See our methodology.

---

Section 06

Pain Points

The 'Black Box' Problem

You have dozens of apps written on long-unsupported runtimes such as Java 6 or .NET 2.0. The original developers left years ago. No one knows how they work, only that they break if you touch them.

M&A Due Diligence

You just acquired a company. Their CTO says the tech is 'modern'. You need a third-party audit to prove it's actually spaghetti code before you integrate it.

Cloud Migration Stalled

You tried to 'Lift & Shift' everything to AWS. It failed because the apps weren't cloud-ready. Now you need to know which ones to refactor and which to retire.

Compliance Audit Panic

Auditors are asking for a list of all systems running EOL (End of Life) software. You don't have that list. You need an automated inventory immediately.

---

Section 07

Methodology

Automated Discovery (1-2 weeks)

Activities:

• Static Code Analysis (CAST, SonarQube)
• Infrastructure Scanning
• Dependency Mapping Outcomes:
• Raw Inventory Data
• Vulnerability Report

Contextual Interviews (2 weeks)

Activities:

• Interviews with remaining SMEs
• Business value assessment (Is this app worth saving?)
• Regulatory review Outcomes:
• Business Criticality Scores
• Hidden Knowledge Capture

Analysis & Roadmap (2 weeks)

Activities:

• 7 Rs Workshop
• Cost-Benefit Analysis
• Sequencing the roadmap Outcomes:
• Final Assessment Report
• Executive Presentation

---

Section 08

Deliverables

• Application Portfolio Inventory (Excel / CMDB Import): A complete list of every application, its language, framework version, database, and dependencies. No more 'I think we have that'.
• Technical Debt Heatmap (Interactive Dashboard): Visual dashboard showing risk scores for every app. Based on code complexity (Cyclomatic), security vulnerabilities (CVEs), and EOL components.
• 7 Rs Disposition Plan (PPT + Excel): The verdict for each app: Retire, Retain, Rehost, Relocate, Replatform, Repurchase, or Refactor (the AWS 7 Rs). Includes estimated effort (T-shirt sizing) for each.
• Cloud Suitability Scorecard (Excel): 0-100 score for every app's readiness for cloud. Checks for hardcoded IPs, local file storage, stateful sessions, and other cloud blockers.

---

Section 09

Team Composition

• Solution Architect: The 'Detective'. Digs into the code and architecture to find the truth.
• Business Analyst: The 'Translator'. Maps technical complexity to business value.
• Security Specialist: Checks for vulnerabilities and compliance risks.

---

Section 10

Success Factors

• Access to Source Code (No code, no assessment)
• Access to Production Infrastructure (Read-only)
• Availability of SMEs (Even if they only know a little)

---

Section 11

Decision Framework

When to proceed

• You have more applications than anyone can track from memory and no central inventory of which are business-critical versus zombie apps
• A cloud migration or major modernization program is planned in the next 12 months and you need to sequence the work
• An M&A transaction requires technical due diligence on an acquired company's application portfolio
• A compliance audit has requested documentation of all systems running EOL software
• A new CTO or CIO has joined and needs an honest landscape assessment before committing to a roadmap

When NOT to proceed

• You have only a handful of applications; a manual inventory is faster and more accurate
• You already know exactly what you want to modernize and the scope is defined; start execution directly
• You have no budget to act on findings; an assessment without remediation budget wastes the investment
• Your portfolio was assessed within the last 12 months and no major changes have occurred

Alternatives to consider

• Cloud Readiness Assessment: More focused on migration suitability and TCO than overall portfolio health — Best for: Organizations specifically planning cloud migration rather than broad portfolio modernization
• Modernization Strategy Services: Combines portfolio assessment with strategic roadmap and financial modeling — Best for: Organizations needing both portfolio analysis and board-level business case