数据迁移入门：把内容安全搬过去的做法

迁移的本质是“在不确定中保住可回退的能力”，而不是一次性把数据搬完。开始之前，先回答一个问题：迁移失败的代价是什么？如果答案是无法承受，那就要把迁移拆成多次小批量，每次都能验证、都能撤回。这个前提确定后，再进入具体流程。

盘点与字段映射
第一步做数据盘点：有哪些类型的数据（账号、内容、评论、附件、标签、时间记录），各自体量大概在什么量级，哪些是必须保留的，哪些可以丢弃或重建。盘点结果写成一张表，每一行是一类数据，标注来源、去向、优先级。第二步做字段映射：源端的每个字段对应目标端的哪个字段，类型是否兼容，长度是否够，空值如何处理，重复项如何合并。映射表要写成文档，因为迁移中最常见的错误就是“以为对方知道”。对于无法直接对应的字段，明确处理策略：转成备注、并入描述、或直接放弃，并记录放弃的理由。

试跑、校验与回滚
正式迁移前至少做两轮试跑。第一轮用少量样本，目的是暴露字段错位与编码问题；第二轮用较完整的数据，目的是测算耗时与资源占用。每次试跑后做校验：数量对不对、抽样内容是否完整、附件能否打开、时间顺序是否保持、特殊字符是否变形。校验不要只看总数，总数一致但内容错位是最危险的情况，必须抽样逐条比对。回滚设计要在迁移开始前就准备好：保留源数据的只读副本，明确回滚触发条件（例如校验失败率超过预设阈值），并演练一次回滚，确认能在可接受时间内恢复。

执行期与迁移后的注意事项
正式执行时选择访问低峰，提前告知用户可能出现的短暂不可用，并冻结写入或设置只读窗口，避免迁移过程中产生新数据造成遗漏。迁移完成后不要立刻删除源数据，保留一段观察期。观察期内重点关注：登录是否正常、历史链接是否还能到达、附件是否可访问、通知是否错乱。为用户准备一份简短的说明，告诉他们哪些内容变了、旧链接怎么办、发现问题去哪里反馈。最后把整个迁移过程写成复盘文档，记录映射决策、遇到的问题与解决办法，下一次迁移会直接受益。