我们都知道这种情况：解决方案A托管在服务器1上，但是服务器1的可靠性出于某些原因可能存在一些问题。这样服务器会遭遇故障，更新延迟或者需要虚拟化来保存资源--这只是迁移到服务器2的众多合理原因中的几种。用户要面临的挑战是即要完成服务器迁移又不会损失解决方案A所需的功能和资源或者引发过多的宕机从而招致用户对IT部门的投诉。
因此当你小心谨慎的实施迁移的过程又不愿遭受损失整个系统的风险，那么你该如何应对这种两难的状况呢？你又该如何满足用户对零宕机的苛刻要求呢？以下是帮助你规避这些风险的五个提示。
了解系统之间的从属性
虽然IT员工可能不愿意承认这一点，但某些员工可能确实不完全了解一项解决方案在既定的迁移战略中是如何工作的。以Exchange Server为例。更改为Exchange Server可以用几种方式完成，从单个用户迁移简单的电子邮箱转移的操作到从整个服务器转移到新的域这种第三方解决方案（如果必要的话）都涵盖在内。
面临的挑战是这种迁移会对诸如Good Technologies服务，黑莓企业级服务器，Lync和移动技术套装向Exchange (Outlook Web Access/App, Outlook Anywhere和ActiveSync)本地迁移的系统产生影响。与在电子邮箱服务器迁移过程中将这些生态系统解决方案考虑在内的方法不同，你可以非常快速的导出所有的移动用户。但是无法全面了解所有的外围系统，而你的目标迁移系统可能会依赖这些外围系统或者相互依赖，从而让你陷入真实迁移的梦魇。
#p#
什么是必须要进行迁移的
一套解决方案是由涉及一个或者多个服务器或者硬件资源的一个或者多个组件所组成的。在迁移过程中正确的步骤能确保你首先了解解决方案的工作原理和迁移部分在开始实际迁移前会占到所迁移系统中的比例。传真服务器就是这种解决方案类型的***示例，因为要保证操作正确许多企业都需要物理传真卡。如果你没有确保传真卡与你试图迁移的新硬件/虚拟化平台相兼容的话，那么再好的迁移计划也会大打折扣。
#p#
什么应该被迁移
一旦你计算出必须从目前平台迁移出去的组件，你应该全面分析你可能需要迁移或者不需要迁移的组件。总会有一些系统组件是没必要迁移到新平台上，但是为了将宕机的可能性和复杂性降到***可能又有必要迁移过去。
举例来说，Windows系统状态信息可能需要适合的工具从一个硬件平台迁移到另一个硬件平台。如果这种信息可以被迁移过去，那么新服务器配置的复杂性就能被大大降低，至少从Windows系统和软件的角度来说是这样的。
#p#
设定期望值
用户都希望实现无宕机的迁移。但是不幸的事实是这种零宕机的梦想在真实的迁移世界中通常是不可能的。即使在实施物理迁移时没有出现可见的宕机（比如在Exchange或者Notes中迁移电子邮箱），你仍然需要给你的员工一些喘息的空间来应对意料之外的突发状况。迁移系统状态信息和二进位，认真规划和在迁移之前提前做好每一件事情能让宕机的可能性降到***。不过消除所有主要硬件迁移过程当中的宕机只是种期许，可能很难实现。
设定合理的宕机数量，确保从IT员工到用户每一个人都知道什么时候可能发生宕机，宕机的时间会持续多久。如果这种宕机无法被用户所接受，要解释清楚为什么必须这么做的原因以及一意孤行给系统可能导致的灾难性后果。
#p#
获得你需要的工具
迁移经常会由于不了解细则导致意外的结果。一个例子：许多从本地物理机迁移到虚拟机的工具需要数据在迁移过程中保持静止的状态（仅供数据库管理员处理使用）。对于SQL或者诸如此类的服务器，这就意味着数据库在迁移过程中必须保证离线状态，因为在此过程中会面临数据丢失的主要风险。物理机向虚拟机迁移的工具还是一种从物理服务器到虚拟机的单向迁移。这是对操作的一种限制。如果你的迁移只是从物理机到虚拟机是可行的，如果你试图向另一台物理机迁移就是没有帮助的。如果在迁移后才发现这个问题也是于事无补的，应用软件在新的环境中就无法达到你预期的状态。
按照你的需求选择工具库--典型的做法是本地工具和第三方工具相结合，这样能确保你可以安全的执行迁移，按照计划实施。将这五个提示结合使用，可以确保不会遗漏掉那一点，你可以在实施迁移时以最小限度的宕机迁移到新平台上。
【编辑推荐】
