第一张表先盘点数据资产和迁移范围
先列出旧系统中的业务对象，而不是直接列数据库表名。客户、联系人、订单、合同、审批记录、附件、账号、权限和操作日志分别服务不同业务；项目负责人要与实际使用部门确认哪些必须进入新系统，哪些只需归档查询，哪些已到期或无权继续保留。
盘点表至少记录数据对象、来源位置、负责人、规模级别、时间范围、敏感程度、当前质量、目标处理方式和验收人。规模可以先写可核对的实际记录或级别，不必为估算迁移工时编造精确数量。若多个系统保存同一对象，还要明确哪个来源是最终依据。
- 业务对象及其实际用途
- 来源系统、文件或数据库位置
- 业务负责人和技术联系人
- 必须迁移、只读归档或不再保留
- 数据敏感程度与允许接触人员
- 最终验收人和核对依据
第二张表把质量问题变成清洗规则
旧数据常见问题包括重复记录、空值、格式不一致、失效状态、错误编码和缺少关联对象。不要在导入脚本里临时决定如何处理，而应把每类问题写成规则：如何识别、自动处理还是人工确认、保留哪条记录、冲突时由谁决定，以及原值是否需要留档。
清洗规则要尽量可重复执行。示例上，“手机号格式不符合预期”不能直接等同于删除客户；可以先标记异常并交业务负责人确认。“名称相同”也不一定代表重复对象。所有合并、舍弃和修正都应有可追踪记录，避免迁移后无法解释某条数据为什么发生变化。
- 空值允许保留、补齐还是阻止导入
- 重复记录的判断字段和合并责任人
- 日期、金额、编码和状态的统一格式
- 失效数据的保留或归档规则
- 人工修正记录与原值留存方式
第三张表明确旧字段到新字段的映射
字段名称相同不代表含义相同，名称不同也可能表示同一业务概念。映射表应同时记录旧字段、旧含义、新字段、新含义、数据类型、是否必填、转换方式、默认值和异常处理。状态、地区、部门、产品和客户等级等代码，还要列出旧值到新值的逐项对应。
关联关系比单个字段更容易被忽略。例如订单引用客户、审批记录引用发起人、附件引用业务单据；如果只导入主表而没有保存新旧标识对应，后续关系可能断开。映射设计应说明先导入哪些主对象、如何生成新标识，以及子记录怎样找到正确的目标对象。
- 旧字段与新字段的业务含义
- 类型、长度、必填和唯一性差异
- 代码值、状态值和单位换算规则
- 主记录、子记录和附件的导入顺序
- 新旧标识对应表的保存与销毁时机
第四张表用试迁移记录暴露异常
试迁移不是只挑一批最整齐的数据证明脚本能运行，而要覆盖正常记录、缺失字段、重复候选、历史状态、跨部门权限、附件和多层关联。测试环境应使用经过授权和适当处理的数据，控制下载、复制和访问范围，不把生产数据随意发给无关人员。
每轮试迁移都要保存批次、输入版本、规则版本、开始结束状态、成功与失败记录、异常分类和处理结论。发现问题后先修改规则或源数据，再用同一批测试范围重新执行，确认结果能够重复。只靠人工在后台改几条记录，无法证明正式迁移时能稳定处理同类问题。
- 测试批次和输入数据版本
- 清洗与映射规则版本
- 成功、失败和跳过记录的分类
- 异常复现步骤与责任人
- 修正后重跑结果是否一致
- 测试数据访问和清理记录
第五张表同时做技术核对和业务核对
迁移完成不能只看“脚本执行成功”。技术核对应比较源端、处理过程和目标端的记录数量、关键字段空值、唯一键、金额汇总、日期范围、失败清单和关联完整性；任何差异都要能落到明确规则或异常记录，不能用大致相同代替解释。
业务核对则由实际使用人员确认记录是否可搜索、详情是否可读、状态是否正确、附件是否能打开、上下级关系是否成立、权限是否符合职责，以及后续动作能否正常执行。抽样应覆盖重要类型和异常类型，而不是只看最新几条。验收表要记录核对人、证据、差异和结论。
- 总量、分类数量和关键汇总
- 关键字段、唯一键与日期范围
- 客户、订单、审批和附件关联
- 搜索、查看、编辑和后续业务动作
- 部门、角色和数据可见范围
- 差异原因、处理状态和验收签字
第六张表写清正式切换与回滚
正式迁移前要确定数据冻结窗口：何时停止旧系统新增和修改，冻结期间业务如何记录，最后一次增量从哪里取得，新系统何时开放。若无法完全停机，就要设计增量同步和冲突处理，而不是假设切换期间不会产生新记录。切换通知也要覆盖一线使用人员。
回滚方案要能执行，而不是文档里写一句“失败则恢复”。应明确备份内容和恢复验证方式、触发回滚的条件、谁有决定权、旧系统重新开放前如何处理冻结期间记录，以及新系统已产生数据如何处置。回滚演练或恢复验证应在正式窗口前完成，避免真正需要时才发现备份不可用。
- 冻结开始、最终导出和新系统开放时间
- 冻结期间业务记录与补录办法
- 备份范围、保存位置和恢复验证
- 回滚触发条件与决策责任人
- 新旧系统重新切换后的数据处理
- 用户通知、支持渠道和问题升级路径
把迁移任务写进合同和最终交付清单
如果数据迁移由外部开发团队负责，范围和验收条件应进入需求、报价或合同附件。至少写明数据对象、历史时间范围、迁移次数、清洗责任、映射确认人、附件处理、权限恢复、失败记录交付和验收方法。否则“包含数据迁移”可能只表示提供一次基础导入。
最终交付应包括经确认的盘点表、清洗规则、字段映射、执行脚本或可重复流程、批次日志、异常清单、核对结果、备份与回滚说明。账号、数据库副本和临时导出文件在项目结束后还要按约定收回或清理。需要评估真实旧系统时，可返回 5656AI 首页提交数据类型、系统边界和目标流程，再据此拆解迁移工作。
- 迁移范围和不包含项
- 业务方与开发方分别负责的清洗工作
- 试迁移、正式迁移和失败重跑次数
- 验收口径、异常处理和签字责任
- 脚本、日志、映射表和回滚资料交付
- 临时数据、账号和访问权限清理