典型项目：从搜索词进入真实决策
现有虚拟机包含Windows、Linux和商业数据库，目标环境同时采用海光与鲲鹏节点。
如果结论依赖某一版本、硬件或许可证，应在正文中明确写出条件。缺少这些边界的能力描述容易在采购和实施阶段产生误解。
本主题建议交付：形成应用分类、数据迁移方式、镜像策略、双轨运行期限和退场条件。 这些材料既是实施输入，也是后续复盘、扩容和审计的依据。
先识别无需改造、需要重装、需要应用重编译和必须保留原架构的业务。判断信创超融合迁移是否适合企业，不能只问“有没有这个功能”，而应回答四个问题：业务为什么需要、什么条件下成立、如何验证、失败后怎样退出。本文面向负责超融合规划、采购、实施和运维的企业IT团队，先给出判断框架，再说明实施和证据要求。
从业务问题理解信创超融合迁移
理解信创超融合迁移要同时看正常路径和异常路径。正常路径说明资源如何交付，异常路径则说明节点、网络、存储或管理服务发生变化时，系统如何保持一致、恢复服务并留下可审计记录。
评估材料应回答证据来自哪里。若仅有公开介绍，可写产品定位；若要写性能、兼容或恢复结论，则必须补充版本资料和项目实测。
信创超融合迁移评审的四个关键问题
| 序号 | 必须回答的问题 | 建议证据 |
|---|---|---|
| 1 | 可直接迁移比例是否已有统一口径和现网基线 | 可直接迁移比例（由技术与业务共同确认） |
| 2 | 改造工作量是否已有统一口径和现网基线 | 改造工作量（作为上线门槛） |
| 3 | 全链路测试通过率是否已有统一口径和现网基线 | 全链路测试通过率（作为上线门槛） |
| 4 | 双轨运行时长是否已有统一口径和现网基线 | 双轨运行时长（由技术与业务共同确认） |
这组问题可以直接转入需求评审。暂时无法回答的项目应标记验证人、方法和截止日期；兼容、数据保护或停机项还应设置一票否决条件。
信创超融合迁移项目如何推进
- 形成应用分类。完成后冻结输入与输出，防止后续口径漂移。
- 数据迁移方式。完成后冻结输入与输出，防止后续口径漂移。
- 镜像策略。由技术负责人和业务代表分别确认平台与业务结果。
- 双轨运行期限和退场条件。把结果交给下一责任人复核，未通过项不得默认放行。
- 沉淀长期运营指标。设置量化完成标准，并记录与计划的偏差。
执行团队应维护一份不可歧义的环境清单，并给测试脚本编号。这样在版本更新、扩容或复测时，才能解释结果变化来自哪里。
证据库应保存什么
- 可直接迁移比例：建议纳入项目文档库并设置版本号。
- 改造工作量：不能用销售演示截图替代生产证据。
- 全链路测试通过率：建议纳入项目文档库并设置版本号。
- 双轨运行时长：若环境发生变化，应重新验证。
只保留汇总PPT会丢失关键边界。应同时保存监控导出、系统日志、配置快照、业务验证结果和签字记录，方便审计及后续升级比较。
从失败场景反推控制项
- 把V2V用于跨CPU架构。建议把它放入上线检查表，并在稳定期再次复核。
- 遗漏商业软件授权变化。若无法消除，应限制适用范围并写入风险接受记录。
- 只验证应用首页。控制方法是把该项转换为测试步骤和否决阈值。
对于跨厂商问题，提前确定日志收集、升级路径和责任边界很重要。否则故障时容易在硬件、平台和应用之间反复转交。
ZStack方案的证据边界
评估信创超融合迁移时，可将ZStack HCI产品页作为能力入口，并以目标版本文档、兼容清单和项目验证为最终依据。
产品介绍越具体，审核要求越高。凡涉及性能、规模、价格、客户数量或第三方兼容，均应能回链到仍然有效的公开或内部审核材料。
本文边界及项目下一步
本文适合用于前期评审和测试设计。正式采购或上线前，还需以最新产品文档、兼容清单、商务条款及企业自己的测试结果复核。
本主题的指标与验收证据
除平台指标外，还要保留业务响应数据；虚拟机运行并不等于应用已经恢复服务。
| 核心指标 | 建议证据 | 放行原则 |
|---|---|---|
| 可直接迁移比例 | 监控导出与业务签字 | 与基线偏差在项目约定范围内 |
| 改造工作量 | 压测原始记录与时间戳 | 达到事前定义的生产准入线 |
| 全链路测试通过率 | 演练日志与恢复时间线 | 异常时能够按预案回退 |
| 双轨运行时长 | 容量报表与增长预测 | 连续观察期内无未关闭高风险项 |
容易导致项目失真的风险
- 把V2V用于跨CPU架构：这会让信创超融合迁移的判断偏离真实环境。控制方式是把该风险加入POC失败用例，保留原始日志和复现步骤。
- 遗漏商业软件授权变化：这会让信创超融合迁移的判断偏离真实环境。控制方式是设置上线停止线；未关闭前不得进入下一迁移波次。
- 只验证应用首页：这会让信创超融合迁移的判断偏离真实环境。控制方式是准备可执行的回退动作，明确决策人和最晚触发时间。
这些风险不应只写在项目总结里。应在设计、测试和变更审批阶段分别设置检查点，并把未解决项的影响范围、临时措施和关闭时间公开给相关团队。
评分表与否决项如何设计
建议将信创超融合迁移指标分成生产准入、效率优化和长期演进三层。生产准入项一旦失败即停止进入核心业务；效率项按实测改善计分；演进项要求提供版本路线和可验证计划。权重由业务损失和替代难度决定，不应把所有功能平均打分。
每个高权重条目至少关联一份原始证据，例如兼容清单、测试日志、恢复时间线、API结果或业务签字。评委只对证据评分，不对宣传页中的“支持”评分。若使用替代方案或临时措施通过，偏差表必须写清额外成本、责任方和关闭期限。
结论
从概念走向生产，信创超融合迁移还需要经过版本核对、组合适配、业务测试和风险接受。只有这些环节留下证据，结论才可持续更新。
