我们都晓得那种情况：处理计划A托管在办事器1上，但是办事器1的可靠性出于某些原因可能存在一些问题。如许办事器会遭遇毛病，更新延迟或者需要虚拟化来保留资本--那只是迁徙到办事器2的浩瀚合理原因中的几种。用户要面对的挑战是即要完成办事器迁徙又不会丧失处理计划A所需的功用和资本或者引发过多的宕机从而招致用户对IT部分的赞扬。
因而当你小心隆重的施行迁徙的过程又不肯遭受丧失整个系统的风险，那么你该若何应对那种两难的情况呢？你又该若何满足用户对零宕机的苛刻要求呢？以下是帮忙你躲避那些风险的五个提醒。
提醒1：领会系统之间的隶属性
固然IT员工可能不肯意认可那一点，但某些员工可能确实不完全领会一项处理计划在既定的迁徙战略中是若何工做的。
以Exchange Server为例。更改为Exchange Server能够用几种体例完成，从单个用户迁徙简单的电子邮箱转移的操做到从整个办事器转移到新的域那种第三方处理计划(若是需要的话)都涵盖在内。
面对的挑战是那种迁徙会对诸如Good Technologies办事，黑莓企业级办事器，Lync和挪动手艺套拆向Exchange (Outlook Web Access/App, Outlook Anywhere和ActiveSync)当地迁徙的系统产生影响。
与在电子邮箱办事器迁徙过程中将那些生态系统处理计划考虑在内的办法差别，你能够十分快速的导出所有的挪动用户。但是无法全面领会所有的外围系统，而你的目的迁徙系统可能会依靠那些外围系统或者彼此依靠，从而让你陷入实在迁徙的梦魇。
提醒2：晓得什么是必需要停止迁徙的
一套处理计划是由涉及一个或者多个办事器或者硬件资本的一个或者多个组件所构成的。
在迁徙过程中准确的步调能确保你起首领会处理计划的工做原理和迁徙部门在起头现实迁徙前会占到所迁徙系统中的比例。传实办事器就是那种处理计划类型的更好示例，因为要包管操做准确许多企业都需要物理传实卡。若是你没有确保传实卡与你筹算迁徙的新硬件/虚拟化平台相兼容的话，那么再好的迁徙方案也会大打折扣。
提醒3：领会什么应该被迁徙
一旦你计算出必需从目前平台迁徙进来的组件，你应该全面阐发你可能需要迁徙或者不需要迁徙的组件。总会有一些系统组件是没需要迁徙到新平台上，但是为了将宕机的可能性和冗杂性降到更低可能又有需要迁徙过去。
举例来说，Windows系统形态信息可能需要合适的东西从一个硬件平台迁徙到另一个硬件平台。若是那种信息能够被迁徙过去，那么新办事器设置装备摆设的冗杂性就能被大大降低，至少从Windows系统和软件的角度来说是如许的。
提醒4：设按期望值并对峙目的
用户都希望实现无宕机的迁徙。
但是不幸的事实是那种零宕机的梦想在实在的迁徙世界中凡是是不成能的。即便在施行物理迁徙时没有呈现可见的宕机(好比在Exchange或者Notes中迁徙电子邮箱)，你仍然需要给你的员工一些喘气的空间来应对意料之外的突发情况。迁徙系统形态信息和二进位，认实规划和在迁徙之前提早做好每一件工作能让宕机的可能性降到更低。
不外消弭所有次要硬件迁徙过程傍边的宕机只是种期许，可能很难实现。
设定合理的宕机数量，确保从IT员工到用户每一小我都晓得什么时候可能发作宕机，宕机的时间会延续多久。若是那种宕机无法被用户所承受，要解释清晰为什么必需那么做的原因以及一意孤行给系统可能招致的灾难性后果。
提醒5：获得你需要的东西
迁徙经常会因为不领会细则招致不测的成果。一个例子：许多从当地物理机迁徙到虚拟机的东西需要数据在迁徙过程中连结静行的形态(仅供数据库办理员处置利用)。关于SQL或者诸如斯类的办事器，那就意味着数据库在迁徙过程中必需包管离线形态，因为在此过程中会面对数据丧失的次要风险。
物理机向虚拟机迁徙的东西仍是一种从物理办事器到虚拟机的单向迁徙。那是对操做的一种限造。若是你的迁徙只是从物理机到虚拟机是可行的，若是你筹算向另一台物理机迁徙就是没有帮忙的。若是在迁徙后才发现那个问题也是于事无补的，应用软件在新的情况中就无法到达你预期的形态。
根据你的需求选择东西库--典型的做法是当地东西和第三方东西相连系，如许能确保你能够平安的施行迁徙，根据方案施行。将那五个提醒连系利用，能够确保不会遗漏掉那一点，你能够在施行迁徙时以最小限度的宕机迁徙到新平台上。