將工作負載遷移到新的服務器上，這似乎是件再簡單不過的事情了，不過在這過程中可能充滿著風險。這里列舉一些在實施硬件遷移過程中的應當注意的地方：

　　服務器識別

　　通常在負載遷移時，新的服務器會采用舊服務器的識別方式。雖然這種識別轉換通常都通過備份恢復的方式完成，不過最好提前記錄下服務器的參數信息。

　　尤其是針對服務器的計算機名和互聯網協議地址。當恢復到不一樣的硬件上時，通常都會丟失掉靜態IP地址。同樣，我也遇到過在新服務器完全加入一個域之前必需重啟整個動態目錄服務器賬戶的情況。

　　當然，你可以為新的服務器使用不同的名稱，不過這會使得遷移變得更為困難。新的計算機名稱可能導致數字證書的失效，并引起網絡驅動器映射的失敗。

　　服務包的版本和補丁

　　你在進行負載遷移之前還應當記錄下舊的硬件上服務包和版本。如果你嘗試著將工作負載遷移到一臺運行不同版本服務包的新服務器上，你可能會碰到數不清的問題。以Exchange Server為例，服務包版本直接影響你加載郵箱數據庫的能力。

　　試驗性測試

　　工作負載遷移的最關鍵部分是在測試環境下測試新的硬件和整個遷移過程。我通常會隔離出一個封閉的測試環境，然后嘗試恢復域控制器的備份、基礎架構服務器（DNS、DHCP等）以及任何其它必要的部分來徹底地測試整個遷移過程。

　　在測試環境下，我會嘗試將新的生產系統加入測試域。這樣做有幾個原因。首先，在測試環境中加入新的硬件可以保證較好的硬件整合。如果某些組件會出現問題，也最好是在新的服務器整合到生產環境之前發現它。

　　我傾向于在測試環境中使用新硬件的另一個原因在于可以發現生產系統上有時可能出現的硬件級別的瑕疵。例如，你可能會發現你需要卸載新服務器上的網卡，禁用TCP/IP協議。

　　最小化宕機時間

　　在遷移過程中，你應當拿出一個規劃來最小化宕機時間。假如你所要替換的服務器是某組集群中的一部分，你可能只需要將新服務器加入集群并移除舊的設備。而在非集群模式下，最小化宕機時間可能頗具挑戰。

　　最小化服務器宕機時間的確切方式取決于工作負載的類型。一般情況下，在進行遷移過程之前，我會將最近的一次備份恢復到新的服務器上。當要進行遷移時，我會將舊的服務器從網絡上斷開，然后執行最后一次備份。由于新的服務器已經有了最近的一次備份，將最新的備份恢復到新的服務器上應當相對較快，因為只有新變動的數據才需要恢復。

　　軟件支持

　　最后，記住要在服務器上運行的軟件支持列表。這其中包括防病毒軟件和備份引擎。我曾經遇到過非常挑剔的軟件支持情況，使得遷移后的運行總有問題。這也是測試為什么非常重要的另一個原因。

　　將工作負載遷移到一臺新的服務器上的確切方法種類繁多，這取決于服務器的具體負載情況，以及你自身的基礎架構需求。不過在任何情況下，你都應該在進入生產環境之前測試遷移過程。通過徹底的測試，你可以確保所有必需的服務都能夠啟動，所有的數據庫都可以在服務器上正常加載，并且服務器上的數據都可以正常訪問。