从Exchange（本地）到Office 365（云）迁移电子邮件似乎是一个非常简单和直接的过程，当你知道你在做什么，这是一个有条不紊的过程。然而，在过去的2 - 3年，我们一直在做的Office 365的迁移，这是惊人的时候，我们被调用到“修复的东西”的数量，其他一些移民问题专家确实已经摇我们我们头上不知道他们在想什么...
对于这篇博客，我问过埃德·克劳利，微软的Exchange MVP，Office 365的迁移专家，融合计算（CCO）顾问公司，就他在Office 365的迁移方面所见过和我一起协作，在于他从字面上迁移数成千上万的邮箱，有时有5-6迁移的同时回事。当谈到了解Office 365的迁移，最好围绕Ed的一个！
首先，当这样做的权利，一个Office 365的迁移是像任何其他迁移，有规划，要完成的需求，而必须配置的先决条件，即必须制定出来，然后最终只选择邮箱和用户迁移怪癖到Office 365虽然爱德过去曾评论到我很多次，“有没有这样的事，作为一个标准或简单的迁移到Office 365。”每个组织都有东西可以迁移，可能包括在创建一个问题：
- 现有的Exchange环境中有腐败和稳定性问题 - 那些需要在迁移过程中摸索出或只是帐户中扣除
- 没有停机时间允许的 - 我们会偶尔遇到单位部门，员工（高管频繁），可以不“倒”在电子邮件（曾经），再次，常见和最佳实践发展到地址
- 网络连接速度慢 - 这会降低Exchange电子邮件最多的Office 365的上传，但有办法的地址，在内容的“分期”的邮件迁移的条款，这样的初始扫描副本邮件最多的Office 365在几天/周，随后的邮件扫描副本在任何新的消息/更改，然后最终的最终是扫任何迁移最近的邮箱中的邮件和裁员
- 强烈的安全性 - 我们已经走进了那里的安全是如此取缔，许多微软默认的工具和流程迁移到Office 365有机构的安全指导方针内进行调整，以适应机构单位。还没有找到阻断剂，但有什么能需要2小时即可服用2-3天（如果你知道你在做什么相对安全）一些组织的安全部门的指导方针，只是工作
- 错误配置的防火墙，代理设备和CAS服务器 - 的必然结果最后一点，边界保护多数民众赞成配置错误会损坏Exchange Web服务，自动发现和SMTP流量到混合配置根本不起作用在所有或以某种方式被打破
- 旧的Outlook客户端 - 这样的Office 365已经滚动了什么是支持用户的需求，目前它是2008年的Mac与SP3或更高版本的Outlook 2007 SP3或Windows系统高，和Entourage。但是，我们遇到了他们在那里的业务流程建立在Office 2003和不能过去的2003升级的单位，所以我们想出办法来获得到Office 365，但仍然解决这些旧旧的客户终端系统。此外，企业常常会忘记，他们必须与老客户部署微软在线登录助手。一般来说，最好之前或用户升级到Outlook 2013中时，他们的邮箱移动为最佳的用户体验。
- 法律和法规遵从策略 - 移动电子邮件“云”是新的组织，并有总有大量的关于解决安全，尤其是秉承像欧盟数据保护指令，或HIPAA等法规政策的问题。我认为现在我们已经听到了他们所有，并有解决这些问题，而是事，来了和我们熟悉的寻址
- 租赁名字不详 - 一家公司的员工会经常获取Office 365的试用，并忘掉它。当谈到时间获得生产租约，所需的租户名称（companyname.onmicrosoft.com）取（用与前一阵子在审判丢弃）和微软在线支持是没有多大帮助，在获得该租赁名字后面
- 没有管理方法 - 我们谁使用目录同步，但没有内部部署与更新和创建新用户，组和联系人Exchange服务器辅助机构。使用ADSI编辑不负责管理收件人属性的可持续方法
- 一些古怪的第三方插件来交换 - 有常用的是一些奇怪的传真软件，语音软件，集成工具到其他服务器应用程序，电子邮件归档坐在Enterprise Vault的或EMS或类似的，同样，这拿出所有常用的东西，只是要识别项目（S）和他们的工作将迁移计划
因此，这些都是上来，必须解决比较常见的事情。同样，已经做了很多Office 365的迁移，我们知道会发生这些事情，我们问他们，我们解决这些问题，然后我们绘制出我们的计划有一个成功迁移到Office 365。
但是，对于一些比较明显的怪癖，我们已经在从在需要我们的援助进度迁移“修复”被拉开的：
- SLOW邮箱迁移：我们碰到的地方邮箱迁移正在运行非常缓慢的节奏迁移的少数（3-4个邮箱一个晚上，而不是50-300大多数单位部门看到）。许多博客文章人们对互联网的地方就微软和单位部门的指责等待微软“解决性能问题”读的，但我们经常发现防火墙和代理服务器，安全设置的奇怪的形状，和迁移服务器的问题是罪魁祸首。而如果没有适当的计划和测试事前，多次组织都坐在自己的“迁徙的周末”，以实现有一个问题，不必测试几十个邮箱的流动事先的中间。
- 在实验室中运行良好：另一个类似的问题是，当单位部门设置一个测试实验室和测试Office 365帐户，做测试的一切，它工作得很好，所以后来他们做了很大的割接周末才发现与大生产割接问题。还有，我们已经从这些情况中发现的最佳实践了很多，一个实验室的网络连接多次上有比生产互联网连接流量较少;或测试邮箱有没有邮件损坏，而真实的邮箱可能已经嵌入旧的Exchange数据库中的腐败;或实验室服务器没有层和安全政策和代理的多层应用到他们生产的实际托管服务器对他们。实验室测试往往没有解决的有经验的结果究竟会在生产中去的割接的一天
- 电子邮件归档：这是多么惊人的许多电子邮件归档厂商是机构单位已使用多年有一种让你的邮件了他们的档案中没有一种方法......多年来，你一直在馅电子邮件到档案馆，在Exchange创建存根和归档附件，移动档案到基于云的解决方案，但现在你想摆脱归档解决方案，只是把你所有的电子邮件（和档案）到Office 365（是该办事处365为您提供几乎无限的归档存储以及大量的电子发现，依法保留工具），你发现你不能让你的档案从你现有的归档产品。虽然有些单位部门已经迁移他们的邮箱到Office 365，但保留其旧档案本地与他们现有的供应商，这些归档供应商解决方案的成本和复杂性归档与许多这些解决方案使得它的原因之一得到他们的摆脱和移动都到Office 365！在一个案例中，归档供应商没有工具迁移的东西了他们的档案，所以我们只好直接到内容的存储系统和提取BLOB和重建档案，这是非常成功的，但在每个人的嘴里留下不好的味道当归档厂商真的把枪给顾客的头说，他们必须保持与此供应商永远档案...（幸运的是，我们的解决办法，没有那么...）
- 糟糕的建议 - 一个组织事先Office 365的咨询顾问，而不在于它是需要安装Exchange 2013服务器作为混合服务器时，他们已经有了一个完美的工作冗余负载平衡的Exchange 2010 SP3 CAS阵列疑问坚持。进一步，他们不得不在他们的不同位点安装混合服务器从其中服务器被正常激活，导致未达最佳被配置的网络明智非冗余混合配置。雪上加霜的是，这些网址被配置不正确。
所以底线，Office 365个的迁移不是简单俗套的过程，有人可以只是“翼它”在周末，但把它做好，有人在Exchange，Office 365中，档案，安全，DNS，存储根深蒂固的专业知识，防火墙，代理服务器，网络，自动发现，活动目录，AD FS，目录同步，PowerShell中，客户端应用程序包装，推出的政策端点客户端，移动设备管理技术，ActiveSync策略的专业知识等。
有人知道这一点，并有更多的东西短，迁移能够大迁移周末的中间过程中停下来，很多次，然后有人需要解开做什么，有可能从头开始重做的东西，并得到处理展望未来，因为它可能应该已经摆在首位完成。
这里的想法一把，希望这将帮助你识别的东西提前迁移到Office 365和被更好的方法制备的！