存储在线将工作负载迁移到新的服务器上，这似乎是件再简单不过的事情了，不过在这过程中可能充满着风险。这里列举一些在实施硬件迁移过程中的应当注意的地方：
服务器识别
通常在负载迁移时，新的服务器会采用旧服务器的识别方式。虽然这种识别转换通常都通过备份恢复的方式完成，不过最好提前记录下服务器的参数信息。
尤其是针对服务器的计算机名和互联网协议地址。当恢复到不一样的硬件上时，通常都会丢失掉静态IP地址。同样，我也遇到过在新服务器完全加入一个域之前必需重启整个动态目录服务器账户的情况。
当然，你可以为新的服务器使用不同的名称，不过这会使得迁移变得更为困难。新的计算机名称可能导致数字证书的失效，并引起网络驱动器映射的失败。
服务包的版本和补丁
你在进行负载迁移之前还应当记录下旧的硬件上服务包和版本。如果你尝试着将工作负载迁移到一台运行不同版本服务包的新服务器上，你可能会碰到数不清的问题。以Exchange Server为例，服务包版本直接影响你加载邮箱数据库的能力。
试验性测试
工作负载迁移的最关键部分是在测试环境下测试新的硬件和整个迁移过程。我通常会隔离出一个封闭的测试环境，然后尝试恢复域控制器的备份、基础架构服务器(DNS、DHCP等)以及任何其它必要的部分来彻底地测试整个迁移过程。
在测试环境下，我会尝试将新的生产系统加入测试域。这样做有几个原因。首先，在测试环境中加入新的硬件可以保证较好的硬件整合。如果某些组件会出现问题，也最好是在新的服务器整合到生产环境之前发现它。
我倾向于在测试环境中使用新硬件的另一个原因在于可以发现生产系统上有时可能出现的硬件级别的瑕疵。例如，你可能会发现你需要卸载新服务器上的网卡，禁用TCP/IP协议。
最小化宕机时间
在迁移过程中，你应当拿出一个规划来最小化宕机时间。假如你所要替换的服务器是某组集群中的一部分，你可能只需要将新服务器加入集群并移除旧的设备。而在非集群模式下，最小化宕机时间可能颇具挑战。
最小化服务器宕机时间的确切方式取决于工作负载的类型。一般情况下，在进行迁移过程之前，我会将最近的一次备份恢复到新的服务器上。当要进行迁移时，我会将旧的服务器从网络上断开，然后执行最后一次备份。由于新的服务器已经有了最近的一次备份，将最新的备份恢复到新的服务器上应当相对较快，因为只有新变动的数据才需要恢复。
软件支持
最后，记住要在服务器上运行的软件支持列表。这其中包括防病毒软件和备份引擎。我曾经遇到过非常挑剔的软件支持情况，使得迁移后的运行总有问题。这也是测试为什么非常重要的另一个原因。
将工作负载迁移到一台新的服务器上的确切方法种类繁多，这取决于服务器的具体负载情况，以及你自身的基础架构需求。不过在任何情况下，你都应该在进入生产环境之前测试迁移过程。通过彻底的测试，你可以确保所有必需的服务都能够启动，所有的数据库都可以在服务器上正常加载，并且服务器上的数据都可以正常访问。