Assessing a Legacy Application

The assignment

Before Meridian spends a dollar on AssetTrack, you need to know what it actually is — not what the wiki from 2019 says it is. You have read access to the repository and one afternoon. A decade ago this was three weeks of consultant time. Today you open your AI CLI at the repo root and drive.

Prompt first

Assess this codebase for modernization planning. Produce exactly four artifacts:

1. CURRENT-STATE TABLE: every major component of the stack (framework,
   runtime, data access, UI layer, build system, key libraries) with columns:
   Component | Version in use | Current supported version | Risk if unchanged.

2. WEAKNESS LIST: the top structural weaknesses, numbered. Each must be
   specific and countable (e.g., "code-behind logic in 74 WebForms pages"),
   never vague (e.g., "outdated architecture").

3. SUCCESS METRICS: measurable targets a modernization of this app should be
   held to (security, performance, maintainability). Numbers, not adjectives.

4. RISK REGISTER: the top risks of modernizing, each paired with a concrete
   mitigation.

Read the code before answering. Cite file paths as evidence for every claim.

The prompt does the shaping; the AI does the reading. Two things make this prompt work harder than a generic “review this code”:

• It names the artifacts. You get a current-state table, a weakness list, success metrics, and a risk register — the four sections every downstream decision in Lessons 1.3, 1.4, and 2.1 will consume.
• It bans vagueness. “Specific and countable” and “cite file paths” turn the output from vibes into evidence you can defend in front of a steering committee.

What comes back: the current-state table

For AssetTrack, the table lands like this (abridged):

One table, one glance, and the shape of the problem is visible: the platform is frozen (Framework 4.8 is the end of its line), the UI layer has no forward path at all, and the release process is a single point of human failure.

Weaknesses as decision criteria

A weakness list earns its keep when each line can anchor a decision. Compare:

Weak: “The application uses outdated patterns and has technical debt.”

Strong:

1. UI logic locked in WebForms code-behind - 212 pages, no port path to modern .NET
2. Business rules duplicated between app code and Oracle stored procedures - 47 procedures
3. No automated tests - 0% coverage on a codebase with nightly batch jobs
4. Build and release known to one engineer - single point of failure
5. Session state in-process - blocks running more than one instance
6. Batch jobs coupled to local file paths - blocks any move off the VMs

Every line is countable, and every line points somewhere: line 1 says the UI cannot be ported, only rebuilt; line 5 says even a simple rehost cannot scale out; line 6 says the batch jobs block the exit from VMs. In Lesson 1.3 you will feed lists like this directly into the build-vs-adopt-vs-extend decision.

Success metrics: numbers, not adjectives

“More maintainable and secure” cannot be verified, so it cannot gate a phase. The assessment’s metric set must look like this:

Security:      zero critical/high findings in dependency and code scans
Performance:   p95 page load under 3 seconds; nightly batch window under 2 hours
Reliability:   app runs as 2+ instances behind a load balancer (kills weakness #5)
Maintainability: 80% test coverage on business-rule code; release runbook
               executable by any engineer on the team

Each metric traces back to a weakness. That is the pattern: weakness list and success metrics are the same facts, written as before and after.

The risk register

Modernizing carries its own risks, and the register pairs each with a mitigation, not a worry:

Your turn

Run the four-artifact prompt against a codebase you own — any aging project qualifies. And note what just happened to the economics: this used to be weeks of consulting effort, which meant it happened once and went stale. Now it is an afternoon, which means it should happen repeatedly — Lesson 5.1 turns that from an observation into an operating model. Then apply the two quality gates: every weakness countable, every metric a number. Where the AI hedges, that is exactly where to dig.

Key takeaway

An assessment is four artifacts — current-state table, countable weakness list, numeric success metrics, risk register with mitigations — and your AI CLI can draft all four from the code in an afternoon. Your job is the two quality gates: every claim cited, every metric a number. Next lesson, this evidence meets FieldDesk’s three possible futures.