PRODUCT / 迁移
不搬历史，只搬「活的」
大多数迁移失败不是工具不好，是搬了太多用不上的东西，最后被重量压垮。 这条路径的目标是：两周内跑起来，而不是三个月内搬完。
STEPS // 三步
先跑起来，再谈完整
01
只迁「活的」
未截止的窗口、在制的任务、近 30 天的决策。历史留在原处，只留一条链接。
02
字段先少后多
第一版只迁 5 个字段：标题 / 状态 / 责任人 / 截止日 / 备注。其余后补。
03
两周并行
老工具不删。新系统只做「盯窗口」一件事，跑顺了再扩。
MAP // 字段映射
从现有工具怎么搬
凡是「部门当责任人」「备注当缺口」的，都要人工拆一次——这两处是迁移里最容易埋雷的。
| 来源 | 原字段 | 战簿字段 | 处理方式 |
|---|---|---|---|
| Notion 数据库 | 页面标题 | 任务标题 | 直接映射 |
| Notion 数据库 | Status（下拉） | 任务状态 | 收敛成 4 态：在制 / 阻塞 / 待验收 / 已交付 |
| Notion 数据库 | Assignee（部门） | 责任人（人名） | 部门要拆到人，否则等于空值 |
| 飞书多维表 | 日期字段 | 窗口截止日 | 只迁未截止的；已过期的另存归档表 |
| 飞书多维表 | 附件 | — | 不迁。附件留在原处，留一条链接 |
| Excel 台账 | 备注列里的缺口 | 缺口字段 | 需要人工拆成独立字段 + 责任人 |
| Linear / Jira | Issue state | 任务状态 | 有映射表，但「In Review」要自己定义归属 |
| Linear / Jira | Cycle / Sprint | 周目标 | 不建议迁——周期结构不同，重建更快 |
NO // 不建议迁
四样东西，直接放弃
- 已完成的历史 issue（几百上千条）——它们不会帮你做明天的决定
- 评论流——上下文在人的脑子里，不在时间线里
- 附件——留在原处，别复制一份增加同步负担
- 权限体系——1–15 人不需要，迁过来只会增加配置成本
RISK // 迁移最大的坑
把「备注」当「缺口」
老系统里「材料还差一份」通常写在备注里。搬到新系统如果还放备注，缺口就不可见了。
正确做法：拆成独立字段「缺口 + 责任人 + 补齐日期」，三个都要有。