我們都知道這種情況：解決方案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或者諸如此類的服務器，這就意味著數據庫在遷移過程中必須保證離線狀態，因為在此過程中會面臨數據丟失的主要風險。物理機向虛擬機遷移的工具還是一種從物理服務器到虛擬機的單向遷移。這是對操作的一種限制。如果你的遷移只是從物理機到虛擬機是可行的，如果你試圖向另一台物理機遷移就是沒有幫助的。如果在遷移後才發現這個問題也是於事無補的，應用軟件在新的環境中就無法達到你預期的狀態。
按照你的需求選擇工具庫--典型的做法是本地工具和第三方工具相結合，這樣能確保你可以安全的執行遷移，按照計劃實施。將這五個提示結合使用，可以確保不會遺漏掉那一點，你可以在實施遷移時以最小限度的宕機遷移到新平台上。
