4. 业务系统调研与迁移范围界定
迁移项目失败最常见的原因，不是云上技术选型错误，而是范围没界定清楚：把不该动的系统卷进来，或者漏掉了某个被隐式依赖的数据库。本节要解决的就是"迁什么、先迁谁、谁和谁绑在一起"这三个问题。核心产出有三样：干系人访谈记录、应用—基础设施—数据依赖图谱、迁移批次划分与优先级矩阵。
一、访谈谁、问什么
访谈对象分两类。业务干系人关注的是业务连续性、停机窗口、合规要求和业务高峰；IT干系人关注的是技术栈、接口、数据量、许可证和运维约束。访谈不是漫谈，要围绕可落地的字段展开。
对业务方，建议固定问这几项：系统支撑的业务流程名称、月活用户量、业务高峰时段（例如每月1—5日结算）、可接受的最长停机时间（RTO）、可接受的数据丢失量（RPO）、是否有监管审计要求。对IT方，问：应用部署形态（物理机/虚拟机/容器）、中间件与版本、数据库类型与版本、数据量、对外接口清单、上下游调用关系、是否有硬编码IP、是否有本地文件依赖。
访谈中一个高频陷阱是"影子依赖"。业务方说"这个系统只连自己的库"，但实际通过定时任务读取了另一个系统的中间表。因此访谈必须配合技术验证：抓取应用服务器的出站连接、扫描配置文件中的连接串、检查crontab与调度平台任务。访谈给假设，技术扫描给证据，两者交叉才能定稿。
二、绘制应用—基础设施—数据依赖图谱
依赖图谱用三层表示：应用层（业务系统与接口）、基础设施层（主机、中间件、网络域）、数据层（数据库、对象存储、文件共享）。绘制规则是：应用调用应用画实线箭头，应用读写数据画虚线箭头，部署关系用包含框表示。
下面这张图是一个典型的三层依赖示例，包含一个核心ERP、一个外围报表系统和一个共享文件服务，用于说明"看似独立的系统其实共享数据层"这一常见情况。
从图中可以读出关键结论：报表分析系统虽然业务上"独立"，但它通过ETL读取ERP主库、通过NFS读取对账文件，因此它与核心ERP、对账服务构成一个强耦合簇。如果只迁ERP不迁报表，报表会在切换后立即失效。这就是依赖图谱的价值——把"业务上独立"和"技术上独立"区分开。
三、迁移批次划分
批次划分遵循三条原则：强耦合同批、低风险先行、关键系统留足回退窗口。具体做法是先在依赖图谱上做连通分量分析，把互相依赖的系统聚成一个迁移单元，再按风险打分排序。
风险打分建议用四个维度加权：业务影响面（1—5分）、技术复杂度（1—5分）、数据量（1—5分）、依赖数量（1—5分）。总分越高越靠后。例如核心ERP：影响面5、复杂度4、数据量5、依赖数4，合计18分，属于最后一批；一个内部培训系统：影响面1、复杂度2、数据量1、依赖数1，合计5分，可作为第一批试点。
四、优先级矩阵
把系统按"业务价值"和"迁移难度"两个轴放入四象限，形成优先级矩阵：
| 象限 | 特征 | 策略 | 示例 |
|---|---|---|---|
| 高价值 / 低难度 | 收益快、阻力小 | 优先迁移，作为标杆 | 内部OA、培训系统 |
| 高价值 / 高难度 | 核心系统、耦合重 | 重点规划，最后批次 | 核心ERP、结算系统 |
| 低价值 / 低难度 | 可顺手处理 | 随批迁移或直接下线 | 老旧报表、临时工具 |
| 低价值 / 高难度 | 投入产出比差 | 评估重构或淘汰 | 无人维护的遗留系统 |
五、可交付的范围界定表
访谈与图谱的最终落点是范围界定表。建议字段如下，每个系统一行：
系统名称 | 业务负责人 | IT负责人 | 部署形态 | 数据库及版本 | 数据量
对外接口数 | 上下游依赖 | 业务高峰 | RTO | RPO | 风险总分 | 迁移批次 | 迁移方式
填写时有两个判断依据要写清楚：一是"迁移方式"（重新托管/重构/替换/退役），二是"批次理由"。例如某系统被列为第3批，理由应写明"依赖ERP主库，须待ERP迁移完成后切换"。这样后续排期和资源分配才有据可依。
完成本节后，你应当能够独立组织一轮干系人访谈、画出至少三层依赖图谱、用风险打分把系统排进批次，并输出一份可评审的范围界定表。这份表将直接作为后续迁移方案设计和切换演练的输入。