服务迁移前：列出数据库、文件和外部依赖迁移准备常从应用部署清单开始，但真正造成切换失败的，往往是没有被列出的状态、连接或人工步骤。数据库可能有多个写入入口，文件可能散落在本地盘和对象存储，外部系统则依赖固定回调地址或出口白名单。迁移前建立带责任人的依赖清单，可以把这些隐性条件变成可验证任务。🔍
记录数据库类型、版本、字符集、时区、扩展、账号角色、连接池配置、备份方式和恢复目标。把应用服务、后台管理、定时脚本、消息消费者、Webhook、批处理和人工运维操作都列为潜在写入方。不能只记录主数据库地址；还要找出连接它的任务、只读副本、缓存和异步队列。
写入入口清单应包含入口名称、调用来源、写入表或对象、运行时段、负责人、停写方式和切换后的检查方法。若旧环境与新环境会同时接收写入，应明确哪一端是权威数据源，以及如何避免双写分叉。验证从备份恢复后，关键约束、索引和权限也能正确工作。
例如 writer=nightly_import、运行窗口、账号权限、目标表、暂停命令和最后成功时间。清单中只记录凭据的安全存放位置与责任人，不粘贴密码、令牌或连接串。
查找用户上传文件、静态资源、导出结果、临时任务产物、日志和备份分别存放在哪里。记录总量、每日增长、访问权限、生命周期、加密方式、域名和应用读写路径。应用可能把临时目录当作任务队列或缓存，需确认其内容能否重建，以及迁移期间是否仍会增加。
目标端验证不应只检查文件是否存在。还要用应用实际读取路径访问样本，检查中文文件名、权限、元数据、下载域名和内容类型。若文件在迁移期间继续变化，安排增量同步或明确冻结窗口。
盘点支付、短信、邮件、身份认证、Webhook、代码托管和数据分析等外部依赖。记录请求方向、域名、端口、超时、失败处理、回调地址、访问白名单、证书要求和业务联系人。检查DNS记录、TLS证书、出口地址及防火墙规则是否需要调整，确认第三方是否需要提前登记新地址。
区分“迁移时要调用”的依赖和“迁移后会回调本系统”的依赖。回调端若仍指向旧站点，用户请求可能正常但异步状态无法更新。不要把密钥原文复制到普通表格；只标注密钥管理位置、轮换步骤、执行人和生效验证方式。
常见遗漏：DNS和网页已切换，但第三方Webhook、邮件回跳地址或固定出口白名单仍指向旧环境。
根据数据规模和可接受停写时间，选择全量复制、增量同步或维护窗口内暂停写入。先在非关键环境演练，记录传输速度、失败重试和校验时间。计划应明确数据冻结点、最终增量同步、DNS或流量变更、写入入口恢复和监控观察顺序。
准备配置差异表，列出新旧环境的数据库地址、存储域名、网络路由、外部回调、时区、证书和权限差异。若需要反向同步，说明如何处理迁移后已经产生的新数据；如果没有可靠反向同步，就在方案中明确回滚时的业务影响和决策时限。
准备代表性账号和数据，分别验证登录、查询、写入、文件上传与下载、异步任务、第三方回调和定时作业。确认日志、监控、备份、告警和权限已经接入目标环境。验收记录应包含输入条件、预期结果、实际证据、责任人和失败处理，不能只用首页能打开作为迁移完成标准。
每个依赖至少应有来源、目标、负责人、操作步骤、验证证据和回退限制。未知项要列为阻塞任务，明确何时由谁确认。可以先验证只读路径和非关键任务，再安排涉及写入的正式切换；每一步完成后保存数据与监控证据。
提醒：未确认的依赖不要留到切换后处理。尤其要说明写入入口、外部回调和回滚后的新数据如何处置。
一份有负责人、有证据、有顺序的清单，比宽泛的“数据库和附件已迁移”更有用。目标端启动后，立即检查备份任务、告警和定时作业是否持续运行，再据此确认迁移收尾。🧭
