如果你了解如何将MS Exchange的邮箱迁移到Office 365上，相信你一定认同这是非常简单的过程。当然当你在Exchange服务器之间迁移邮箱的时候你依然会遇到问题。
为了Office 365的迁移，你需要事先做好规划好配置然后决定迁移的邮箱用户。需要指出的是对于O365的迁移并没有一个标准或者通用的过程。
任何一个组织在迁移过程中都可能遇到这样那样的问题。这些问题大致可以归类为：
1. Exchange环境的错误：整个Exchange服务器环境（包括活动目录）被破坏，此类问题需要今早解决。
2. 没有变更窗口：有时候，你会遇到一些组织（主要是管理层）一刻不能停止邮件服务。
3. 糟糕的网络状态：这个问题会减慢Exchange邮箱上传到O365的速度。最佳解决办法是设置“候场过程”。在“候场区”中的邮箱会慢慢地自动地上传到O365。
4. 安全要求：许多组织对网络安全有严苛标准，以致于许多默认或内置的迁移工具必须根据其安全标准进行定制化的调整。
5. 防火墙、代理设备及CAS服务器的配置错误：这类边界访问设备的配置问题会导致EWS（Exchange Web Services）的不可用。
6. 不支持早期的Outlook：目前O365的客户端要求必须是Outlook 2007 SP3以上；如果是Entourage服务器则要求Mac 2008 sp3以上版本。
7. 合规性要求：将用户邮箱迁移到云端对于传统内部IT来说是新鲜的尝试，所以对于安全和合规性的质疑从来没有间断过。
对于上述各种问题，就我个人做过的迁移项目的经验，有以下解决办法：
a. 邮箱迁移太慢：很多用户抱怨的问题，比方说你要迁移50-300个邮箱，但发现进展很慢，每天晚上只能迁4-5个。你可能首先想到的是网络的问题。但实际原因其实是多种多样的，比如说防火墙配置问题，安全级别设置问题或者是源服务器的问题，总之在正式迁移之前做好测试以避免此类问题发生。
b. 与实验环境测试结果不符：有些组织为了迁移会特地搭建实验环境，然后发现实验环境下一切OK，但实际环境却问题不断。其实这些问题是实验环境下暴露不了的，例如：实验环境的数据流量远不如真实环境的流量；测试邮箱远不如实际邮箱容易被破坏；实验服务器没有安全层而生产服务器部署有各种各样的安全策略。另外实验环境很多时候模拟不出生产环境的实际数据。
c. 邮件归档：许多组织有自己的邮件归档服务商，但没有一家可以从归档的茫茫邮件中将某封邮件再找出来。因为长久以来，你一直在往归档中塞邮件，建立邮件服务器与归档间的界限，再将归档移至公有云。如果你讨厌这么冗长的步骤，你只要将邮件（或归档）移至O365，他能提供给你虚拟的无上限的归档空间以及便捷的eDiscovery的查找服务。
最后我想说从内部Exchange服务器往O365的迁移需要考虑上述所有的方方面面并且最好在专家指导下进行。