BotMan AI's Knowledge-Graph Migration Pitch Is Short on Proof

BotMan AI says its migration pipeline maps an application's dependencies, business logic and data models into a knowledge graph for agents to use. SiliconANGLE reported that approach on October 12, 2026, but provided no migration-accuracy figures. ¹ For CIOs weighing AI legacy application migration, the key question is whether the graph helps produce a functionally equivalent replacement and reduces review effort.

SiliconANGLE describes a pipeline that represents application relationships in a knowledge graph. Founder and CTO Alejandro D’Andrea says the approach rebuilds application architecture rather than simply translating old code into a newer language. ¹

That is an architecture description, not an outcomes report. The article reports no accuracy figures, measured migration results, or comparison showing that graph context outperforms code translation on the same application. ¹ D’Andrea also says the system migrates applications “fully autonomously,” but the report does not provide results substantiating that claim. ¹ Buyers should treat the graph as a proposed way to organize context, then assess separately whether the migration is complete, behaviorally equivalent and ready for production.

What's actually new in this AI migration pitch

BotMan says its pipeline maps dependencies, business logic and data models into a knowledge graph that agents use during migration. The legacy technologies named in the report are Delphi, Visual Basic and Oracle Forms. ¹

D’Andrea describes the approach as rebuilding an application's architecture and relationships rather than simply translating its old code into a newer language. ¹ That is a different stated scope from code translation, but the report offers no comparative results showing that the approach works better. ¹ For a different example of how AI-assisted migration claims can be weighed, see what GitHub's AI-assisted Copilot runtime rewrite shows about code migration.

A graph could help organize context about code, data structures and business rules. That is a plausible benefit of the described architecture, not a reported benchmark. ¹

A better map is not necessarily a correct replacement. Evaluate the graph and the migrated application as separate deliverables: does the graph reflect the source system, and does the agent use it to preserve required behavior?

The case for knowledge graphs in code modernization, and its limits

D’Andrea describes knowledge graphs as a way for agents to reuse context and find related information, including links among documents, messages, people, projects and products. ¹ If that context is accurate and complete, it could help agents connect information that would otherwise require repeated discovery. That is a plausible benefit of the described architecture, not a reported benchmark. ¹

A graph can make relationships visible without establishing that they are correct. A documented dependency may miss an edge case in how a system is used; a business rule inferred from available material may be incomplete. The report does not explain how BotMan detects or resolves missing or conflicting relationships. ¹

Ask what evidence supports each important edge in the graph: source code, data, documentation or human review. Without that, the graph may offer a clearer representation without resolving uncertainty.

Graph context vs. code translation: what's claimed, what's shown

	BotMan's claim	Evidence in the report
Scope	Rebuilds application architecture rather than simply translating old code 1	D’Andrea's description; no comparative results 1
Autonomy	Says it migrates applications “fully autonomously” 1	No accuracy figures or migration results reported 1
Comparison to translation	Describes a different approach to legacy modernization 1	No head-to-head test reported 1

The practical question is whether the added context improves results enough to justify building and validating the graph. Buyers should define a baseline — such as code translation, manual redevelopment or another method already in use — before accepting an improvement claim. Compare approaches on the same application and under the same review standard.

What hasn't been demonstrated about autonomous AI migration agents

D’Andrea says BotMan ingests an application as a whole and migrates it “fully autonomously.” The report provides no migration-accuracy figures, completeness measurements or comparative test results. ¹

Buyers will also want to know whether a migrated application preserves required behavior, whether all relevant components and data are accounted for, and whether the output is ready for production. The report does not measure or establish those outcomes. ¹

The human-review burden is also unquantified. The report does not define the boundaries of the claimed autonomy or describe a review model. ¹ Buyers should ask whether autonomy covers analysis, code generation, data transformation and deployment, and which steps require sign-off. Agents that run without supervision also need their own testing; see When Agents Run Unattended: Testing for Retries That Cost Money and Outputs That Vary.

Where the risk hides in legacy system dependencies

Undocumented behavior is a concern to test for: information absent from the materials available to a migration process may not be reflected in its representation of the system. The report does not explain how BotMan handles that possibility. ¹ It also does not describe how the pipeline deals with missing or conflicting relationships, measures confidence or routes uncertainty to a person. ¹

Human review belongs in the migration design from the start. Teams should decide who validates the generated architecture, business rules and migrated data; which outputs require sign-off; and how unresolved exceptions are escalated. The report does not describe those procedures. ¹ A pilot should reveal uncertainty and failure cases rather than treating incomplete source material as settled fact.

What to demand before a pilot

Build an evaluation set that reflects your application patterns, including any relevant use of the legacy technologies named in the report: Delphi, Visual Basic and Oracle Forms. ¹ A pilot on one system can show how the approach performs on that system; broader claims require broader evidence.

Set acceptance criteria before the pilot starts. Consider functional equivalence, migration completeness, data integrity, production readiness and human-review effort. These outcomes are not reported in SiliconANGLE's article. ¹

Ask for traceability: a visible chain from source evidence to graph relationship, generated design, migrated code and test result. That would let reviewers assess whether a migration decision follows the available evidence or an incomplete representation. The broader question of how much evidence is enough before an agent acts is covered in AI Agent Governance: What Evidence Is Enough Before an Agent Can Take Action?

Agree on failure handling up front. Ask how the system surfaces missing documentation, conflicting relationships or dependencies it cannot resolve. Compare results against a defined alternative on the same application and under the same review standard; the report provides no such comparison. ¹

What would actually convince a skeptic

Useful evidence would include results across multiple legacy languages, application sizes and architectures; disclosed accuracy, completeness and data-validation figures; and an account of the human review required. SiliconANGLE's article provides none of those measurements. ¹

Failure cases would also help buyers understand where undocumented behavior or inaccurate graph relationships affect a migration. The report does not provide such cases. ¹

For now, the fair reading is that BotMan has described a context-rich migration architecture, not demonstrated that it reduces modernization risk. ¹ Buyers can pressure-test the graph's accuracy, check whether the migrated system behaves like the original, and measure how much review remains necessary.