老系统接盘前自查清单

代码是否可以正常在本地运行起来？

如果连跑起来都费劲，说明环境依赖混乱，风险极高。

核心业务逻辑是否能看懂？（随机打开 5 个关键文件）

完全看不懂的代码，意味着改动任何地方都可能产生未知副作用。

是否有单元测试或集成测试？

没有测试的代码，每次修改都是在碰运气。

使用的框架/语言是否仍有社区支持？

停止维护的框架意味着安全漏洞无法修补、新人招聘困难。

是否存在大量硬编码（IP、密钥、业务参数写死在代码里）？

硬编码越多，后期修改越痛苦。

数据库有没有完整的结构文档（字段说明）？

没有文档的数据库，在不了解业务含义的情况下轻易改动极易造成数据错误。

是否有定期数据备份机制？备份是否真实可用？

询问上次从备份恢复的记录，如果没有，备份机制形同虚设。

数据库表是否有大量冗余字段或废弃表？

杂乱的数据库结构说明历史改动随意，可能存在数据一致性问题。

核心业务数据量级大概多少？（条数/表大小）

超大数据量的迁移改造成本会成倍增加，要提前评估。

服务器/云资源的账号密码是否可以完整交接？

如果交接不了，意味着你拿到的只是代码，不是整个系统。

是否有完整的部署文档或运维手册？

没有文档意味着你需要花大量时间反向工程整个运行环境。

系统依赖哪些第三方服务？这些服务的账号和 API Key 是否可以转移？

短信、支付、地图等第三方服务如果账号无法交接，相关功能就会中断。

当前系统是否在正常运行（还是已经挂了）？

已经挂了的系统接盘成本更高，因为还有恢复服务这一步。

是否有需求文档或原型图（哪怕是不完整的）？

完全没有文档，意味着你需要靠猜测来理解每个功能的业务含义。

是否有 bug 记录或已知问题清单？

了解现有 bug 情况，有助于判断系统稳定性和改造优先级。

原开发团队是否愿意提供 1–3 次的交接说明？

哪怕只有 1 次 2 小时的口头说明，也能节省大量摸索时间。

业务方是否清楚"接盘后先做什么、不做什么"？

如果业务方期望接盘后立刻加大量新功能，风险会很高。

是否有合理的改造预算和时间预期？

要求"1 个月内完成改造、预算 5 万"的项目，接下来大概率是灾难。