上云迁移常见的遗漏，不是应用本身，而是它依赖的文件、服务账号、网络访问和定时任务。梳理时，先把企业上云前的应用依赖梳理清单做成可核对的台账，再判断每项依赖是迁移、替换还是保留。不要只看架构图：配置文件、部署脚本和运行日志里往往还藏着实际调用关系。
先定边界：记录应用与调用关系
以一个可独立部署、发布和回退的服务作为梳理单元。给每个应用记录负责人、用途、运行环境、数据归属、上下游系统，以及开发、测试、生产环境的差异。再画出调用方向，例如“Web 服务—订单服务—PostgreSQL”，标明是同步请求、消息传递、文件交换还是定时拉取。
同一系统可能有多个部署实例，但共享数据库或文件目录。清单要记录依赖对象及连接方式，而不只是应用名称；否则切换一个实例时，容易漏掉仍指向旧环境的调用方。
逐项核对六类依赖
| 类别 | 要检查什么 | 迁移时的判断 |
|---|---|---|
| 运行环境 | 操作系统版本、Java或.NET运行时、系统库、启动参数 | 确认云端镜像和运行时版本兼容；手工安装的组件要纳入部署流程。 |
| 数据与文件 | PostgreSQL、Redis、RabbitMQ、共享目录、上传文件和备份 | 区分需要迁移的数据与可重建数据，并核对读写方、保留周期和恢复方式。 |
| 网络与外部服务 | IP和端口、代理、邮件发送、SFTP交换、第三方接口 | 记录发起端、目标端及协议；确认新环境可访问，外部对方是否需要登记新出口地址。 |
| 身份与凭据 | 服务账号、证书、密钥、目录服务和授权范围 | 核实由谁保管、何时轮换、哪些服务使用；避免把凭据写入镜像或代码仓库。 |
| 作业与运维 | cron任务、消息消费者、监控告警、日志位置、备份和恢复步骤 | 确认任务是否会重复执行，告警是否仍能送达，值班人员能否按文档处置。 |
| 许可与交付 | 商业软件许可、字体或驱动、安装包来源、部署脚本 | 确认许可允许新的运行方式，并保留可重复部署所需的版本和校验信息。 |
把清单变成可执行检查
- 收集证据：查看配置文件、环境变量、systemd服务定义、容器镜像构建文件、定时任务和近期运行日志。日志只能辅助发现调用，不能替代负责人确认。
- 逐项登记：为每项依赖写明名称、用途、调用方、目标地址或目录、环境差异、负责人、敏感级别及验证方式。未知项标成待确认，不要猜测。
- 分类处置：标注“原样迁移”“云上替换”“暂时保留”或“下线”。例如，依赖固定本地路径的文件服务，可能需要改为共享存储；是否适合替换，取决于访问模式和应用改造成本。
- 验证闭环：在目标环境逐条测试连接、读写、权限、证书、作业触发和恢复流程。记录结果与证据；对计划停机的系统，另行演练数据同步、切换和回退。
用风险决定迁移顺序
优先处理“影响面大、替代困难、验证耗时”的依赖，例如多个应用共用的数据服务、外部系统接口和无人维护的定时任务。单机配置或可重新生成的缓存通常更容易处理，但仍要确认缓存重建会不会拖慢启动或影响服务。企业上云前的应用依赖梳理清单还应注明责任人和验证状态，按变更持续更新，而不是在迁移前一次性填完就归档。
常见问题
只看源代码够不够？
不够。部署参数、服务器上的手工配置、定时任务和外部白名单可能不在代码仓库中，应结合配置、运行环境和负责人访谈核对。
依赖信息不完整怎么办？
先标记未知项及确认人，再通过日志、网络连接记录和分环境测试补证；没有证据的项目不要直接当作无依赖。
哪些内容需要定期更新？
应用版本、调用对象、账号证书、网络规则和作业负责人发生变化时，都应更新清单，并在迁移验收前复核。
把每项依赖落实到对象、负责人、处置方式和验证结果，企业上云前的应用依赖梳理清单才能真正支持迁移排期、风险评估与回退决策。