AI如何帮助老项目如何迁移
| 步骤 | AWS | 微软等云厂商 | 开源 |
|---|---|---|---|
| 1 评估 | Transform 发现与波次规划 | Azure Migrate、Moderne DevCenter | Joern、CodeBoarding、tbls |
| 2 逆向文档 | Transform 代码库分析 | Google Code Wiki | deepwiki-open |
| 3 抽业务规则 | Transform Reimagine | Moderne（确定性） | 空白 |
| 4 建本体 | AWS Context（托管） | Fabric IQ Ontology | COA（自建）、OpenBKN、Semantica |
| 5 治理 Action | AWS Context | Fabric IQ Rules + Activator | operational-ontology |
| （横切）确定性改造 | Transform 自定义 | Moderne / OpenRewrite | OpenRewrite |
第 1 步：评估
评估要回答四个问题：代码规模与技术债存量、系统间依赖关系、修改的影响范围、改造优先级。
AWS：Transform 的发现与波次规划（wave planning）在三条供给线中最完整，支持 what-if 场景模拟和 TCO 对比，产出可直接用于预算评审。其差异点不在分析能力本身，而在将优先级决策转化为可评审的量化依据。
微软：Azure Migrate 覆盖基础设施侧评估；代码侧由 Moderne 的 DevCenter 完成全量盘点。Choice Hotels 使用该平台对 4800 个仓库做了一次性盘点，检视 691 个 codebase，其中 526 个进入升级队列。
开源：Joern 生成依赖图与调用关系——将 AST、控制流图、程序依赖图合并为一张 Code Property Graph，支持十余种语言；CodeBoarding 生成分层架构图；tbls、Azimutt 生成数据库文档。技术债扫描在开源侧最成熟，缺口在于缺少基于业务影响的优先级排序。
输入输出对照
| 方案 | 输入 | 输出 |
|---|---|---|
| AWS Transform | 非规范化的发现数据：RVTools 导出、不完整的 CMDB 记录、数年前手工维护的表格（官方明确说明不要求先完成规范的 discovery）；大型机场景为 COBOL/PL/I 源码、JCL、copybook | 资产清单与依赖关系、波次规划、what-if 场景（多条迁移路径 + TCO 对比 + Cloud Value Framework）、大型机业务功能映射与优先级排序方案 |
| Azure Migrate | 本地部署的轻量 appliance VM，无代理方式连接 vCenter/Hyper-V host（物理服务器走 WinRM/SSH）；一个只读 vCenter 账号；性能数据建议采集 1 天至 1 个月（30 天数据最完整） | 服务器清单（OS/核数/内存/磁盘）、就绪性分级（Ready / Conditionally ready / Not ready）、right-sizing 建议（基于性能的方法比 as-is 匹配通常降低 30–50% 成本）、成本估算（PAYG vs RI vs Hybrid Benefit）、依赖关系可视化，可导出 Excel |
| Moderne DevCenter | Git 仓库（批量 ingest，每个仓库解析为预构建 LST——类型归因、依赖、格式信息均保留） | Data tables（依赖、CVE、许可证、版本号、API 使用）、可视化报表（语言构成、OWASP top 10、COBOL 关系图）、DevCenter 仪表盘（upgrade cards 逐 repo 跟踪目标版本迁移状态、security cards 可直接运行修复 recipe 并跟踪 PR）、跨全部仓库的影响分析（分钟级） |
| 开源组合 | Joern：源码目录 CodeBoarding：repo + LLM API key tbls：DSN 连接实际数据库（注意 .tbls.yml 中凭据为明文） Azimutt：数据库连接或 SQL dump |
Joern：CPG（可导出 GraphML/JSON/DOT/SARIF）+ CPGQL 查询（调用图、切片、污点分析） CodeBoarding：.codeboarding/ 目录中的分层 Mermaid 图 + 组件级 Markdown tbls：Markdown/HTML 文档 + ER 图 + lint + schema diff Azimutt：交互式 ER 图与关系追踪 |
这张表有一个值得注意的结论：三条供给线的输入覆盖不同层面，实际是互补关系而非竞争关系。 Transform 消化基础设施数据与大型机代码，Azure Migrate 读取 hypervisor，Moderne 读取 Git 仓库，开源组合读取源码与数据库。Azure Migrate 不分析代码，Moderne 不感知基础设施。企业实际操作中往往需要组合使用。
第 2 步：逆向生成文档
将系统现状写成可交接的文档。这是老项目的典型痛点：原开发者离职后，系统知识随之流失。
AWS：Transform 的 comprehensive codebase analysis 产出四类结果——组件依赖关系、行为模式、架构决策、白话描述的业务逻辑。技术路线为确定性静态分析 + LLM + 图神经网络，中型代码库耗时 45 分钟至 2 小时。
Google：Code Wiki 对公开仓库免费，覆盖度与更新频率尚可；私有代码的 Gemini CLI 扩展仍在 waitlist。
开源：deepwiki-open（MIT，约 18k star）输入仓库地址即可生成 wiki、架构图与问答界面，支持本地 Ollama，代码不出内网。三点差异需要明确：其目标是”辅助阅读”而非”支撑改造决策”；纯 LLM 生成导致两次运行输出不一致；产物为面向人的页面，不是可供下游工具消费的机器可读输入。
如有审计要求，确定性问题从这一步就必须处理——不可复现的架构文档在变更评审中不具备证据效力。
第 3 步：提取业务规则
将分散在代码分支中的业务判断提取为”条件 → 结果”规则，每条附带验收标准，供编码工具消费。
这一步是整条链路的分水岭。 它同时决定两件事：改造是否改对了语义，以及让 agent 执行改造时依据什么。
AWS：Transform Reimagine 提取业务规则时附带验收标准，每条规则可追溯至源码位置，再通过 MCP 流入 Kiro 或 Claude Code。这是目前唯一将”理解”与”改造”衔接为一条流水线的产品。
微软系：Moderne 采用不同技术路线。它不依赖 LLM 推断，而是将代码解析为 Lossless Semantic Tree——编译器精度、类型已归因、保留原格式——再用一万多条确定性 recipe 执行变换。2026 年 Gartner 的 AI 增强代码现代化魔力象限（Magic Quadrant for AI-Augmented Code Modernization Tools）将 Moderne 列为 Leader，与两家超大规模云厂商同列（据其官方博客）；报告评价指出其”基于确定性流程的业务逻辑与规则提取能力领先”。
适用范围需要明确：Moderne 覆盖的是升级，不是迁移。 语言范围包括 JVM 系、JS/TS、C#、Python 及构建配置；自研框架需要自行编写 recipe；COBOL/PL-I 大型机不在支持范围内，该领域仍由 AWS Transform 和专业厂商覆盖。
同时要清楚，确定性 recipe 覆盖的是升级中的 common case。Choice Hotels 的迁移记录了典型例外：PowerMock 和 EasyMock 需要人工迁移到 Mockito；依赖内部 Nexus 中已过期的私有库导致构建失败；构建在 Apache Tiles 上的应用需要整体重写。老项目升级的主要工程量，恰恰落在这类 recipe 覆盖不到的例外上——这与引言中”升级的真实困难”是同一件事。
开源：spec-kit 等项目解决的是正向流程（人写 spec → 生成代码），不是逆向提取。代码到规格这一段，开源基本空白。
第 4 步：构建本体
将对象、关系、规则、指标定义为机器可读的模型，使 agent 明确自己操作的业务实体及其约束。
AWS：Context 是托管服务；内核 COA（Apache-2.0）开源，采用 Scan → Model → Serve 三段架构，包含图存储、推理引擎、SHACL 校验、MCP 接口。限制：仓库为 read-only mirror，不接受 PR——上游更新需要自行同步，对要求跟随上游升级的团队，这一条可能是决定性风险。
微软：Fabric IQ Ontology（preview）是直接竞品：可从 Power BI 语义模型一键生成本体，表映射为实体类型、模型关系映射为关系类型、DAX 度量映射为指标；支持 RDF/OWL/Turtle 导入导出；提供 MCP endpoint 和 Private Link，权限继承自数据源。代价是绑定 OneLake，且规则仅为供阅读的文本，本体不执行规则，也不对数据执行动作。
开源：OpenBKN、Semantica。更稳妥的做法是只使用底层组件——Ontop 做虚拟知识图谱（OBDA）、HermiT/ELK 做 OWL 推理、pySHACL 做约束校验、Cube 或 MetricFlow 做指标语义层。
一个共同前提：本体建模不可外包。这项工作的本质是将业务认知结构化，工具只承担最后的编码。
第 5 步：治理 Action
让 agent 具备修改业务数据的能力，而不只是回答业务问题。
一个受治理的 Action 需同时满足六个条件：类型化契约、真实副作用、前置条件、幂等与补偿、授权、审计。任一条件缺失，系统就停留在问答系统层面，无法对业务执行写操作。
AWS：Context 的定位即”判定正确的动作”（determine correct actions），这是它与纯语义层的本质区别。
微软：Fabric IQ 提供 Rules，可配合 Activator 实现自动通知和动作——但如前所述，规则本身是文本，执行依赖外部触发器组合实现。
开源：operational-ontology 等最小参考实现可以演示完整形态——规则在 Action 内检查、违反时返回机器可读拒绝码、审计留痕、write-back——但与生产环境要求相差一个量级。范式已被复刻，工程厚度没有。
整合方案：三种组合
全 AWS：Transform + Context。理解与改造衔接最顺畅，代价是两层架构异构（一层闭源托管、一层开源自建）、成本高、厂商绑定深。
全微软：Azure Migrate + Moderne + Fabric IQ Ontology。升级路径最稳（确定性 recipe），本体使用成本最低，但规则不可执行、本体处于 preview、数据须进入 OneLake。
全开源：OpenRewrite + deepwiki-open + COA + 自建 Action。可控性最高、无厂商锁定，代价是第 3 步和第 5 步需自行补齐，工程量大。