從 IBM Notes 遷移到 Microsoft Exchange 或 Office 365 為組織提供了大量好處，但遷移專案本身看起來令人畏懼，並且不完全清楚從哪裡開始遷移。 Exchange 本身不包含用於 Notes 和 Exchange 完全遷移或共存的自己的工具。 事實上，如果沒有第三方產品，一些遷移和共存任務是不可能實現的。 在本文中，我們將根據最佳實踐和我們成功遷移的經驗概述需要遵循的七個關鍵步驟。
成功的遷移包括以下步驟：
- 初步遷移評估。
- 在 Notes 和 Exchange 之間建立共存。
- 規劃最佳遷移精度。
- 確保最大的遷移效率。
- 運行測試遷移。
- 規劃遷移時間以盡量減少對組織的影響。
- 啟動遷移並追蹤其進度。
在本文中，我們將了解如何使用 Quest 的兩個解決方案來準備和完成遷移 - и 。 切口下方是一些細節。
第 1 步：初步遷移評估
盤點您目前的環境
如果您認為 Exchange 是適合您的組織的平台，您所要做的就是遷移到那裡。 首先，您需要收集有關當前環境的信息，收集有關計劃遷移的數據的清單信息，確定可以刪除哪些內容以減少磁碟空間利用率，計算環境之間的可用頻寬等。初步評估應包括以下問題：
- 有多少個 Notes 網域和 Domino 伺服器？
- 你有多少個信箱？ 其中有多少沒有被使用？
- 主郵件檔案佔用多少磁碟空間？ 檔案中有多少？ 本地副本中有幾個？
- 檔案位於哪裡？
- 有多少用戶使用加密？ 需要傳輸加密內容？
- 環境中有多少個個人資料夾？
- 哪些使用者使用文件連結？ 有多少用戶收到了其他用戶和應用程式的連結？
- 您要傳輸多少資料？ 例如，您只想傳輸最近六個月的資料。
- 本機存檔是否會移轉到個人 Exchange 檔案或 Outlook *.pst 檔案？
- 頻寬限制是多少？ 可以傳輸多少數據
某段時間？ - 遷移後需要多少儲存空間？
移民將如何影響業務和運營
必須仔細規劃該項目，以最大限度地減少停機時間並最大限度地減少生產力損失。
例如，考慮用戶之間的委託非常重要 - 如果用戶遷移但他或她的委託仍保留在原始平台上，這將如何影響他們的日常工作？ 更廣泛地說，您需要考慮遷移專案可能如何影響公司的所有關鍵業務流程和工作流程。
考慮 Notes 中的關鍵接觸點也很重要。 例如，在處理訊息傳遞時，分析應用程式並考慮郵件路由和應用程式之間的互動以避免遷移期間和遷移後業務流程中斷非常重要。 請務必詢問以下問題：
- 哪些用戶擁有委託以及打破這種關係會如何影響業務流程？
- 哪些應用程式和業務流程與電子郵件環境相關？ 在規劃遷移時，應用程式和電子郵件服務之間的任何關鍵整合（例如審批流程）都至關重要。
- 應保留應用程式的哪些元件和重要功能？
- 如何使用新平台的內建功能來實現您需要的功能？
- 非活動內容是否應該存檔以供將來儲存？
- 是否需要重建任何應用程式才能在新環境中正常運作？
- 如何衡量成功？
在開始遷移之前，您需要定義衡量成功的標準。 特別是，您需要了解期望 100% 資料傳輸是不合理的。 並非每個 Notes 項目類型在 Exchange 中都有對應的項目（Active Mail 是最令人震驚的例子）。 因此，實際情況是，遷移後，並非 Notes 中的所有項目都會存在於 Exchange 中。 一個可實現且可衡量的目標是將 95% 的郵件移至 95% 的郵箱。 衡量和記錄結果對於確保遷移成功至關重要，只有在電子郵件遷移專案一開始就定義了成功標準，才能獲得真正的結果。
第 2 步：建立票據和交易所共存
對大多數組織來說，遷移是一個過程，而不是一個事件。 因此，郵箱遷移和應用程式遷移應遵循最適合業務和營運的計劃，而不是基於技術要求。
制定共存策略
為了最大限度地提高遷移的價值，必須在遷移過程的早期制定並實施完整的共存計劃。 「共存」的定義可能因組織而異。 有些組織積極使用忙/閒數據，而其他組織則根本不使用此功能。 有些專注於遷移日曆數據，而有些則專注於遷移完整使用者目錄的微調。 與每個利害關係人合作以清楚了解真正重要的事情並幫助每個人了解有效共存策略的重要性非常重要。
從 Notes 遷移到 Exchange 和 Office 365 需要同時規劃郵箱和應用程式遷移。 所有用戶都必須支援當前的 Notes 應用程式功能，無論他們目前的電子郵件平台如何。 當使用者遷移到 Exchange 和 Office 365 時，他們應該能夠存取和使用 Notes 應用程式作為其現有工作流程的一部分。 此功能應該會持續到 Notes 應用程式遷移到 SharePoint 或其他平台為止。
除了應用程式共存之外，在開始遷移之前還必須實現不同平台上的使用者之間的互動。 這包括所有用戶的自動目錄路由和更新、忙/閒狀態和日曆，無論他們當前的平台如何。
最後，您不僅需要考慮電子郵件服務之間的協作，還需要考慮行事曆和共用資源（例如會議室）之間的協作。 使用者應該能夠下載會議安排資訊。 這包括一次性會議和定期會議。 無論約會是在遷移之前安排還是在遷移期間創建，都必須在整個專案過程中保持日曆資料的準確性。 例如，您需要確保使用者可以更改定期會議中下一次會議的會議室或取消一個會議，而不會在後續會議中造成衝突和混亂。
步驟 3：規劃最佳遷移精確度
規劃從 Notes 遷移到 Exchange 或 Office 365 需要了解平台之間的許多具體差異。
電子郵件地址
Notes 資料通常包含出現在多個位置的專有地址：訊息標題中、嵌入檔案中、個人聯絡人和分散式清單中。 作為遷移過程的一部分，這些專有位址必須更新為 SMTP 位址，以確保 Exchange 環境中的完整功能。 許多組織也選擇在遷移期間更新 SMTP 網域或定址標準。 如果這適用於您的組織，請務必了解某些遷移解決方案會自動更新每個使用者的歷史 SMTP 位址實例。
資料夾結構
在許多組織中，使用者使用自己的郵箱和存檔，因此保留這些資料非常重要。 使用者查看完整資料夾結構的能力也會影響遷移帶來的使用者體驗。 選擇保持資料夾和資料結構完整性的解決方案和轉換非常重要。
本地副本和存檔
為了控制儲存成本並更好地管理資料成長，許多組織設定了郵箱配額。 這項政策的一個意想不到的後果往往是檔案數量和大小的增加。 在遷移規劃期間必須評估這些附加資料來源並考慮它們的遷移。 您可以為使用者提供自助服務元件，允許他們僅遷移重要資料。 為了優化 Exchange 存儲，我們建議使用另一個 Quest 產品 - ，它特別具有對附加文件進行重複資料刪除的有用功能，類似於 Notes 中的 DAOS。
ACL 和委託
存取控制清單 (ACL) 和委派是在 Notes 環境中操作的關鍵元素，而且它們對於保護完整性也至關重要。 因此，準確地將關聯權限和存取權限轉換為 Exchange Server 和 Office 365 中的同等權限非常重要。理想情況下，自動執行此操作將加快流程並消除人為錯誤。 為了維持保護組織資訊資產的有效性，ACL 和委派映射必須與郵件資料同時執行。 某些組織嘗試在資料遷移完成後手動或使用腳本分配同等權限。 然而，這種方法可能會對生產力產生負面影響，並為組織的資料增加安全漏洞。
註釋自己的內容
相同的活動郵件。 從 IBM Notes 遷移時的另一個常見問題是遇到大量富文本。 Exchange 和 Office 365 不支援 Notes 中的整合式標籤式表格、按鈕、儲存的表單和其他專有內容。 因此，您需要為失去此功能做好準備，或投資一個可以將這些元素轉換為可遷移格式的遷移解決方案。 假設 Quest 的解決方案不會以任何方式轉換這些信件，只能將此類信件作為附件傳輸，以便用戶可以透過 Notes 用戶端打開它們。
群組和個人通訊簿
許多組織廣泛使用公共郵件清單進行內部和
外部通訊。 此外，Notes 使用者經常發現在個人通訊錄中維護業務聯絡人非常重要。 這些資料來源對於業務運作至關重要，必須在遷移到 Microsoft 平台的過程中進行有效轉換。 因此，自動準備群組以移轉到 Active Directory 並有效地轉換所有個人位址（甚至是儲存在使用者桌面上的位址）非常重要。
與 Notes 應用程式交互
在規劃和安排遷移時，應用程式和郵件服務之間的整合點（例如協調流程）非常重要。 與其他平台相比，IBM Notes 在電子郵件和應用程式之間具有更緊密的整合。 這些整合可以包括從簡單的文件連結到業務流程的所有內容。
資源和郵件資料庫
許多組織在 Notes 中使用資源預留資料庫、郵件資料庫和其他共用資料庫。 因此，這些資料庫在組織的運作中發揮重要作用。 為了確保業務連續性和員工生產力，考慮實施方法和時機非常重要：
- 在目標環境中建立資源郵箱；
- 將資料從預訂資料庫傳輸到 Exchange；
- 確保兩個系統的使用者可以協作並使用 Notes 和 Exchange 中的資源。
第 4 步：最大限度提高遷移效率
除了確保資料準確性之外，根據組織的要求確保遷移盡可能有效率也很重要。 遷移的效果不僅直接取決於直接成本，還取決於對業務的影響程度。
遷移方案架構
影響效率的最重要因素之一是遷移解決方案的架構。 選擇具有多執行緒架構的解決方案非常重要，該解決方案允許一台遷移伺服器同時遷移多個使用者。 多執行緒架構降低了遷移硬體需求並提高了遷移速度，從而顯著降低了整體專案成本。 不要被聲稱是多執行緒的遷移解決方案所愚弄，但實際上一次只能遷移一個用戶，並且需要添加工作站才能一次遷移更多用戶。 根據配置和環境，真正的多執行緒解決方案在將資料遷移到 Exchange 和 Office 30 時效率提高 5000% 到 365%。
遷移過程
遷移涉及許多步驟，這些過程必須在正確的時間進行，以確保平穩過渡。 為了最大限度地減少業務中斷並最大限度地提高遷移的收益，所有流程必須由單一應用程式整合和控制，該應用程式可以及時處理遷移的每個步驟。
靈活性和自助服務
有些使用者和部門需要偏離標準遷移流程。 例如，法律部門可能有不同的儲存需求，或者管理人員可能需要遷移整個郵箱和檔案。 因此，選擇一個靈活的遷移解決方案，讓遷移團隊能夠輕鬆適應這些需求非常重要。 提供這種靈活性的最有效方法之一是為某些用戶啟用自助服務。 例如，某些使用者可能被允許從其主郵件檔案或本地資料傳輸附加數據，以便稍後將其轉換為伺服器上的個人存檔。
步驟 5：運行測試遷移
一旦完成遷移前評估、最終確定共存策略並定義最佳化計劃，透過一次或多次試點遷移獲得策略確認至關重要。
試點遷移的目的是測試所開發的程式並確定全面遷移開始後可能出現的問題，使他們有機會在開始即時遷移之前解決這些問題。 因此，在試點遷移過程中出現問題是可以預料的，甚至是值得歡迎的。
確定飛行員遷移量
飛行員遷移應該足夠大，以收集代表性的數據樣本並回答戰鬥遷移期間可能遇到的相關問題。 如果您要遷移數千個郵箱，樣本大小應該就足夠了。 對於非常大的遷移，百分比可能會更低。
數據和系統的選擇
在飛行員遷移過程中，作戰資料和作戰系統的使用非常重要。 這非常重要，原因如下：
- 您需要了解戰鬥環境的表現。 合成生成的環境不能代表戰鬥環境。
- 您可以根據範例資料取得加密郵件、Exchange 中找不到的郵件類型的頻率以及儲存需求的更多資訊。
設定期望
試點遷移過程還提供了一個絕佳的機會來測試專案概述的成功標準並校準對剩餘遷移的期望。 如果需要調整，則必須記錄下來並在戰鬥遷移過程中予以考慮。
步驟 6：規劃遷移時間以盡量減少對組織的影響
使用者分組
為了最大限度地減少對使用者和整個組織的影響，一起工作的使用者應同時遷移。 建立這些群組時要考慮的關鍵因素包括授權。 尋找一種解決方案，該解決方案可以根據有關來源環境中使用者關係的資訊推薦要遷移的集合。
遷移時機
群組遷移完成後，請務必安排好遷移的時間
對這些用戶的影響很小。 這可能意味著將遷移窗口安排在一天中的特定時間，以避免在工作時間、年底或維護窗口期間進行遷移。 例如，銷售團隊可能要到季度末才可以遷移，而會計和法律部門可能會限制他們的遷移時間。
第 7 步：開始遷移並追蹤其進度
有了經過試驗驗證的資料遷移方法，戰鬥遷移應該成為例行事件。 整個過程可能會略有調整，以滿足某些群體的需求。 仍需要仔細監測，以確保在規劃和試點階段考慮所有突發事件。 然而，這個過程必須變得越來越自動化。 戰鬥遷移計劃的執行對於記錄和傳達整個組織的進展非常重要，以確認期望得到滿足。 監控和回饋仍然是整個過程中成功遷移的關鍵面向。
結論
我們介紹了遷移郵政服務時需要考慮的事項。 如果您目前正在選擇遷移解決方案或只是在考慮它，那麼考慮所有這些非常重要。 我們使用 Quest 的遷移解決方案，並準備好推薦它們，因為它們是減少手動步驟數量和增加遷移所傳輸的資料量的最有效方法。
如果您想了解有關有效遷移方法的更多信息，請向 在我們的網站上或致電，您也可以使用以下連結學習其他資料：
來源： www.habr.com