Legacy application video walkthrough: capture it before the developer retires

A legacy application video walkthrough is the cheapest insurance a CIO can buy against the day the only person who understands the system hands in their notice. It records the running software, the paths users take through it, and the business rules those paths encode, in a form anyone can replay. This article explains what such a walkthrough must contain, why retirement risk makes it urgent, and how to commission one that produces evidence rather than a slide deck.

What a legacy application video walkthrough must capture

A useful walkthrough is not a tour of screens. It is a narrated record of the application behaving, with the reasoning behind each behaviour made explicit while the person who knows it is still available to explain.

Screens, paths and the business rules behind them

For each in-scope workflow, the recording should show the entry point, the fields a user fills, the validation that fires, the records created, and the downstream effect. Narrate the rules as you go: why this customer type bypasses that approval, why the discount caps at a particular threshold, why the batch job runs on the 27th. Those undocumented business rules are usually the part no repository records and no new developer can reconstruct with confidence.

The difference between what the code says and what it does

Legacy systems accumulate behaviour that diverges from their source: patches applied directly to production, database triggers added by a contractor, a spreadsheet that reconciles what the application gets wrong. A walkthrough driven through the live software exposes that gap. The code may suggest one calculation; the screen shows another. Capture both.

Evidence you can replay, not a handover slide deck

A deck tells you what someone believed on the day they wrote it. A recording with a dated outcome shows what the system actually did, which is testable later against a rebuilt system. That distinction matters enormously when the modernisation budget is being argued. The same asset should answer two questions at once: "what does this system do" and "what is our exposure". A short executive summary over the opening minutes, followed by detailed workflow recordings, satisfies both without producing two disconnected artefacts. Keep a single index so nobody has to hunt.

The roles a walkthrough has to serve

• The successor developer: needs field-level detail, error paths and the location of the relevant code.
• The IT manager: needs to know which workflows carry the most risk and where work is already queued.
• The auditor or consultant: needs a dated record of behaviour before any change.
• The business owner: needs to recognise their process and confirm the rules are correct.

Why a retiring developer makes a legacy application video walkthrough urgent

Retirement is a fixed date. Knowledge capture work, by contrast, always looks deferrable until the last fortnight, when it becomes impossible to do well. The report on legacy modernisation trends describes the pressure organisations face from ageing systems and the skills needed to maintain them, and the pattern is familiar across sectors.^[1]

The knowledge that only lives in one head

Most legacy estates have a handful of people who can explain the month-end process, the interface to the finance system, or why one report must never be run twice. That is tribal knowledge transfer that has never been written down because the system "just works". It is also the knowledge that leaves with a pension.

What happens when nobody can explain why the system behaves that way

Without an explanation, teams treat unexplained behaviour as sacred. Nobody dares change the calculation, so workarounds pile up around it. The result is a system that is expensive to maintain, risky to replace, and impossible to defend when a regulator or auditor asks why a rule exists.

Turning retirement risk into a dated, testable artefact

The goal is to convert a person's tacit understanding into a recorded, dated set of observations that a successor can test against. Once the walkthrough exists, the question changes from "who remembers?" to "does the new system reproduce this recording?" That is a far healthier position from which to plan a rewrite.

Signals your knowledge risk is already acute

1. Only one or two people can approve changes to a core workflow.
2. The last significant documentation update predates the current team.
3. Known retirements or departures fall inside the next eighteen months.
4. Test coverage exists, but nobody can explain what the tests protect.
5. Every release carries a manual regression checklist maintained by memory.

Takeaway: treat the departure date as a deadline for evidence, not for meetings. If the recording does not exist a month before the developer leaves, the knowledge is already at risk.

How a legacy application video walkthrough is produced from real software

Producing a credible walkthrough means operating the application rather than describing it. That requires a working environment, a demo user, and access to the code or a source archive so behaviour can be traced back to its implementation.

Drive the live application as a new user would

Start at the login screen and follow what a real user does, including the awkward paths: a rejected form, a duplicate submission, a timeout, a correction made after posting. A new user meets the system through those moments, and so should the recording.

Read the repository and trace the workflow through it

While recording, trace each step into the codebase so the successor sees the screen and the module that produces it. If your repository is large and largely unfamiliar, the method in this guide to turning a sprawling repository into a codebase walkthrough video pairs well with application-level recording.

Narrate the path and record the outcome

Narration should state the intent, the rule and the observed result: "I expect this order to bypass approval because the customer is on terms; the system approves it automatically; here is the table that records the approval." That structure makes the recording reviewable by people who were not present.

Log the defects the walkthrough exposes on a reviewable branch

