一，了解系统之间的从属性
虽然IT员工可能不愿意承认这一点，但某些员工可能确实不完全了解一项解决方案在既定的迁移战略中是如何工作的。以ExchangeServer为例。更改为ExchangeServer可以用几种方式完成，从单个用户迁移简单的电子邮箱转移的操作到从整个服务器转移到新的域这种第三方解决方案(如果必要的话)都涵盖在内。
面临的挑战是这种迁移会对诸如GoodTechnologies服务，黑莓企业级服务器，Lync和移动技术套装向Exchange(OutlookWebAccess/App,OutlookAnywhere和ActiveSync)本地迁移的系统产生影响。与在电子邮箱服务器迁移过程中将这些生态系统解决方案考虑在内的方法不同，你可以非常快速的导出所有的移动用户。但是无法全面了解所有的外围系统，而你的目标迁移系统可能会依赖这些外围系统或者相互依赖，从而让你陷入真实迁移的梦魇。
二，知道什么是必须要进行迁移的
一套解决方案是由涉及一个或者多个服务器或者硬件资源的一个或者多个组件所组成的。在迁移过程中正确的步骤能确保你首先了解解决方案的工作原理和迁移部分在开始实际迁移前会占到所迁移系统中的比例。传真服务器就是这种解决方案类型的最好示例，因为要保证操作正确许多企业都需要物理传真卡。如果你没有确保传真卡与你试图迁移的新硬件/虚拟化平台相兼容的话，那么再好的迁移计划也会大打折扣。
三，了解什么应该被迁移
一旦你计算出必须从目前平台迁移出去的组件，你应该全面分析你可能需要迁移或者不需要迁移的组件。总会有一些系统组件是没必要迁移到新平台上，但是为了将宕机的可能性和复杂性降到最低可能又有必要迁移过去。
举例来说，Windows系统状态信息可能需要适合的工具从一个硬件平台迁移到另一个硬件平台。如果这种信息可以被迁移过去，那么新服务器配置的复杂性就能被大大降低，至少从Windows系统和软件的角度来说是这样的。
四，设定期望值并坚持目标
用户都希望实现无宕机的迁移。但是不幸的事实是这种零宕机的梦想在真实的迁移世界中通常是不可能的。即使在实施物理迁移时没有出现可见的宕机(比如在Exchange或者Notes中迁移电子邮箱)，你仍然需要给你的员工一些喘息的空间来应对意料之外的突发状况。迁移系统状态信息和二进位，认真规划和在迁移之前提前做好每一件事情能让宕机的可能性降到最低。不过消除所有主要硬件迁移过程当中的宕机只是种期许，可能很难实现。
设定合理的宕机数量，确保从IT员工到用户每一个人都知道什么时候可能发生宕机，宕机的时间会持续多久。如果这种宕机无法被用户所接受，要解释清楚为什么必须这么做的原因以及一意孤行给系统可能导致的灾难性后果。
