迁移切换失败时，先冻结新系统写入，确认失败发生在数据抽取、映射转换、导入校验还是切换后业务验证，再判断原系统能否继续承载业务、是否需要回退。处置顺序是先保业务可用，再修数据，最后重新切换；恢复后用数量核对、抽样比对和关键业务场景走查确认，并把本次原因补进下次切换的检查项。处置过程中的问题登记、责任人分派和验证记录，可以在ONES中通过工作项与文档协作完成。
要点总览（TL;DR）
- 迁移切换失败后先冻结新系统写入，确认失败发生在抽取、映射转换、导入校验还是切换后验证，再判断原系统能否继续承载业务。
- 原因排查按假设—证据推进：用转换报告、导入日志、数量对账、账号核对清单逐类确认或排除，避免凭经验下结论。
- 处置路径取决于三个条件：失败是否局部、新系统是否已对外启用、原系统是否可并行；回退是控制业务风险的正常手段。
- 重新切换前必须完成根因修复和小范围试迁验证，清理数据、覆盖写入、删除账号前要备份并确认可恢复。
- 恢复后用数量核对、抽样比对、附件与权限走查、端到端流程跑通确认，并把本次原因写成下次切换的检查项。
先判断失败发生在哪一步、影响多大
故障现场最容易出现的错误，是在原因尚未查清时反复重跑导入或继续推进切换。此时应先把失败固定在一个可描述的环节上，再判断业务是否还能正常使用。判断顺序建议是：确认新系统是否已经对外启用，确认原系统是否仍可读写，然后定位失败节点，最后界定受影响的数据范围。
四个节点各有典型症状，可以据此快速归类：
- 数据抽取阶段：源系统连接失败、抽取任务中断、导出文件不完整，表现为迁移任务在开始阶段即报错，目标系统几乎没有新增数据。
- 映射转换阶段：字段对应关系缺失、枚举值无法转换、日期或人员格式不匹配，表现为转换报告出现大量跳过记录或错误记录。
- 导入校验阶段：必填项为空、唯一性冲突、外键关联对象不存在，表现为导入批次部分成功、部分失败，或整批被校验规则拒绝。
- 切换后业务验证阶段：数据已导入但用户登录后看不到项目、流程状态不对、附件打不开，表现为业务人员反馈“数据在但用不了”。
影响范围要落到具体对象上，而不是笼统地说“迁移有问题”。需要确认受影响的是哪些团队或部门、哪些项目或工作项集合、哪个时间段产生的数据，以及是否包含附件和历史版本。范围界定清楚了，才能判断是局部补导还是整体回退。
业务可用性是决定处置优先级的关键。原系统仍可读写、新系统尚未对外启用时，处置空间最大，可以从容修复；新系统已对外启用而原系统已停写时，应优先恢复业务入口，再处理数据问题。无论哪种情况，处置优先级都遵循同一顺序：先保业务连续，再修数据，最后重新切换。
| 失败环节 | 典型症状 | 影响对象 | 当前业务可用状态判断 |
|---|---|---|---|
| 数据抽取 | 连接失败、任务中断、导出文件不完整 | 尚未产生目标数据，影响范围为整批迁移 | 原系统通常仍可用，新系统无有效数据 |
| 映射转换 | 字段无对应、枚举转换失败、大量记录被跳过 | 特定字段或特定类型的工作项 | 原系统可用，新系统数据不完整 |
| 导入校验 | 必填为空、唯一性冲突、关联对象缺失 | 失败批次涉及的记录及其关联数据 | 原系统可用，新系统部分数据可用 |
| 切换后验证 | 看不到项目、流程状态异常、附件无法打开 | 特定团队、角色或业务流程 | 需确认新系统是否已对外启用、原系统是否已停写 |
常见原因假设与排除证据
迁移失败的原因不能靠经验直接下结论。可行的做法是先列出假设，再为每个假设指定验证方法和判定证据，用证据决定排除还是确认。下面按数据、数量、权限、流程配置、环境网络五类整理常见假设及对应的排除方式。
数据层面的假设与证据
字段映射缺失、必填项为空、枚举值不匹配、附件或历史版本丢失，是导入校验失败和切换后数据不可用的高频原因。验证时查看转换报告和导入日志中的错误明细，确认报错集中在哪些字段；对附件和历史版本，抽取若干条记录在源系统与目标系统中逐一打开比对。判定为是的证据是错误记录能按字段归类且可复现；判定为否的证据是同一批数据在修正映射后完整通过校验。
数量层面的假设与证据
记录条数与源系统对不上、重复导入、增量数据漏迁，需要通过数量核对来验证。分别统计源系统与目标系统在相同范围内的记录总数、各工作项类型的数量、附件数量，与导入报告中的成功数、失败数、跳过数对账。三者能对上，数量假设可以排除；对不上且差额与失败批次吻合，则确认是导入失败导致；差额无法解释时，需检查是否存在重复导入或增量窗口遗漏。
权限与组织层面的假设与证据
成员账号未建立、角色权限错配，典型表现是数据已导入但用户登录后看不到内容。验证方法是准备一份账号核对清单，逐项确认关键成员账号是否存在、是否归属正确团队、角色是否具备对应项目或空间的访问权限。用其中一个受影响账号实际登录走查，能复现“看不到数据”即为确认；账号与权限核对无误后仍看不到，则应转向数据归属或项目成员配置继续排查。
流程与配置层面的假设与证据
工作流状态、字段选项、通知规则未随数据迁移，会导致数据“在但状态不对”。验证时抽取若干条处于中间状态的工作项，比对源系统与目标系统的当前状态、可选状态和字段选项；再触发一次状态流转，观察通知是否按预期发出。状态值与选项一致、流转可正常完成，即可排除该类假设。
环境与网络层面的假设与证据
导入中断、接口超时、批量任务失败，通常留有明确痕迹。查看导入任务日志中的中断时间点、超时错误码和重试记录，确认失败是否集中在某一批次或某一时间段。日志显示任务在固定位置反复中断，指向环境或网络限制；日志显示任务完整执行但结果不符，则应回到数据与映射层面排查。
| 原因假设 | 验证方法 | 判定为是的证据 | 判定为否的证据 |
|---|---|---|---|
| 字段映射缺失或枚举不匹配 | 查看转换报告错误明细，按字段归类 | 错误集中在特定字段且可复现 | 修正映射后同批数据完整通过 |
| 必填项为空或关联对象缺失 | 查看导入校验失败清单 | 失败记录均指向同一必填字段或关联对象 | 补齐数据后校验通过 |
| 附件或历史版本丢失 | 抽样在两端逐一打开比对 | 抽样中存在无法打开或版本缺失 | 抽样全部可打开且版本一致 |
| 记录数量对不上 | 按类型统计两端数量并与导入报告对账 | 差额与失败或跳过批次吻合 | 总数、分类数、附件数均一致 |
| 重复导入或增量漏迁 | 检查唯一标识重复情况与增量时间窗口 | 存在重复记录或时间窗口内数据缺失 | 无重复且增量区间数据完整 |
| 账号未建立或权限错配 | 账号核对清单加受影响账号实际登录走查 | 账号缺失或登录后无对应访问权限 | 账号齐全、权限正确、数据可见 |
| 工作流状态或字段选项未迁移 | 抽样比对状态值与选项，触发一次流转 | 状态不符或流转无法完成 | 状态一致且流转与通知正常 |
| 导入中断或接口超时 | 查看任务日志的中断点与错误码 | 任务在固定位置反复中断 | 任务完整执行，结果差异另有解释 |
按场景处置：继续修复、回退还是重新切换
原因初步定位后，处置路径的选择取决于三个条件：失败是否局限于局部数据、新系统是否已对外启用、原系统是否仍可并行运行。三条路径并非互斥，实际处置中常常先回退保业务，再修复，最后重新切换。
继续修复的适用条件与步骤
失败集中在局部数据、新系统尚未对外启用、原系统仍可读写时，适合在原位继续修复。步骤是：暂停后续导入任务，保留当前失败现场；按上一节的证据定位具体字段或批次；修正映射或补齐数据后，只对失败范围做补导；补导完成后重新执行校验。停止点是补导前的数据备份，确认目标系统中已有数据可回退到补导前状态再执行。
回退的适用条件与操作
新系统已对外启用但核心业务无法正常使用，或失败范围无法在短时间内界定清楚时，应优先回退。操作顺序是：冻结新系统写入，避免回退期间产生新数据造成二次混乱；导出并保留失败现场日志、导入报告和错误清单；确认原系统数据在并行期间未被污染，包括是否有人已在原系统中修改或删除数据；恢复原系统为业务主入口，并通知相关团队。回退不是失败，而是把业务风险控制在可接受范围内的正常手段。
重新切换的适用条件与步骤
根因已定位并修复、且完成过一次小范围试迁移验证后，才具备重新切换的条件。步骤是：冻结写入，保留证据，修复根因，选取一个团队或一个项目做小范围试迁并完成验证，确认无误后再执行全量重切。跳过试迁直接全量重切，会把同一风险再放大一次。
破坏性操作的风险边界
清理已导入数据、覆盖写入、删除账号都属于破坏性操作，执行前必须完成备份并确认可恢复。具体边界包括：清理前导出目标系统现有数据或确认可从源系统重新导入；覆盖写入前保留被覆盖对象的原始版本；删除账号前确认该账号不承担审批或流程节点职责。任何一步无法确认可恢复，就应停止操作，改用回退路径。
| 处置路径 | 适用条件 | 关键步骤 | 停止点与备份要求 |
|---|---|---|---|
| 继续修复 | 失败局限于局部数据；新系统未对外启用；原系统可并行 | 暂停导入、保留现场、修正映射、局部补导、重新校验 | 补导前备份目标系统现有数据 |
| 回退 | 新系统已启用但核心业务不可用；失败范围短时间无法界定 | 冻结新系统写入、保留日志与报告、确认原系统未被污染、恢复原系统为主入口 | 回退前完成现场证据导出 |
| 重新切换 | 根因已定位修复；已完成小范围试迁验证 | 冻结写入、保留证据、修复根因、小范围试迁、全量重切 | 试迁验证通过前不启动全量重切 |
处置过程涉及多个角色并行推进时，问题登记、责任人分派和状态跟踪需要有统一载体。在ONES中，可以把每个失败项登记为工作项，指定负责人和截止时间，把导入报告、比对结果作为附件挂在对应工作项下，验证结论以文档形式留存并与工作项关联，使“谁在处理、处理到哪一步、验证是否通过”在同一个流程里可查。
恢复后的验证与复发预防
系统恢复运行不等于迁移成功。恢复后的验证要回答两个问题：数据是否完整可信，业务是否真正可用。验证通过后，还要把本次失败转化为下次切换的检查项，否则同类问题会在下一次迁移中重复出现。
恢复验证的五个维度
- 记录数量核对：按工作项类型、项目、时间段分别统计源系统与目标系统数量，与导入报告的成功数、失败数、跳过数三方对账，差额为零或可逐条解释。
- 关键字段抽样比对：按类型分层抽样，比对标题、状态、负责人、日期、优先级等关键字段，抽样比例和样本选择规则提前确定，避免只挑“看起来正常”的记录。
- 附件与历史可打开：抽样打开附件、查看历史版本和变更记录，确认内容完整、版本顺序正确。
- 权限与角色走查：用不同角色的真实账号登录，确认各自能看到应看的数据、不能看到不应看的数据。
- 核心业务流程端到端跑通：选取一条代表性流程，从创建、流转、审批到关闭完整走一遍，确认状态、通知和关联数据均符合预期。
验证证据要留存并与责任人绑定。比对结果、走查记录、端到端测试结论应形成书面记录，由业务负责人和数据负责人分别签字确认。没有签字确认的“验证通过”，在后续出现争议时无法追溯。
把失败原因转为下次切换的检查项
每次失败都应产出至少一条可执行的检查项，写明检查内容、执行时点和通过标准。例如本次失败源于枚举值不匹配，检查项就应写成“切换前完成全部枚举字段的取值映射核对，映射表中无未对应项方可通过”。检查项积累成清单后，下次切换的预检就有了明确依据，而不是依赖个人记忆。
| 本次失败原因 | 增补检查项 | 执行时点 | 通过标准 |
|---|---|---|---|
| 字段映射缺失或枚举不匹配 | 核对全部字段映射表与枚举取值 | 试迁移前 | 映射表无未对应项，试迁校验零错误 |
| 记录数量对不上 | 按类型统计两端数量并与导入报告对账 | 全量导入后、切换前 | 差额为零或逐条有解释 |
| 账号或权限错配 | 账号核对清单加多角色登录走查 | 切换前一日 | 关键角色均可看到应看数据 |
| 工作流状态未迁移 | 抽样比对状态值与选项并触发流转 | 试迁移验证阶段 | 状态一致，流转与通知正常 |
| 导入中断或超时 | 检查任务日志与重试机制 | 全量导入前 | 试迁批次完整执行无中断 |
切换窗口与并行期安排
为降低再次失败的业务影响，切换窗口应预留回退时间，并在切换后保留原系统只读一段时间作为兜底。只读期的长度取决于业务对数据新鲜度的要求和验证进度，期间新系统为唯一写入入口，原系统仅供查询和比对。只读期结束前完成全部验证并签字确认，再正式停用原系统。这样即使切换后发现问题，也能在不丢失数据的前提下快速对照和恢复。
常见问题
迁移切换失败后，原系统已经停写，还能回退吗？
可以回退，但要把顺序做对。先冻结新系统写入，导出失败现场日志、导入报告和错误清单，再确认原系统在停写期间数据未被修改或删除，然后把原系统恢复为业务主入口并通知相关团队。停写期间如果原系统数据被改动过，回退前需要先核对差异，避免两边数据互相覆盖。
回退后不要立即重新切换，先利用原系统恢复业务，再按证据定位根因，完成小范围试迁验证后再安排全量重切。
导入报告显示全部成功，但业务人员说看不到数据，应该先查什么？
这种情况优先查权限与组织配置，而不是回头怀疑导入。准备账号核对清单，确认受影响成员账号是否存在、是否归属正确团队、角色是否具备对应项目或空间的访问权限，再用其中一个受影响账号实际登录复现。账号和权限都正常时，再检查数据归属和项目成员配置。
如果多个团队同时反馈，说明问题可能出在组织架构或角色映射层面，排查范围应扩大到全部关键角色，而不是逐个账号处理。
什么情况下可以继续修复，不用整体回退？
同时满足三个条件时适合原位修复：失败集中在局部数据、新系统尚未对外启用、原系统仍可读写并行。操作上先暂停后续导入任务并保留失败现场，按错误明细定位具体字段或批次，修正映射或补齐数据后只对失败范围补导，补导前备份目标系统现有数据，确保可以回到补导前状态。
如果失败范围短时间界定不清，或核心业务已经无法在新系统完成，继续修复的代价会超过回退，应改走回退路径。
重新切换前，试迁移要做到什么程度才算通过？
试迁移应覆盖与全量切换相同的环节：抽取、映射转换、导入校验和业务验证。选取一个团队或一个项目作为样本，完成数量对账、关键字段抽样比对、附件与历史版本打开、多角色登录走查，并跑通一条代表性业务流程。样本范围内校验零错误、差额可解释、流程状态与通知正常，才具备全量重切的条件。
试迁通过不代表全量一定顺利，全量导入后仍需在切换前再做一次数量对账和关键角色走查。
恢复验证的记录需要保留多久、由谁确认？
验证记录建议至少保留到原系统只读期结束、正式停用之后，便于出现争议时追溯。比对结果、走查记录和端到端测试结论应形成书面文档，由业务负责人和数据负责人分别签字确认；只写“验证通过”而没有责任人和证据的记录，在后续核对中起不到作用。
如果组织有审计或合规要求，保留期限按内部规定执行，并把验证文档与对应的迁移任务关联存放。
