从 Superhuman、Notion、Slack 迁到 Macro：哪些数据能带过来，哪些只能重建

换协作工具最怕的不是新工具不好用，是搬家搬到一半发现有东西卡在旧系统里出不来。评估 Macro 的时候，真正该先问清楚的是三件事：哪些东西压根不用搬、哪些能靠自动化搬、哪些只能人工重建或者干脆放弃。

Macro 官方文档对这件事的态度比较克制，开篇就写明「你不必一次性全部搬过来」，推荐的顺序是先把旧工具连上，确认没有东西丢失，等你准备好了再让 agent 做完整迁移。文档还提到一种长期形态：如果你只想用 Macro 的邮件加任务，或者只用文档加文件，其它工具可以通过 MCP 一直连着。

下面按数据类型拆，每一类都对应官方文档里写明的具体做法。

邮件：没有迁移这件事

这是最容易被想复杂的一块。Macro 不是邮件服务器，它只是一个邮件客户端，同步你现有的 Gmail 或 Google Workspace 账号，邮件本身始终留在 Gmail。所以从 Superhuman 换过来时，官方明确写的是「两边都只是 Gmail 之上的客户端，任何一个方向都不存在迁移」，你的邮件、标签、历史记录在连上账号那一刻就都在。

对应的动作只有两步：在注册时（或者之后在 Settings 里）连接 Gmail 或 Google Workspace 账号，然后就结束了。文档还特意说了一句，过渡期你可以两边同时跑，或者一直留着 Superhuman。

多账号是个值得注意的差别。官方说明 Macro 支持在 Settings 里添加多个 Gmail 或 Google Workspace 账号，它们汇入同一个统一收件箱，写信时再选用哪个地址发出。邮箱接入的完整前提条件可以看 Macro 邮箱接入怎么配。

但这里有个硬缺口：Outlook 和自定义 IMAP/SMTP，官方标注为计划中，目前尚未提供。如果你的团队主力邮箱不在 Google 体系里，那么上面这套「不用迁移」的逻辑对你不成立，得先等这块落地。这个限制的影响面在 Macro 对 Outlook 和 IMAP 的支持现状 里说得更细。

文档：靠 MCP 连接器加 agent 重建

Notion 和 ClickUp Docs 这两块，官方给的路径是一样的，因为两边都是 markdown-native，所以导入过程被形容为「干净」。步骤是：

1. 在 Settings → Connectors 里连接 Notion（或 ClickUp）。
2. 开一个 agent 会话，让它执行导入。

官方文档给出的示例指令是这样的：

Import my Notion docs from the "Engineering" workspace as Macro docs.
Keep the folder structure and skip anything archived.

ClickUp 那边的示例是同一套句式，只是把 workspace 换成 space：

Import my ClickUp Docs from the "Engineering" space as Macro docs.
Keep the folder structure and skip anything archived.

agent 通过连接器读取页面，再在 Macro 里重建成文档。注意这不是数据库级别的字段搬运，而是内容重建，所以官方专门提醒：遇到 Notion 里那些结构化数据库，你得自己先判断每一个到底本质上是任务、是 CRM 记录，还是一篇带属性（properties）的文档，然后按判断结果让 agent 分别导入。

还有一个不那么显眼但很实用的选项：Notion 的 MCP 连接可以无限期保留，让 agent 随时引用历史内容。官方在这里的原话立场是「别觉得非得把所有东西都迁过来，我们自己更喜欢从干净的一页开始」——这是官方文档的说法，采不采纳看你团队的历史包袱有多重。

任务：多数团队只搬未完结的部分

Linear 和 ClickUp 的任务迁移，官方给的建议一致：大部分团队只重建当前在做的工作，已完成的 issue 很少值得搬。真要保留历史，做法还是在 Settings → Connectors 里连上，让 agent 把未关闭的 issue 带过来。

任务这块有个字段层面的取舍要提前想清楚。官方说明 Macro Tasks 在设计上参考了 Linear（状态、优先级、负责人、键盘优先，以及一个 GitHub 集成：从任务复制分支名，随着你建分支、开 PR、合并，任务会依次流转到 In Progress、In Review、Done）。但字段默认是精简的，故事点、工作量这类通过 properties 提供，官方的建议是「尽量保持轻量」。Linear 里那套深度工作流配置（cycles、triage、自定义流程），官方表格里标为 Linear 有、Macro 是「默认最简，需要时用 properties」。

也就是说，如果你现在的看板重度依赖自定义状态和流程编排，迁移不只是搬数据，还得同时接受一次流程简化。这不是数据能不能带过来的问题，是要不要带的问题。

GitHub 集成本身是单独配置的：在 Settings 的 Account 下关联账号即可。

频道：只能新建，且有一块搬不走

Slack 这边最直白：官方给的切换步骤里没有任何历史消息导入的说法，只有三步——按团队或项目建频道、按邮箱加人（对方还没有 Macro 账号也能被加进来）、讨论时用 @mention 分享文档和任务。

Slack Connect 那种和客户的外部频道，官方表格里明确写的对应方案是「把 Slack 作为 MCP 连接器保留着」，也就是不迁移。文档还描述了一种常见的过渡形态：内部沟通跑在 Macro，Slack 只留给外部频道。历史归档同理，靠连接器让 agent 能搜到，而不是搬进来。

频道在 Macro 里还兼着权限的职责：在频道里 @mention 一个文档或任务，频道成员会自动获得访问权，权限随人员加入或离开自动跟随。这一层在把外部协作留在 Slack 时是拿不到的，评估过渡期方案时要算进去。成员和权限的具体规则见 Macro 团队成员与权限。

