只迁通讯录会遗漏流程依赖
员工账号之外，应用入口、审批、待办、机器人和集成接口也可能依赖旧平台。
场景解决方案 / 企业办公平台迁移解决方案
从飞书迁移至钉钉，需要评估哪些业务范围？
先盘点人员、应用、流程和资料依赖，再确定从飞书迁移到钉钉的分批顺序与切换边界。
不同数据对象的导出、导入和持续同步能力并不相同；不承诺所有历史内容可无损迁移。
客户问题
更换办公平台，身份迁移只是整个业务切换的一部分
迁移是否可行取决于当前使用范围、第三方应用依赖和业务连续性要求。
并行期间数据归属不清
新旧平台同时使用时，人员信息和流程可能两边更新，产生重复消息或状态不一致。
整体思路
按对象盘点、按业务分批验证，再决定切换
先区分可迁移数据、需要重建配置的应用、可继续留在原系统的内容及无法自动迁移的历史记录；明确主数据源、并行期规则和回退条件后，再选小范围用户验证关键流程。
- 01现状盘点清点账号、应用、流程与历史资料
- 02迁移评估区分可移、需重建及保留对象
- 03试点批次核验人员和关键业务流程
- 04切换决策依据结果扩大、调整或回退
本页聚焦迁移评估与系统衔接；飞书与钉钉各类历史数据的可迁移范围需向平台方逐项确认。
核心任务
盘点身份、应用与业务依赖 · 验证分批迁移和切换条件
01 / 盘点身份、应用与业务依赖
找出切换后必须继续运行的流程
- 01业务访谈识别使用人和关键流程
- 02依赖清单记录登录、审批、待办和集成
- 03范围判断标记可迁、需重建及保留项
原来怎么处理
项目团队往往先处理通讯录，再发现部分应用入口、审批或自动化仍依赖旧平台。
数犀如何处理
与业务和 IT 共同清点人员、组织、身份认证、应用、流程、消息和历史数据；按来源与目标平台实际接口区分自动迁移、重建、人工归档或暂留对象。
由业务负责人逐项确认关键系统和不可迁移项；重点核对第三方应用登录与流程通知。
希望带来的变化
提前看到迁移缺口和需人工处理事项，避免仅按账号数量判断项目完成。
相关能力系统与流程盘点账号和组织映射接口依赖核对
02 / 验证分批迁移和切换条件
用试点决定是否扩展
- 01选定批次明确人员与业务范围
- 02并行验证核对数据、通知和入口
- 03切换复核确认回退触发条件
原来怎么处理
一次性全员切换后才发现关键审批或应用入口未准备好，难以快速回退。
数犀如何处理
按部门或业务选择试点批次，建立并行规则、数据校验、用户通知和切换决策条件。实施工具、迁移脚本及具体迁移执行范围需由项目确认。
使用试点清单逐项验证登录、流程提交、待办通知和资料访问；演练中断后的旧入口回退及未迁移数据处理。
希望带来的变化
把大范围切换拆成可核查的决策步骤，降低未知依赖集中暴露的风险。
相关能力试点计划数据核对切换与回退演练
改善与验证
以试点清单核对业务连续性与迁移缺口
记录可迁移对象、需重建项目、人工补偿步骤和用户问题。
| 常见处理 | 希望实现的变化 | 试点检查方法 |
|---|---|---|
| 迁移范围不透明员工账号之外，应用入口、审批、待办、机器人和集成接口也可能依赖旧平台。 | 希望实现的变化关键人员、系统、流程和资料被分类并由负责人确认。 | 试点检查方法抽查各业务线清单完整性，核验可迁移、需重建和保留对象。 |
| 切换后业务中断新旧平台同时使用时，人员信息和流程可能两边更新，产生重复消息或状态不一致。 | 希望实现的变化试点批次完成核心流程验证并具备回退判据。 | 试点检查方法检查试点用户登录、审批、待办和第三方应用；演练并记录回退结果。 |
历史消息、审批附件、机器人及第三方应用的数据能力需依据飞书和钉钉接口与许可逐项确认；不承诺全量、无损或不中断迁移。