Walkthroughs expose defects: a validation message that misleads, an error path that leaves orphaned records. Log each one with reproduction steps, and where a fix is straightforward, prepare it on a separate branch the owner reviews. The owner keeps control; the evidence stays attached.

What separates a walkthrough from a screen recording

Aspect	Screen recording	Legacy application video walkthrough
Narration	Whatever the presenter says	Business rules stated and demonstrated
Code link	None	Workflow traced into the repository
Defects	Usually unrecorded	Logged with reproduction steps
Reusability	Hard to index	Indexed, dated, replayable
Baseline for testing	Not suitable	Directly comparable after migration

Recordings age; code changes. A recording that names the module, the route and the configuration it exercised remains useful long after the video is stale, because a successor can check whether that code still behaves as shown. Without the code link, the video is an anecdote.

Pair your legacy application video walkthrough with regression evidence

A walkthrough describes current-state behaviour. Testing makes that description falsifiable, which is what a modernisation decision actually needs.

Establish a baseline before anyone changes anything

Run the in-scope workflows against a known state and record the outcomes: what is created, what is rejected, what is emailed. That baseline is the reference against which a rewrite, a migration or a vendor replacement is judged.

Show which workflows break, and where

When the baseline is replayed, failures should be shown precisely: the screen, the input, the expected and actual result. Vague statements that "the new system does not match" waste weeks of triage.

Keep the evidence attached to a branch your team can review

Findings, reproduction steps and any proposed fixes should sit together on a branch or in a linked repository. Reviewers can then accept, reject or defer with the evidence in front of them, rather than chasing it across inboxes.

Evidence formats a consultant can hand over

• Indexed recordings of each workflow, dated and labelled by user role.
• A findings list with reproduction steps and severity.
• A traceability note linking each workflow to code locations.
• A regression baseline and the results of replaying it.

What to ask for in a legacy application video walkthrough assessment

Commissioning the work is straightforward if the brief is specific about scope, outputs and access. Vague briefs produce vague recordings.

Scope: which workflows and which users

Name the five to fifteen workflows that carry the most business risk, and the roles that perform them. Everything else can wait; breadth without depth will not survive a handover.

Deliverables: recordings, findings, reproduction steps

Ask for indexed recordings, a written findings list, and reproduction steps for each defect. Require the link between workflow and code location in the deliverable, not as a favour.

Access: demo user, repository or a source archive

Provide a non-production environment with a demo user, plus access to a repository or a source archive. Where the application cannot be run, the walkthrough becomes a code-only exercise and should be described honestly as such.

Limits: evidence, not certification

No walkthrough proves an application is free of defects, and none is a substitute for security testing or performance testing. Guidance from bodies such as BSI and NIST covers the security and risk disciplines that sit alongside this work; a walkthrough supplies behavioural evidence, not assurance.^[2][3] Write down the workflows, the roles, the environment, the deliverables and the exclusions. State plainly that the output is current-state evidence and regression comparison, and that it does not certify the software. That single paragraph prevents most disappointment later.

From legacy application video walkthrough to modernisation plan

The recordings and regression evidence are not an end in themselves. Their value appears when they are used to decide, brief and verify.

Use the walkthrough to price the rewrite or replace decision

Once workflows are mapped, the estimation conversation becomes concrete: this many documented workflows, these undocumented business rules, this much regression surface. That is a better basis than an architect's memory.

Brief new developers and outsourced teams from the recordings

A new developer or an offshore team can watch the walkthrough before touching the code. Onboarding time drops, and questions become specific rather than introductory.

Re-run the regression evidence after each migration step

Each increment of a migration should replay the baseline and compare. Differences are either defects or intentional changes, and both should be recorded deliberately.

Where Vidabug fits. Vidabug films narrated walkthroughs of real software, tests applications the way a new user meets them, and repairs defects it can prove on separate branches the owner reviews, recording the evidence. It works from a live site with a demo user, or from a GitHub, GitLab, Bitbucket or Azure DevOps repository, or a ZIP of the source. It does not certify software as bug-free and is neither a penetration test nor a load test. For this reader, it produces the current-state walkthrough and regression evidence described above, in a form a CIO, an engineer and a consultant can all use.

Conclusion: start your legacy application video walkthrough this quarter

Begin before the retirement date is close enough to feel real. Scope the riskiest workflows, record them with the rules narrated, link each one to its code, and keep the regression baseline beside it. The result is a dated, testable account of how the system behaves today, which is the most useful thing an organisation can hand to whoever comes next.

^[1] The 2026 State of Legacy Software Modernization Report, saritasa.com.

^[2] BSI – Federal Office for Information Security, bsi.bund.de.

^[3] National Institute of Standards and Technology, nist.gov.