IMAP 迁移容易迅速暴露问题：邮件找不到、已发送文件夹分散、历史邮件一半在新服务商，一半在旧服务商。如果将它当作简单复制，就可能产生重复、漏掉切换时的新邮件，并花数小时确认重要邮箱没有丢失数据。
本指南介绍 IMAP 迁移的原理、转移范围、限制、常见故障和分阶段切换，适合管理一个或大量域名的运维人员。工具细节可在之后阅读我们的 imapsync 运维指南。如果同时重新规划托管模式，多域名邮箱托管指南涵盖管理方面。
什么是 IMAP 迁移？
IMAP 迁移通过 IMAP 连接源邮箱，读取邮件和文件夹，然后写入目标邮箱。它转移邮件内容，而非完整协作环境。许多意外来自对协议能力的误解。
在协议层面，这是使用 RFC 3501 所定义的邮件访问标准，在邮箱间转移数据。工具登录旧服务器，读取正文、邮件头、文件夹和标志，再登录新服务器追加数据。实际中，各服务商处理边界情况的方式不同，文件夹名也不同，用户还在持续修改源端。
因此，谨慎的迁移不应只依赖一次处理。它需要分阶段同步、切换窗口、DNS 准备和验证。协议用于访问邮件，并非完美的数据库复制，流程应尊重这一事实。
如果还要从头搭建邮件系统，企业邮箱指南提供整体思路。迁往 TrekMail 时，可参考 IMAP 迁移概览和从 Gmail 迁移的面板操作文档。
IMAP 迁移会转移哪些内容
IMAP 转移邮箱内容和部分状态，不包括用户所理解的所有“邮件相关内容”。邮件、文件夹及常用标志通常能迁移；联系人、日历、客户端签名和服务器过滤规则通常不能。
操作生产环境前应说明这一边界。用户可能认为整个工作环境会一起搬迁，但 CardDAV 联系人、CalDAV 日历和专有管理层规则不在 IMAP 范围内。
| 对象 | 通常可转移？ | 生产环境中的实际情况 |
|---|---|---|
| 邮件 | 是 | 正文、邮件头和附件通常可转移，损坏的 MIME 仍可能导入失败。 |
| 文件夹结构 | 是 | 层级通常可转移，但分隔符和特殊用途文件夹可能需要映射。 |
| 已读或未读状态 | 通常可以 | Seen 标志通常保留，对用户十分重要。 |
| 已回复或标记状态 | 通常可以 | 标准 IMAP 标志常能保留，客户端专有标志未必。 |
| 联系人 | 否 | 地址簿不属于 IMAP 迁移范围。 |
| 日历 | 否 | 需要单独导出或迁移路径。 |
| 规则和过滤器 | 否 | 服务器自动化通常需要重新建立。 |
| 签名 | 否 | 存于 Outlook、网页邮箱、移动应用或用户配置，而非 IMAP。 |
应正确界定“迁移成功”：不仅是任务结束，还包括用户周一能登录、找到历史邮件、发送新邮件，并看到完整的历史已发送内容。
旧 cPanel 环境经常有系统文件夹映射问题。切换前可以查看 TrekMail 的 cPanel 迁移指南，因为核心文件夹命名可能与新目标不同。
IMAP 迁移的底层工作方式
工具从一个服务器读取邮件，追加到另一个服务器，并跟踪各轮之间的状态。难点不仅是复制，更是识别已搬迁内容，让后续同步只处理缺少的数据，而不重新复制整个邮箱。
工具相当于双方的客户端：源端列出文件夹、枚举邮件并读取内容，目标端创建缺失文件夹并追加邮件。过程中尝试保留 Seen、Answered 和 Flagged。一些工具还在本地记录已复制项目，避免重复运行产生副本。
状态与 UID 和文件夹身份有关。IMAP 文件夹提供邮件 UID 和 UIDVALIDITY，以判断 UID 是否仍属于同一逻辑文件夹。迁移中若此值变化，工具可能认为文件夹是新的，重新复制已导入内容。常规服务器修复也可能因此大幅增加存储。
实际例子：周六预先同步时，源服务商重新建立索引，UIDVALIDITY 改变。下一轮增量同步将数千封邮件视为“新邮件”并再次导入。目标容量翻倍，用户看到的确实是重复档案。
还有其他特点：Gmail 标签让同一邮件出现在多个位置，服务商分别用点或斜线分隔层级，部分目标拒绝源端多年容忍的错误邮件。不看细节时，IMAP 迁移才显得简单。
许多工具按设计只追加数据。这有助于减少意外删除，但源端删除未必会从目标删除对应邮件。应提前纳入计划。
谨慎的 IMAP 迁移流程
分阶段流程包含初始同步、一轮或多轮增量同步，以及 MX 切换后的最终同步。用户可以继续使用旧系统，主要数据在后台转移。
不要只等一个迁移周末，应提前复制，降低切换前的风险，并尽量减少最终同步的剩余量。
1. 复制前先准备目标端
创建目标邮箱、检查存储余量，并确认平台准备就绪。在 TrekMail 中，域名和 DNS 应已配置，目标邮箱应已存在。先使用必需 DNS 记录文档，再进入迁移流程。
提前告知用户迁移范围、限制和暂停操作规则。计划大规模清理邮件时，应先核对保留要求，在首次同步前完成，而不是处理中途进行。
2. 执行初始 IMAP 迁移
目标是用户仍使用旧服务时搬走大部分数据。小邮箱可能一次完整复制，大规模环境可以使用日期筛选，或接受初轮耗时较长。
此时会发现连接限制、错误凭据、损坏文件夹和大型旧邮箱。应在这一阶段发现，而不是最后切换时。
3. 用户继续工作时同步增量
后续轮次抓取初轮之后到达的邮件，复制项目成为同步项目。工具比较源端与目标状态，导入看起来缺少的内容。
迁移周期较长时，应多次同步。每分钟变化的邮箱不应等到切换日才再次检查。
4. 切换前降低 DNS TTL
在迁移前约 24 小时降低 TTL，并考虑原缓存有效期。五分钟，即 300 秒，是常见参考值。只有旧缓存到期后，较短 TTL 才可能加快更新，不保证固定的 DNS 传播速度。跳过准备，可能延长新旧投递并存的阶段。
DNS 记录错误可能让邮件送错位置，请认真复核。
5. 修改 MX 并执行后续同步
新 MX 生效后，部分流量仍可能进入旧服务商。等待流量转向，再对旧源端执行增量同步。保留源端，检查后续投递，有新增邮件时再次同步，直到验证结束。
| 阶段 | 操作 | 用户影响 | 跳过的主要风险 |
|---|---|---|---|
| 初始同步 | 转移大部分历史邮件 | 通常较小 | 切换窗口过长 |
| 增量同步 | 补充初轮后的新邮件 | 通常较小 | 切换时数据缺口大 |
| 降低 TTL | 修改 MX 前降低 DNS TTL | 通常无直接影响 | 新旧路由并存时间长 |
| MX 切换 | 将新收件指向目标端 | 短暂协调登录和路由 | 邮件继续送达旧服务商 |
| 最终增量 | 导入切换后的迟到邮件 | 通常较小 | 缺少近期邮件 |
迁往 TrekMail 时，也应考虑长期运营模式：从用户计费、域名分散，转为套餐计费、共享存储和集中域名管理。根据源快照，Starter 每月 $3.50 起，付费套餐提供需信用卡的 14 天免费试用，Nano 持续免费且无需试用。请在 TrekMail 价格页面核对现行条件。
常见 IMAP 迁移故障
常见问题有文件夹映射错误、Gmail 重复、服务器限速、错误邮件，以及只凭绿色状态便认为成功。这些通常可以预见，应作为工作计划的一部分。
已发送文件夹陷阱
源端常使用 Sent Messages、Sent Mail 或 Sent，目标可能需要 Sent Items 或特殊用途标志。映射不对，用户打开新账户时可能看到空的已发送文件夹。
迁移后从目标发送新邮件。如果新邮件与导入的历史已发送内容不在同一文件夹，映射还未完成。
Gmail 标签重复
Gmail 并非以文件夹为核心。同一邮件可出现在 Inbox、自定义标签和 All Mail，IMAP 可能将其表现为多份可下载副本。盲目全迁可能增加容量并造成混乱。
根据 Google 文档，账户级 IMAP 设置影响暴露的内容，部分环境也有文件夹大小上限。应采用 Gmail 专用流程。源快照引用的 Gmail IMAP 会话约限 24 小时，对长期任务有影响；请核对现行说明。
限速与连接上限
线路带宽不等于实际吞吐。Microsoft 说明 Exchange Online 迁移有服务限流和资源健康限流等层次。因此，即使自有网络正常，任务仍可能变慢或停滞。
不要盲目提高并发，可能更快触发限制。使用能够退避和正确重试的工具，按服务器要求降低负载。
层级分隔符不一致
一家用点，另一家用斜线。如果工具未正确转换分隔符和特殊文件夹，目标可能变成扁平结构或出现重复顶层文件夹，破坏多年积累的组织方式。
错误的源邮件
旧服务器有时保留损坏邮件头、非法 MIME 或来自 2009 的异常字符集处理。现代目标可能拒绝这些邮件。这并非自动意味着整个迁移失败，但需要异常处理及数量核对。
如何验证 IMAP 迁移
核对邮件数量，抽查重要文件夹，测试已发送行为，并针对缺口重跑增量。容量和进度条都不够，应检查用户真正关心的文件夹。
不要因疲劳和工具的“完成”状态省略验证。完成可能只是进程结束，不代表结果正确。
- 比较源端和目标的 Inbox、Sent、Drafts、Archive 及几个大型自定义文件夹数量。
- 只有能解释时才接受小差异，例如损坏邮件或已知排除项目。
- 在获得授权的访问下，与用户确认历史和新发送邮件进入同一已发送文件夹。
- 按主题和发件人查找跨多个年份的已知邮件。
- 针对缺失文件夹重跑，而不是清空整个邮箱重来。
数量比容量更便于比较，不受存储后端和编码开销同样程度的影响。一个附件可能占不同磁盘空间，但一封邮件仍是一封邮件。
抽查应重视实际使用。如果高管主要使用 Inbox 和 Sent，不要把全部验证时间花在 Projects/2017，而漏掉关键文件夹。
一处文件夹不符，就针对它重跑。不要仓促删除整个目标；删除必须先保存数据并取得单独许可。修复范围通常比担忧的更小。
工具选择与运维取舍
选择取决于成本、控制和报告需求。没有完美工具，只有适合当前任务的取舍。
| 选项 | 适用对象 | 优势 | 限制 |
|---|---|---|---|
| imapsync | 系统管理员、MSP、定制任务 | 细致控制和可自动化操作 | 错误参数可能迅速造成问题 |
| SaaS 迁移平台 | 企业项目和重视报告的团队 | 图形界面、批次可见性、委派功能 | 用户费用可能侵蚀利润 |
| TrekMail 内置迁移 | 迁入 TrekMail | 平台内服务器端流程，源快照列为付费功能 | 面向 TrekMail 目标，不是任意平台间的通用编排 |
技术团队常以 imapsync 为参考，因为它提供细致控制，我们也发布了 imapsync 指南。对代理机构和 MSP，利润、设置时间及迁移与邮箱平台的整合程度也很重要。
区别在于：同时为目标和迁移工具按用户付费，或采用套餐邮箱托管，将迁移纳入接入流程，并使用共享存储而非固定席位配额。
TrekMail 在 IMAP 迁移中的作用
需要非用户计费的多域名托管、服务器端迁移和共享存储时，可以考虑 TrekMail。它仍是 IMAP；成本和复杂度是否减少，要根据需求和现行条件判断。
源快照介绍了自定义域名、IMAP 邮箱、catch-all、转发、按套餐提供 BYO SMTP 或包含 SMTP，以及高阶 API。迁移工具在付费套餐内置。TrekMail 被描述为只支持 IMAP、不支持 POP3，适合服务器端共享状态。请核对当前功能。
源快照列出的价格为 Free $0、Starter 每月 $3.50、Pro 每月 $10、Agency 每月 $23.25，Enterprise 定制报价。付费套餐有需信用卡的 14 天试用，Nano 无需卡或试用。年付被描述为优惠 20%；请确认现行条件。
运营方面，共享存储可按需求分配，多域名控制能集中客户环境，集成迁移可能减少额外接口及凭据交接。不过，这些不能替代访问权限控制。
如果 Google Workspace 或 Microsoft 365 对仅用邮箱的用户太贵，可以比较专门邮件平台。评估 TrekMail 的功能和总成本是否满足实际需求。
IMAP 迁移常见问题
问题主要围绕范围、中断、重复和切换。分阶段并验证，可以降低风险，但不会消除协议边界。
IMAP 迁移会造成停机吗？
分阶段迁移可能减少中断，但不保证零停机。主要数据在用户继续使用源端时转移，MX 切换后的同步抓取迟到邮件。必要时重复，直到完成验证。
能迁移联系人和日历吗？
不能。IMAP 迁移邮件，其他内容需要单独导出、同步或手动重建。
为什么会产生重复？
常见原因是源状态改变、Gmail 多次暴露同一邮件，或重跑未正确跳过重复。通常涉及状态跟踪问题。
迁移需要多久？
取决于邮箱大小、服务器限制、限速和并发。大邮箱可能需要数天，应据此规划，而不是赌一个周末。
怎样安排切换更稳妥？
初始同步、增量同步、降低 TTL、修改 MX、后续增量和验证。平稳而可控的过程更合适。
结论
IMAP 迁移不是魔法，而是两个系统之间的有状态传输；它们的文件夹、标志、限制和时间安排可能不同。尊重这些事实，流程就更易管理，否则后续还要解释重复和历史已发送缺失。
流程清楚：提前复制、执行增量、降低 TTL、映射特殊文件夹，并按数量验证。如果需要共享存储、固定费用多域名托管和内置迁移，可按需求和当前条件认真评估 TrekMail。
