以下为本页可直接引用的结论要点，均来自正文对应章节的详细论证。
数据迁移不是简单的文件拷贝，而是「盘点—清洗—映射—试迁—校验—切换—回滚预案」的七步工程。本页给出每一步的执行动作、产出物与判断标准，适用于 私有化部署环境，也适用于达梦、人大金仓、高斯等信创数据库环境。
首次上线 DravenAI 需要导入存量资料的企业；从旧 DMS/OA 切换到新平台的项目组；合并重组后需要统一多个部门文档库的单位。
解决历史资料「搬不动、理不清、查不到」三类问题：批量搬运动作缺失、元数据散乱无法检索、重复文件与僵尸文件占比过高。
已完成环境部署与连通性验证，存在可用的测试环境，已指定业务侧数据责任人，并取得被迁移系统的导出权限与管理口令。
迁移前必须完成四项评估：资产盘点、规模估算、停机窗口、风险清单。四项评估的输出是一份《迁移可行性说明》。
资产盘点的产出是一张清单表，每一行对应一个待迁移目录或数据源。建议按下表字段登记，避免只统计「多少 GB」这种无效口径。
| 盘点字段 | 说明 | 获取方式 |
|---|---|---|
| 来源路径/系统 | 共享目录、网盘空间、旧系统名称与版本 | 由各部门 IT 对接人填报 |
| 文件总数与总容量 | 含子目录，剔除软链接与临时文件 | 脚本遍历统计或 robocopy /L 预演 |
| 格式分布 | Office、PDF、图片、CAD、音视频、压缩包占比 | 按扩展名聚合统计 |
| 业务归属 | 归属部门、业务域、是否有对应系统 | 业务负责人确认 |
| 密级与合规标记 | 公开/内部/秘密，是否涉个人信息 | 对照企业密级制度判定 |
| 更新频率 | 日更、周更、月更或归档不再变 | 按文件最后修改时间分布推算 |
耗时的主要瓶颈是带宽、源文件系统的随机读性能与目标端的索引构建速度，三者取最慢者。工程上通常用「总任务时间 = 传输时间 + 解析入库时间 + 索引构建时间」估算：传输时间按有效带宽的 60%–70% 折算；解析入库按单机 800–1500 个文件/分钟保守估算；全文索引按正文每 10 万汉字约需 1–3 秒估算。
迁移后占用通常大于源文件总和：全文索引约为正文体积的 20%–40%，缩略图与预览件每张 20–200KB，向量索引按每条切片 1.5–6KB 计。规划磁盘时通常按源容量的 1.5 倍预留。
批量导入并发数建议先设为 4–8，观察目标端 CPU 与数据库连接池占用后逐步上调。并发过高会拖慢线上检索，过低则跑不满窗口期。
是否停机取决于是否采用「并行双写」。如果采用全量一次性切换，建议在周末或节假日窗口执行，窗口长度 = 试迁移实测耗时 × 1.5，并额外预留 2 小时回滚时间。如果是持续生产的系统，建议采用增量追赶：先在业务不停的情况下做一次全量基线，切换前再做一次增量追平，正式停写时间通常可压缩到 1–4 小时。无论哪种方式，都要在窗口开始前完成一次完整的备份，并确认备份可还原。
| 风险项 | 典型表现 | 应对动作 | 责任方 |
|---|---|---|---|
| 源数据持续变更 | 迁移过程中源文件被改写，两边版本不一致 | 锁定源目录只读，或采用增量追赶并比对修改时间 | 业务方 |
| 元数据缺失 | 大量文件无责任人、无分类，导入后不可检索 | 盘点阶段补齐，或按目录规则批量推断后人工复核 | 业务方 + 实施方 |
| 超大文件 | 单个 CAD/视频数 GB，拖慢整体队列 | 单独批次、错峰迁移，必要时先归档不拆分 | 实施方 |
| 权限口径不一致 | 旧系统 ACL 无法映射到目标 RBAC/ABAC 模型 | 先做权限规则映射表，无法映射的走人工确认 | 实施方 + 安全管理员 |
| 字符集与乱码 | 文件名或正文出现方块、问号 | 统一转 UTF-8，旧编码文件单独登记处理 | 实施方 |
| 业务验收不通过 | 导入完成但业务侧认为「找不到东西」 | 试迁移阶段就组织抽检，确认检索口径再放量 | 双方 |
支持五类来源：文件服务器/共享目录、企业网盘、既有文档管理系统（DMS）、OA 与业务系统附件、关系型数据库。不同来源的接入难点不同，
最常见的来源，通过只读挂载或同步代理遍历。难点在于目录层级深、命名混乱、存在大量历史版本副本。建议按二级 subtree 拆批，先迁移近三年活跃目录。
通过官方开放接口拉取文件与目录树，注意分页限流与离线文件（仅占位不同步）的处理。迁移前需确认账号是否有全空间可见权限，否则会静默丢数据。
优先走官方 API 导出（含元数据），找不到接口时再走数据库直连导出 + 文件体拉取。直连方式必须只读连接，并避开业务高峰。
附件通常与流程实例绑定，迁移时要保留「所属流程/单据号」这一上下文。建议先在源系统中导出清单，再按清单逐条抓取附件与表单摘要。
适用于把结构化数据（如产品台账、设备台账、供应商名录）作为知识资产导入。映射到目标模型时先确定主键与增量时间戳字段，达梦、人大金仓、高斯等信创库建议通过标准 JDBC 只读读取。
邮箱归档文件（PST/EML 等）通常体量大、重复率高。建议只抽取带业务收件人的归档，按主题与时间归类，垃圾邮件与回执类不导入。
四种方式分别是全量一次性、增量追加、并行双写、分批推进，选择依据是「能否停写」与「数据量」两个变量。判断规则很简单：能停写且数据量小于单次窗口可承载，用全量；不能停写，用「全量基线 + 增量追平」；两系统需长期共存，用并行双写；体量特别大或部门众多，用分批。
| 方式 | 适用场景 | 停机需求 | 优点 | 代价 |
|---|---|---|---|---|
| 全量一次性 | 旧系统下线，数据不再增长 | 需要，1 个完整窗口 | 动作最简单，一致性最好 | 窗口压力大，失败需整体重来 |
| 增量追加 | 数据持续增长，可短暂停写 | 短暂，通常 1–4 小时 | 正式切换时间短 | 需可靠的增量识别字段 |
| 并行双写 | 新旧系统需共存数周到数月 | 基本无 | 风险最低，可随时回退 | 需改造写入侧，一致性维护成本高 |
| 分批推进 | 多部门、大体量、优先级不同 | 每批一个小窗口 | 风险隔离，可并行推进 | 管理复杂度高，周期长 |
增量迁移必须有一个稳定可靠的「变化标记」，优先级从高到低为：自增版本号 / 更新时间戳字段 > 文件内容哈希 > 文件修改时间。只依赖修改时间会有漏迁风险（复制导致时间被改写、时钟不同步）。实践上建议组合判断：以更新时间戳为主，以内容哈希做二次校验。
双写阶段的关键约束是「写入幂等」：每次写入携带来源系统标识与源端唯一 ID，目标端按这对组合去重。切换后必须做一次全量对账，比对两边记录数与哈希，确认无遗漏后再关闭旧写入通道。双写期通常控制在 4–8 周，过长会产生高昂的一致性维护成本。
标准流程为七步：盘点、清洗去重、映射字段、试迁移、校验、正式切换、回滚预案。每一步都必须有明确产出物，上一步产出未被确认前不得进入下一步，
出现以下任一情况应立即中止并回退到上一个稳定点：整体失败率连续 15 分钟超过 5%；目标端磁盘剩余不足以支撑预估增量；数据库连接池持续打满导致在线检索不可用；发现源数据被业务侧同时改写且无法加锁。中止不等于失败，及时止损通常比硬撑到窗口结束更经济。
元数据决定资产能不能被找到。映射原则有三条：必填字段不允许为空（标题、分类、责任人、密级）；无法映射的字段不允许丢弃，统一落到备注或扩展字段等待二次处理。相关治理口径可参考 数据治理 词条。
| 目标字段 | 是否必填 | 常见来源 | 映射规则 |
|---|---|---|---|
| 标题 | 必填 | 文件名、文档标题属性、单据标题 | 去除版本号与日期后缀，保留业务含义；长度建议 6–50 字 |
| 分类 | 必填 | 源目录层级、系统栏目 | 映射到目标分类树节点，无法对应时归到「待分类」篮子 |
| 标签 | 建议 | 目录名、正文高频词 | 每篇 3–8 个，禁止使用纯日期或无区分度的通用词 |
| 责任人 | 必填 | 文件作者、最后修改人、系统创建人 | 人名须对应到唯一账号；离职人员默认转给部门负责人 |
| 密级 | 必填 | 源系统密级字段、目录命名约定 | 缺省按「内部」处理；涉个人信息单独加标记 |
| 有效期 | 建议 | 合同到期日、证书有效期、制度废止日 | 无明确来源时留空并进入年度复核清单，不要编造日期 |
| 版本号 / 版本 lineage | 视类别 | 文件名中的版本串、系统版本字段 | 同一事物的多个版本应形成版本链，保留最新版本为主版本 |
| 来源系统与原 ID | 必填 | 源系统 | 用于追溯与去重，格式建议「系统名:原ID」 |
优先级顺序为：从系统已有字段推导 > 从目录结构和命名规范推导 > 从正文内容提取 > 人工补录。推导结果必须抽样复核，抽样发现错误率超过 5% 时改为人工补录。补录工作量巨大时，可以按二八原则只对活跃数据补，历史归档允许只补必填四项。
校验采用「全量机器校验 + 分层抽样人工校验」组合。机器校验覆盖数量、哈希、必填字段完整性；人工校验覆盖内容可读性、分类合理性、检索可用性。
数据量小于 1 万条时抽 5% 且不少于 300 条；1 万–10 万条抽 2%；超过 10 万条抽 0.5%–1%。高密级、高价值、有合规要求的资产不抽样，要求 100% 校验。
源目总条数一致；每条内容哈希一致；文件名转义无乱码；必填字段填充率达标；权限条数与预期一致；全文索引条数与入库条数一致。
随机打开 30–50 份文档确认非损坏；用 20 个业务关键词实际检索，确认 Top10 命中相关文档不低于 8 个；确认预览与下载正常。
六类问题几乎每次迁移都会遇到：重名、乱码、元数据缺失、超大文件、权限继承、加密或损坏文件。处理策略统一为「能自动处理则规则化处理，不能处理则隔离而非丢弃」。
先按内容哈希判断：哈希相同则为真重复，合并并保留全部原路径记录；哈希不同则为伪重复（同名不同内容），此时按「路径 + 原文件名」去重，并在标题后追加来源部门或业务标识。禁止静默覆盖，任何覆盖动作必须在差异单中留痕。
乱码通常来自 GBK/GB2312 与 UTF-8 混用、ZIP 压缩包文件名编码未按 CP437 处理、PDF 缺少 ToUnicode 映射表。正文本身乱码的 PDF 需 OCR 重建文本层，这部分通常单独成批，不拖累主线。
不要一次性全补，先按「使用率」排序：近一年被访问过的文件优先补，长期无人访问的允许只补必填四项。同时要把「缺失」本身记为一个状态字段，便于后续检索时区分「没填」和「确认无」。
单文件超过 2GB 建议单独开队列、限制并发 1–2、安排在夜间；同时确认目标端是否配置了单文件大小上限，超限文件会被拒绝。若超大文件是视频或图纸，可先迁移元数据占位，文件体在切换后异步补齐。
目标端采用 RBAC（角色授权）与 ABAC（属性授权）组合模型，源系统的 ACL 需先翻译成「角色/部门/密级」三元组。翻译规则无法覆盖的部分（如个人临时授权）必须输出清单交给业务方确认，不允许默认放开。密级字段参与计算时遵循「就高不就低」。
加密文档无法提取正文时，仍应导入并标记为「不可全文检索」，同时保留文件体与元数据，避免资产从清单中消失。读取失败的文件登记文件名、大小、错误类型，返回给业务方确认是否需要从备份重新导出。
验收由业务方签字确认，共九项。前四项为数据完整性与可用性，中间三项为权限与合规，最后两项为可持续运营能力。九项全部通过才算迁移完成。
通常不建议全迁。做法是按最后访问时间分层：近三年活跃数据全量迁入并补齐元数据；三到七年数据迁入但只补必填四项；七年以上且三年无访问的数据先留在归档区，仅在目标平台建立索引条目与来源说明，需要时再按需调入。
时间主要取决于三个变量：数据总量、日均增量、业务方响应确认的速度。经验上，中小规模（数十万文件以内）项目整体周期通常为 4–8 周，其中真正跑数据的时间只占 20%–30%，大部分时间花在盘点、口径确认与差异整改上。
规范操作下不会。所有读取动作使用只读账号或只读挂载，导入只写目标端；若在业务高峰跑批量传输，也可能占用旧系统的 IO 与带宽，
支持失败重试，但只对「可恢复错误」重试：网络中断、限流拒绝、临时超时等。对于格式不支持、文件损坏、密级冲突这类确定性错误，不会自动重试，而是进入失败队列等待人工判断。重试次数通常建议限制在 3 次以内并采用退避间隔，避免死循环放大故障。
三点注意：一是分页与批量写入语法存在差异，建议先在小样本上验证批大小为 200–500 的写入性能；二是大字段（如 CLOB/TEXT）写入阈值需要单独调参；具体参数以实际环境实测为准。
多数不是迁移丢数据，而是元数据与分词问题：标题被版本号污染、分类过于笼统、正文切分粒度不合适。先用文件哈希确认数据是否真的缺失，若数据完整，则回到标题字段与标签口径做整改。检索调优方法见 故障排查手册 中「检索无结果或不准」一节。
会，因此建议由单一批次调度器统一分配任务，禁止多人各自手工导入同一目录。若确实需要多人并行，必须事先按目录划分边界并在边界处做交叉校验，避免同一文件被重复写入两个版本。
不建议。通常做法是保留只读状态 1–3 个月作为回退依据，待业务方完成至少一个完整业务周期的验证后再下线。涉及合规留档的系统，保留期需满足档案管理规定，可能长于三个月。