An interviewer says - you have two weeks with a 15-year-old system nobody understands and no documentation. At the end you must tell the board whether to replace it. What do you actually produce?

What the interviewer is testing

Whether you can produce a decision-grade answer from evidence rather than from reading code. Two weeks is enough to understand how a system behaves and nowhere near enough to understand how it works. A candidate who proposes to read the source has misjudged the budget; one who proposes to interview "stakeholders" has not said what they would ask.

The clarifying questions that change the answer

• What decision is actually in front of the board - replace, invest, freeze, or outsource? "Should we replace it" is rarely the real question; "can we keep doing business on this for three more years" usually is.
• What hurts today? Change lead time, incident rate, an audit finding, a supplier withdrawal, a skills shortage, or a licence renewal. The answer determines which evidence matters.
• Is there a date forced by someone else - a hardware end-of-life, an OS out of support, a regulation, a contract? A forced date converts the analysis from a value judgement into a schedule.
• Who still touches it, and how often does a change go wrong?

Where I would look, in order

1. The deployment pipeline and the runbooks. They name the components that actually exist, which no diagram does.
2. The database. Schema, row counts, growth, and the ten largest and ten most-written tables. The data model is the system's real domain model, and it survives when the code's intent has been lost.
3. Production telemetry and logs. Top endpoints by volume, batch schedule, error patterns, and the integration points that talk to the outside world. This is how you find the functionality that is used, as opposed to the functionality that exists.
4. Version control history. Where change concentrates, which files change together, who committed, and what the churn has been for two years. Hot spots are where the cost of change lives.
5. The incident record and the change-failure rate, which is the single most persuasive number available to a board.
6. Four or five people: the person who gets paged, the person who makes changes, the business owner of the most-used function, and whoever handles the integrations. One hour each, asked what breaks and what they refuse to touch.

What I deliver in two weeks

• A component inventory with evidence of use, marking what is live, what is dead and what is unverified.
• An integration map - every system that depends on this one and every one it depends on - because that is what determines the cost of replacement.
• Three to five numbers the board can act on: change lead time, change failure rate, incidents per quarter and their cost, annual run cost including licences, and the number of people who can safely change it.
• The forced dates, if any, on a timeline.
• A disposition recommendation per component rather than for the system, using the six Rs, with the reasoning stated. Most 15-year-old systems are a mixture: a core worth keeping, a periphery worth retiring, and one component that is the actual problem.
• The one-page risk statement: what happens if nothing is done for two years, written in business terms.

Common weak answers

• "Produce a full architecture document." It would be out of date, unverifiable and unread.
• "Recommend a rewrite." Without a quantified cost of the current state, this is a preference. Boards have seen rewrites fail and will ask for the number.
• "Run static analysis over the codebase." Useful supporting evidence and it answers a question nobody asked. Lines of code and cyclomatic complexity do not predict business risk; change failure rate does.

What a strong answer adds

An explicit statement of what 10 working days cannot establish - undocumented edge-case behaviour, which is exactly where migration programmes fail - and a proposal for how to find it later: a comparison harness that runs the legacy and the candidate side by side on real inputs for 3 months before any cutover. The public record is the argument for that caution: the US IRS began its CADE 2 replacement of the Individual Master File in 2009 and the Government Accountability Office was still reporting revised completion dates years later, and the common factor in such programmes is behaviour that existed only in the old code.

Prefer a per-component recommendation with a stated reversal condition - revisit if the supplier announces withdrawal, or if change failure rate exceeds 20% - over a single verdict on the whole system. That is what separates advice from a decision a board can own, and it is also what stops a two-week assessment being quoted as a mandate 18 months later.