Ask a language model to explain a twenty-year-old ColdFusion application and it will oblige. It reads the templates, writes a confident architecture summary, and drafts a modernization plan in minutes. The problem is not that the output is useless. The problem is that it is plausible, and on old code nobody fully understands, plausible is not the same as true.
So can AI help modernize a legacy ColdFusion application? Yes, with one condition: every claim the model makes gets checked against evidence from the running system before anyone acts on it. We have built and maintained ColdFusion systems since 1998, and we shipped a production ColdFusion 2025 migration in mid-2026 (the lessons are in our CF2025 migration field checklist). The model's default mode is optimism, and optimism is fatal on code nobody fully understands.
Why AI summaries of old ColdFusion code go wrong
AI summaries go wrong because the model fills gaps with what is typical, and old code is rarely typical. On July 16, 2026, martinfowler.com published Nik Malykhin's The Archaeologist's Copilot, a candid account of that failure on a Java 1.5 codebase. He started the usual way and asked the model for a senior developer's summary of the repo. It suggested the wrong major version of a core dependency and assumed a standard Maven layout the project never used. Its tidy picture also hid what he found later: the "unit tests" were integration tests, and the core implementation was not thread safe. He calls the pattern the hallucination of competence. His fix was to stop asking for a tour and demand a forensic audit that cites specific lines as evidence.
Three things make that failure worse on CFML.
The model has seen less CFML. Java is among the best-represented languages in training data. CFML is not, and the model's confidence does not drop to match. Expect fluent CFScript that mixes dialect eras, or a function signature from a version your server never ran.
Half the system is not in the repository. Datasources, mappings, and scheduled tasks live in the ColdFusion Administrator. Stored procedures live in the database. Server settings changed years ago never reached version control. A model reading the repo sees a fraction of the system and cannot tell you which fraction.
Nobody is left to catch the miss. The developer who knew why the 2009 custom tag exists left years ago. On a quiet ColdFusion application, the model's summary can become the documentation, wrong or not, and every plan after it inherits the error.
What counts as evidence on a ColdFusion application?
Evidence is anything that comes from the running system rather than from reading source: logs, configuration exports, and test results. The model proposes. The evidence decides.
Runtime truth over source reading. Web server and application logs show which templates execute, how often, and from which callers. Dead-code candidates come from months of access logs, never from the model's opinion. We have watched a "clearly dead" admin module turn out to be one department's quarter-end process.
Configuration exports over assumptions. Treat the Administrator settings as source. On ColdFusion 2021 and later, Adobe's CFSetup configuration tool exports datasources, scheduled tasks, and mappings to JSON. On ColdFusion 2018 and earlier, capture them by hand. Test every datasource. Give every scheduled task an owner and a reason, or flag it.
Behavior baselines before any change. Characterization tests record what the system does today, bugs included, so any change in behavior fails a test. They turn "the model says this refactor is equivalent" into a claim a test suite can reject. Our write-up on writing characterization tests first when there are no tests to inherit covers how we build them.
Contain the application before you improve it
Containment means the application runs, verifiably, in a reproducible environment on the versions it uses today, before anyone changes it. Malykhin refused to fix bugs, update dependencies, or even reformat whitespace until he got there. Most modernization efforts skip this step.
For ColdFusion, that means standing the application up on its current versions, in an environment you can rebuild from scratch, with the baseline tests green. Clients sometimes push back because it looks like paying to stand still. It is also the step that turns every later change from a leap into a diff. In our migrations, containment is a scheduled phase with its own exit criteria, not a hope.
Where AI pays in ColdFusion modernization
Constrained by evidence, AI is the best tool this work has had. It builds the inventory faster than any team: every template, every include chain, every query that touches a given table. It does translation work such as dialect upgrades and tag-to-script conversion, with the characterization tests as referee. It drafts the risk ranking that a senior engineer then checks against the logs.
It does not decide. What to migrate, what to rewrite, and what to leave alone rests on evidence plus human judgment. The wrong question is "can the model understand our code?" It will produce something that looks like understanding either way. The right question is what evidence you will require before you act on what it says. If you are weighing a migration and want that evidence pass before the plan, our ColdFusion migration work starts there. AI that ships, not AI that demos.