Modernization note

Why "just point Claude Code at it" is not a rescue plan

A growing idea in legacy modernization is that an AI coding tool can be pointed at an old system and produce a clean replacement. For leadership teams, that sounds efficient, low-risk, and fast. In practice, it is usually a misunderstanding of where the real value and difficulty sit.

The hard part is rarely turning one programming language into another. The hard part is finding the business logic, the edge cases, the operator shortcuts, the approvals, the data assumptions, and the hidden dependencies that the old system has accumulated over years of real use.

Why the idea sounds plausible

If a legacy system contains code in a recognizable language such as VBA or classic Visual Basic, it is reasonable to think that modern tooling could translate it into something newer. At a narrow level, that can happen. A procedure can be rewritten. A report query can be restated. A screen event handler can be converted into another language.

That is the part people can see. It is not the part that usually makes the project fail.

What the tool can help with

Tools like Claude Code can be useful for reading code, explaining routines, spotting repetition, drafting migrations, comparing patterns, and accelerating documentation. They can help a team move faster once the system is understood well enough.

That is different from saying the tool understands the business well enough to replace the system safely.

Why simple translation is not enough

A legacy system is usually not just code. It is a working arrangement between software, people, data, timing, and process. Even where code exists, it is only one expression of the business rules.

The code may be incomplete as a specification: the real behavior may depend on forms, reports, saved queries, configuration, user permissions, or the order in which staff perform steps.
The system may rely on hidden assumptions: file locations, old drivers, spreadsheet formats, printer layouts, shared folders, or manual checks done by experienced staff.
The most important rules may not be named clearly: developers and users often added special cases over time without creating formal documentation.
The language can be translated while the behavior is still lost: a technically correct rewrite can still break the business if it misses timing, sequencing, validation, or exception handling.

Example: VBA

VBA is a good example because it is a real programming language and can often be read and translated. But a VBA-heavy solution usually depends on more than the code modules alone. The real behavior may also live in workbook structure, form controls, hidden worksheets, named ranges, Access forms, report layouts, event bindings, and the way users prepare and review inputs.

If you only translate the VBA procedures, you may preserve the syntax while losing the operating model.

Example: Visual Basic

Classic Visual Basic applications can also look deceptively straightforward. There is source code, forms, and event handlers. That makes the rewrite problem look like a language conversion exercise.

In practice, the business behavior often depends on the interaction between forms, shared modules, database queries, report components, configuration files, and a set of local conventions that nobody wrote down because the system had already become "just how things work." Translating the code does not automatically recover those conventions.

What leadership should assume instead

The safer assumption is this: AI can accelerate parts of rescue and modernization, but it does not remove the need for discovery, validation, and business-rule extraction. A legacy rescue still needs people to determine what the system actually does, what must be preserved, what can be retired, and where the real risk sits.

That work is especially important in companies where the original builders have left, where IT capacity is limited, or where the software supports exceptions that the main platforms never handled properly.

What a serious rescue approach looks like

Inventory the artifacts: code, forms, reports, queries, tables, macros, jobs, exports, and integrations.
Identify the business-critical flows: what the organization cannot afford to get wrong.
Capture exceptions and operator knowledge: the cases the old system handles that nobody remembers until they break.
Use AI as an accelerator, not as the source of truth: helpful for analysis and drafting, but not a substitute for understanding.
Validate against real operations: the replacement has to preserve outcomes, not just resemble the old code.

The practical conclusion

The question is not whether Claude Code or similar tools are useful. They are. The question is whether they remove the need to understand the business logic embedded in the old system. They do not.

If the organization treats a legacy rewrite as a translation exercise, it risks preserving the visible software while losing the working knowledge that made the business function. That is why legacy rescue starts with extraction and understanding, not with blind conversion.