文件和其它工具

文件这块官方的说法是「基本自己就迁过来了」：邮件附件会被自动提取进文件存储，你拖进频道或文档的任何东西都会被导入并可搜索。

至于清单之外的工具，官方给的是一条通用路径：任何带 MCP server 的工具都能在 Settings → Connectors 下连接，从而对 agent 可读。这条路径同时是迁移手段（让 agent 把内容复制过来）和长期桥接（对那些你打算继续用的工具）。

一张表：搬还是不搬

把上面的结论压成一张对照表，方便你先定策略再动手。

数据类型	官方给的处理方式	是否需要真正迁移
Gmail / Google Workspace 邮件	连接账号即同步，邮件留在 Gmail	不需要
Outlook / 自定义 IMAP/SMTP 邮箱	官方标注为计划中，目前尚未提供	当前无路径
Notion 文档	Connectors 连上，agent 按指令重建为 Macro 文档	需要，可自动化
Notion 结构化数据库	先人工判断属于任务/CRM/带属性的文档，再分别导入	需要，先做映射决策
ClickUp Docs	同 Notion，markdown-native，agent 重建	需要，可自动化
Linear / ClickUp 任务	多数团队只重建未完结的；要历史则连连接器让 agent 搬	部分迁移
Slack 历史消息	无导入路径，保留 Slack 作为 MCP 连接器供 agent 搜索	不迁移
Slack Connect 外部频道	官方方案是保留 Slack 连接器	不迁移
邮件附件与拖入的文件	自动提取进文件存储，可搜索	自动
其它带 MCP server 的工具	Settings → Connectors 连接，可作迁移通道或长期桥接	看需求

官方拿别家做参照的部分，怎么读

这份迁移文档里有相当一部分内容是官方自己在做产品对照，写法上要区分开：哪些是可核查的机制差异，哪些是官方的立场表述。

机制层面的并列比较硬，比如「两边都建在 Gmail 上所以不用迁移」「j / k / e 这几个整理快捷键沿用不变」「ClickUp 需要你自己配置 spaces、folders、lists、自定义状态」，这些直接影响你迁移时要做什么。

立场层面的就得标清楚来源。比如官方称数据库是做正经业务软件时「错误的抽象层级」，并举了自己上一家公司规模扩大后从 Notion 迁到 HubSpot、Linear 的经历——这是官方文档的说法，是他们做产品选择的理由陈述，不构成对你的场景的结论。同样，官方说 Macro 里任务、CRM、邮件、频道、文件各自是专门构建的 block，共享同一套数据模型和同一个搜索索引，agent 因此能把这些当作一份上下文来读，而不是通过有速率限制的 API 逐页翻——这段里前半句是架构描述，后半句对比是官方的表述方式。

实际迁移时你只需要盯住一件事：官方也承认，换过来意味着放弃 Notion 那种自由的数据库灵活性，取而代之的是内置 block 上的 properties。这个交换划不划算，取决于你现有的数据库有多少是真在跑业务，多少只是没人清理的历史。

什么时候先别急着搬

有几种情况，按现有文档看不适合现在就动。

主力邮箱不在 Google 体系。Outlook 和自定义 IMAP/SMTP 官方标注为计划中、目前尚未提供，而统一收件箱恰恰是 Macro 把邮件、频道消息、任务分派、@mention 收拢到一处的地基，邮箱接不进来，这套逻辑就断了。

和客户的沟通重度依赖 Slack Connect。官方方案是继续保留 Slack，那你实际上是在维护两套沟通面，得先想清楚谁看哪边、外部信息怎么回流。

任务流程重度定制。cycles、triage、自定义流程这些，官方表格里 Macro 一侧写的是默认最简、需要时用 properties，迁移会连带一次流程改造。

还有一些文档没有回答的问题：历史消息和已关闭任务由 agent 搬运时的完整度如何、导入过程出错怎么回滚、大体量文档导入需要多久，这些官方迁移文档都没有写，不要靠猜。想先低成本摸清楚这套工作流长什么样，可以从 Macro 十五分钟上手 那条路径起步，等确认能跑通再谈整体搬家。

一个比较稳的推进顺序是：先连 Gmail（这步不产生迁移风险），再把旧工具都挂成 MCP 连接器让 agent 能读到，然后只重建当前在做的任务和频道，文档按需分批导入，历史的部分先留在原地。官方推荐的也正是这个顺序，它的好处是每一步都可逆——在你真正决定关掉旧工具之前，没有任何数据只存在于一个地方。

延伸阅读

• 从头读起：Macro 是什么：邮件、任务、文档、CRM 共用一个双向数据库的开源工作区
• 本专题共 40 篇，完整分组目录见专题页
• “Macro 官方 Agent 配方拆解：八段提示词各自解决什么问题”
• 从 2026 年 1—5 月的 changelog 看 Macro 在往哪走：AI 工具、通话与团队化

---

本文依据 Macro 官方仓库（github.com/macro-inc/macro，AGPL-3.0 协议）的 apps/docs/ 产品文档、 MCP 工具参考与自托管说明整理，核对日 2026-08-17。 我们没有注册或运行过 Macro，因此不涉及界面外观与操作手感； 官方标注为计划中的能力文中已如实标明，不代表当前可用。 价格与额度以官网 macro.com 最新页面为准；许可证相关问题请咨询专业人士并以官方许可证原文为准。