微软租户到租户迁移编排器

多年来，我听过很多微软关于租户到租户迁移的演讲。每一次，当微软意识到将信息从一个微软365租户迁移到另一个租户的复杂性时，他们的兴趣就消退了。这不仅仅是构建迁移功能的工程工作。毕竟，微软可能比任何其他公司都迁移了更多的邮箱到云端以及在云端之间迁移。问题似乎出在支持上。更确切地说，是微软内部缺乏承担那些可能变得非常棘手和麻烦的迁移项目责任的意愿。

微软似乎很乐意将T2T迁移涉及的困难留给独立软件供应商，其中许多如Quest、BitTitan、ShareGate和AvePoint等，已经在T2T工具和技术上工作了多年，并在这方面拥有丰富的经验。事实上，微软的T2T迁移架构模型（2021年版）就强调了使用第三方工具来移动数据。但现在我们有了迁移编排器（预览版），于2025年12月16日在MC1198079中宣布。

迁移编排器可以移动邮箱、OneDrive for Business账户和Teams聊天记录。邮箱迁移功能已存在一段时间，可以处理主邮箱和存档邮箱。

许可

独立软件供应商对他们的T2T解决方案收费，微软也不例外。参与迁移的用户账户需要微软365 E3或E5许可证，并且每个账户需要一个跨租户用户数据迁移许可证才能移动邮箱和/或OneDrive信息。

由PowerShell驱动的迁移

这可能让一些人感到惊讶，但迁移编排器是由一组通过Microsoft Graph PowerShell SDK cmdlet（2.33版）访问的Graph API控制的，例如New-MgBetaCrossTenantMigrationJob（提交新的迁移作业进行处理）。

这个实现方式一点也不让我惊讶。T2T迁移过程通常是经过精心规划和执行的，前期需要做大量工作，例如必须在运行任何迁移作业之前完成的跨租户身份映射过程。有一个用户界面固然很好，但鉴于T2T迁移并非微软365的核心功能，通过PowerShell运行一切是合理的。

缺点

像任何迁移一样，存在一些限制。如果邮箱受到任何类型的保留，微软不会移动它们，因此可能需要做一些前期工作来确定要移动的邮箱是否存在任何保留，以及是否可以在不丢失数据的情况下解除这些保留。将邮箱从电子数据展示保留中释放通常是最大的难题，因为邮箱因电子数据展示而被保留这一事实很好地表明了一些正在进行的调查需要这些信息。

另一个问题是只有IPM（电子邮件客户端可见的数据）会被移动。任何存储在非IPM文件夹中的数据（如Teams合规记录）都会被留下。这符合“合规数据属于生成记录的租户”这一总体立场。

迁移编排器不包含处理受敏感度标签保护的消息和文档的方法。根据敏感度标签的工作方式，项目离开源租户之前必须移除源租户的标签。微软在一篇相当老的博客（2019年）中处理了这个问题。然而，独立软件供应商已经找到了迁移受保护内容的方法，这可能是一个需要考虑的重要点，具体取决于您的租户如何使用敏感度标签。

微软的巨大优势

迁移编排器最大的优势在于其处理的数据始终保留在微软数据中心内。无需将数据移出租户到中间位置，然后再移回目标租户。考虑到邮箱、OneDrive账户和Teams聊天中积累的信息量，迁移速度非常重要，而当信息保持在微软内部时，速度是最快的。

独立软件供应商会讨厌微软拥有速度优势，但他们会争辩说，分阶段和受控的迁移可以实现同样的目标，尽管速度较慢。独立软件供应商还会指出他们处理不同使用场景的能力，例如受保护的文档。而且独立软件供应商会乐于看到微软将T2T确立为租户拆分、合并和兼并的有效方法，所以大家都会很高兴。