# TEL203: Legacy System Assessment
https://www.telosready.com/skills/TEL203?v=2
The process Telos uses to assess the feasibility of rebuilding or re-platforming a legacy system — from initial code access through to a scoped feasibility output. Use when a prospect has an existing system they need evaluated.

## Instructions
# Legacy System Assessment

When a prospect has an existing system — particularly an old or undocumented one — Telos can run a first-pass assessment to establish feasibility: what it would take to rebuild, re-platform, or support the system. This is not a full blueprint engagement; it is a scoped, low-commitment exercise designed to answer the question: *is this worth pursuing, and at roughly what scale?*

## When to use this

- A prospect is evaluating whether to rebuild a legacy system
- No documentation exists and the system's complexity is unknown
- The prospect needs something concrete to present to a board or leadership team before committing to a full engagement

## The assessment process

### 1. NDA and code access
Telos signs a non-disclosure agreement and receives a copy of the source code. The code is used solely for analysis purposes — no reuse, no retention beyond the engagement.

### 2. Software walkthrough
Before any code analysis begins, Telos asks for a walkthrough of the live system. This can take 1–4 hours depending on complexity. The walkthrough gives the AI a frame of reference — the language of the system, its information architecture, and the main user flows. It materially improves the quality of subsequent analysis.

### 3. First-pass code analysis
Telos runs a targeted analysis — not a full deep-dive, but enough to understand the breadth of the system. The output is a set of scope tickets: discrete, sized units of work representing the modules, functions, or domain areas identified in the code.

### 4. Subject matter interview
Where possible, Telos interviews someone with deep knowledge of the system — the original developer, a long-tenured support engineer, or a key business user. Code analysis surfaces what the system does; interviews surface why, and where the hidden complexity lives.

### 5. Feasibility output
The assessment produces a plain-language summary covering:
- Breadth of scope (number and nature of modules identified)
- Complexity indicators (language, architecture, data model legibility)
- Indicative time and cost range for a rebuild or re-platform
- Recommended next steps

This output is suitable for internal use; it gives leadership a concrete basis for a go/no-go decision on a full engagement.

## Notes on legacy languages

AI tools perform best with modern, widely-used languages. Older or proprietary languages (e.g. Progress, COBOL, RPG) will be less familiar to the models. In these cases:
- Analysis scripts are tuned in advance to guide the AI on what to look for
- Human subject matter experts become more important as a complement to code analysis
- The first-pass may be more limited in depth, and that should be communicated upfront

## Proving documentation is complete

Documentation of a legacy system is difficult to trust because blind spots are invisible by definition. You can review three sections and conclude they look correct without knowing what is missing. The only reliable way to prove documentation is complete is to build from it — the act of building forces every business rule to be understood and encoded, because you cannot build what you don't understand.

Where the engagement includes a build phase alongside documentation, the resulting prototype serves as proof of completeness. If the system can be built from the documentation, the documentation is accurate. If it cannot, the gaps surface during construction — where they can be resolved — rather than later, where they cause failures.

Engagements that produce documentation without a build phase can still be thorough and valuable, but the documentation remains untested. This distinction should be communicated clearly to clients when scoping.

## What this is not

This is not a project plan, a fixed-price quote, or a commitment to build. It is a feasibility signal — enough information to decide whether a full blueprinting engagement makes sense.

# Legacy System Assessment

When a prospect has an existing system — particularly an old or undocumented one — Telos can run a first-pass assessment to establish feasibility: what it would take to rebuild, re-platform, or support the system. This is not a full blueprint engagement; it is a scoped, low-commitment exercise designed to answer the question: *is this worth pursuing, and at roughly what scale?*

## When to use this

- A prospect is evaluating whether to rebuild a legacy system
- No documentation exists and the system's complexity is unknown
- The prospect needs something concrete to present to a board or leadership team before committing to a full engagement

## The assessment process

### 1. NDA and code access
Telos signs a non-disclosure agreement and receives a copy of the source code. The code is used solely for analysis purposes — no reuse, no retention beyond the engagement.

### 2. Software walkthrough
Before any code analysis begins, Telos asks for a walkthrough of the live system. This can take 1–4 hours depending on complexity. The walkthrough gives the AI a frame of reference — the language of the system, its information architecture, and the main user flows. It materially improves the quality of subsequent analysis.

### 3. First-pass code analysis
Telos runs a targeted analysis — not a full deep-dive, but enough to understand the breadth of the system. The output is a set of scope tickets: discrete, sized units of work representing the modules, functions, or domain areas identified in the code.

### 4. Subject matter interview
Where possible, Telos interviews someone with deep knowledge of the system — the original developer, a long-tenured support engineer, or a key business user. Code analysis surfaces what the system does; interviews surface why, and where the hidden complexity lives.

### 5. Feasibility output
The assessment produces a plain-language summary covering:
- Breadth of scope (number and nature of modules identified)
- Complexity indicators (language, architecture, data model legibility)
- Indicative time and cost range for a rebuild or re-platform
- Recommended next steps

This output is suitable for internal use; it gives leadership a concrete basis for a go/no-go decision on a full engagement.

## Notes on legacy languages

AI tools perform best with modern, widely-used languages. Older or proprietary languages (e.g. Progress, COBOL, RPG) will be less familiar to the models. In these cases:
- Analysis scripts are tuned in advance to guide the AI on what to look for
- Human subject matter experts become more important as a complement to code analysis
- The first-pass may be more limited in depth, and that should be communicated upfront

## Proving documentation is complete

Documentation of a legacy system is difficult to trust because blind spots are invisible by definition. You can review three sections and conclude they look correct without knowing what is missing. The only reliable way to prove documentation is complete is to build from it — the act of building forces every business rule to be understood and encoded, because you cannot build what you don't understand.

Where the engagement includes a build phase alongside documentation, the resulting prototype serves as proof of completeness. If the system can be built from the documentation, the documentation is accurate. If it cannot, the gaps surface during construction — where they can be resolved — rather than later, where they cause failures.

Engagements that produce documentation without a build phase can still be thorough and valuable, but the documentation remains untested. This distinction should be communicated clearly to clients when scoping.

## What this is not

This is not a project plan, a fixed-price quote, or a commitment to build. It is a feasibility signal — enough information to decide whether a full blueprinting engagement makes sense.