许可是整件事里最简单的一步。

可以带走

• 邮件，连同文件夹结构与历史记录，逐个邮箱迁移
• 文件与共享盘，目录树保持原样
• 组织通讯录、部门与汇报关系
• 日历，包括周期性会议与会议室预订
• 通讯组与共享邮箱，重新映射成群组
• 文档——在「转成 Lark 文档」比「继续当文件存着」更好的地方，就转过去

不会原样过来

每一次迁移都会留下残渣。现在听到，比在切换那个周末才发现，要便宜得多。

• 其他平台的聊天记录很少能迁成还能用的样子；我们通常的做法是让旧工具只读保留一段时间
• 层层嵌套的权限模型一般要重新设计，而不是照搬——照搬会把问题一起搬过来
• 宏很重的表格继续当文件存着。它们不会自己变成 Base 表，假装它们会，是迁移延期一个月的典型原因
• 为旧套件写的插件，要么找到等价方案，要么重做，要么明确决定不要了

一个靠谱的计划长什么样

• 盘点——席位、邮箱大小、文件体量，以及那些不坏就没人记得的集成
• 租户、域名、通讯录与权限，先在试点组里跑通，再让其他人看见
• 邮件与文件分批迁移，从最旧的数据开始，这期间旧系统照常运行
• 切换，旧系统改为只读，而不是直接关掉
• 然后才是审批流、Base 应用与 AI 配置——等人都进来开始干活之后，不是之前

我们需要你这边提供什么

• 现有租户的管理员权限，或者会议室里有一个手上有权限的人
• 一个能拍板「组织架构应该长什么样」的人——这个决定不该由我们替你做
• 一份诚实的集成清单，包括那些由已经离职的人搭的

把你们现在在用的发给我们。

人数、现在的邮件与文件平台、大致的数据量，以及任何一个你不愿意弄丢的集成。我们会回一个迁移顺序，并指出我们认为有风险的部分。