很多企业准备升级老系统时，都会碰到一个相似的难题：业务部门不断催促，技术团队却没人愿意率先行动。表面原因常被归结为代码陈旧、文档不全，但真正让人迟迟不敢下手的，往往是那些平时看不见的依赖关系。一个看似普通的登录入口，可能同时连接着三个内部系统；一张常规报表背后，可能挂着两条定时任务和一个外部数据接口。代码本身尚能读懂，依赖一旦断裂，却很难在短时间内补齐。因此迁移之前的第一件事并不是挑选新技术，而是把依赖关系梳理清楚。
依赖盘点可以从四个层面依次展开。数据层需要确认表结构、字段含义、导入导出通道，以及历史数据量究竟有多大，哪些数据必须随迁移带走，哪些只是过程记录。接口层要理清对内对外的调用关系，特别是那些缺少文档、只在运行过程中才暴露出来的定时任务和回调地址。账号与权限层最容易被忽略，登录方式、角色配置、单点登录关系，往往牵一发而动全身。运行环境层则涵盖服务器、域名、证书和第三方服务，其中任何一项到期或发生变更，都可能让迁移计划被迫中断。
盘点时建议用一张三列表格来记录：谁在使用、怎么使用、断开之后会怎样。每一行对应一个依赖项，并按影响范围标注关键程度。影响核心业务且短期内无法替代的，标为高；影响内部效率但可以临时绕过的，标为中；只影响个别查询或历史查看的，标为低。这张表不需要多精致，但必须真实，宁可写得琐碎，也不要凭印象概括。
迁移顺序的判断标准并不复杂：先替换可回退的部分，保留并行运行窗口，提前写明回滚条件。能单独切分出来、出问题又能快速切回去的模块优先处理；核心链路先并行运行一段时间，确认数据一致、业务无感知之后，再考虑下线旧入口。回滚条件要写得具体，比如数据比对出现差异、关键接口连续报错、用户反馈集中在某一功能，只要达到其中任意一条，就暂停推进。
盘点结果不能只留在个别人的记忆里。每一项依赖的负责人、当前状态、替代方案和验证方式，都应整理成书面资料，并随迁移进度同步更新。it数运在需求梳理和资料交付上的做法，是先确认依赖清单再讨论开发排期，把口头描述转化为可核对的文档，避免系统换完了，问题却还藏在某个人的聊天记录里。
先看清再动手，是老系统迁移最稳妥的起点。普通企业当天就能做的第一步，是找一张白纸，把“谁在用、怎么用、断开会怎样”这三列画出来，先填入最熟悉的五个依赖项，再逐个找人确认。清单不必一次做完，但必须开始做。
