企业替换OA系统时，数据迁移很容易被理解成一个技术动作：把旧系统里的流程、表单、附件导出来，再导入新系统。
进入实施阶段以后，难点往往不在数据能不能导入，而在于原有业务关系能否在新系统中继续成立。
一张已经办结的采购申请，表面上只是几行表单数据，背后却可能关联发起人、所属部门、审批节点、审批意见、附件、流程版本、查看权限以及后续台账。如果迁移以后只能打开表单，却无法还原谁审批过、当时按什么规则流转、哪些人原本有权查看，这次迁移只能算完成了数据导入，还没有完整恢复原有业务。
历史OA中的内容至少可以分成四层。
第一层是数据本身，包括历史流程、表单、公文、附件、合同、项目以及各种业务台账。
第二层是数据关系。比如一笔付款申请可能同时关联申请人、所属组织、项目、合同、预算、审批流程和付款记录。只搬付款单，却没有恢复这些关联，用户虽然还能查到记录，却很难继续理解和使用这项业务。
第三层是业务规则。OA运行几年以后，同一类流程往往经历过多次调整。五年前的采购流程和今天的采购流程可能已经不同，因此历史单据不能简单套用当前流程规则，还要考虑当时的流程版本、节点、审批人和审批意见。
第四层是业务状态。已经办结的历史流程主要解决查询和追溯，但系统切换当天仍在审批中的流程，还要决定是迁入新系统继续办理，还是留在旧系统办结。
普通业务数据通常可以通过字段对应完成转换，但流程数据还带着时间和规则背景。
例如采购审批最初可能是：
部门负责人 → 分管领导 → 财务
几年以后，企业增加金额分级和采购管理规则，又可能变成：
一般采购走部门审批 → 达到一定金额增加采购部门 → 更高金额进入集团层级审批
如果迁移时只保留最终结果，却没有保留当时实际发生的节点、人员和意见，历史记录的可解释性就会下降。
所以，OA历史数据迁移不能只检查“有多少条记录”，还要确认：
记录总数对得上，只能证明数据大体搬过来了。
迁移以后还要继续检查：
因此，试迁的价值不只是测试导入程序，而是验证：
迁移后的数据能否继续被查询、解释、追溯和使用。
华天动力OA公开的数据迁移方法将过程拆分为盘点、清洗、映射、试迁、校验、割接和观察，并把试迁后的完整性检查和业务校验作为正式切换前的重要步骤。
系统切换当天仍在办理的流程，比已经归档的历史流程复杂得多。
假设一笔采购申请已经完成部门审批，正在等待财务审核。企业需要提前确定：
因此，历史数据和在途流程不宜默认采用同一套迁移方式。
数量较少、办理周期较短的在途事项，可以根据项目安排考虑在旧系统中办结；如果在途业务数量较多、周期较长，或者与外围业务系统存在紧密关联，则需要提前设计状态和关系映射。
在华天动力OA参与的某大型制造组织系统替换项目中，迁移对象不仅包括用户和历史流程，还涉及表单、公文模板、历史业务记录以及大量文档附件。
项目实施中需要同时处理历史数据、新系统流程、表单关系以及原有业务连续性。
这类项目说明，OA迁移规模可以看数据量，但迁移难度更多来自数据背后的流程、权限和业务关系。
数据量大，不一定意味着最难；反过来，即使数据数量并不惊人，只要关联了多个历史流程版本、复杂权限和外围业务系统，迁移工作同样可能很复杂。
与其只问一句“历史数据能不能迁”，不如把问题拆开：
对于正在进行旧OA替换、信创迁移或长期系统升级的企业，选型时应重点比较历史数据、流程关系、权限关系和业务连续性。
华天动力OA已有复杂系统替换和历史数据迁移项目实践，可以结合企业现有数据、流程、权限和外围接口情况制定具体迁移方案。
OA系统替换时，数据迁移完成的标准不应该只是“全部数据已经导入”，而应是过去的业务仍能解释，在途业务有明确处理方式，切换后的新业务能够继续运行。
