權威指南
遷移到 SharePoint
線上和本地部署
撰稿 |理查德·哈布里奇 & 坎瓦爾·基普爾
白皮書
您一定會喜歡我們的工作方式。一起。
遷移到 SharePoint Online 和 SharePoint 2019 的權威指南
您一定會喜歡我們的工作方式。
一起。
介紹
透過 Microsoft 365 和 SharePoint Online，Microsoft 提供了一個現代化平台，允許組織建立自己客製化的數位工作場所。可以結合使用 Microsoft 365 提供的應用程式和豐富的功能來建立適合組織的需求和要求、企業實體及其員工的環境。
由於舊版的 SharePoint 不提供許多令人興奮的新功能，因此許多組織正在考慮從舊環境遷移到 Microsoft 365 和 SharePoint Online。想要或需要在自己的託管環境中託管 SharePoint 的使用者可以遷移到 SharePoint 2019。
無論指定的目標環境如何，遷移現有環境都不是一件容易的事，需要大量的規劃和準備。根據我們的員工在不同組織的 SharePoint 遷移方面的長期經驗，我們知道徹底、全面的規劃是成功的關鍵一步。
本白皮書提供了從早期版本的 SharePoint 遷移到 Microsoft 365、SharePoint Online 和 SharePoint 2019 的指南和最佳實務。
移民的商業驅動因素
每個人最終都會升級（或他們離開該平台），因此我們認為談論企業為何加速升級或他們在哪些方面（就工作負載而言）考慮「早期」升級/遷移 SharePoint 總是好的。
那麼人們為什麼要升級或遷移呢？值得注意的是，IT 面臨內部和外部的技術升級壓力。
內部壓力：
- 在內部，我們總是處於一個用更少的錢做更多的事情的循環中。通常，升級提供了多種以優化或更有效率的方式完成任務的方法，支援對 IT 不斷增長的需求。
- 在本地維護 SharePoint 等舊版本的技術可能具有挑戰性。現在，尋找具有 SharePoint 2007/2010/2013/2016 等經驗或知識（並且想要使用它）的人員非常困難。這很困難，因為當時的 SharePoint 專家較少，但主要是因為經驗豐富且技術熟練的專業人員希望使用最新版本。
- 通常，升級（尤其是 SharePoint 升級）會增強對標準或新技術的支援。就SharePoint而言，改進的瀏覽器支援、行動裝置支援和Windows/Office整合可以支援相關升級或工作場所新技術帶來的不斷增長的需求。
- 員工正在使用現代化的 web 科技融入他們的私人生活，隨著這些技術的發展，員工期望組織能跟上新科技的腳步。
外部壓力：
- 在消費市場中，我們有很多選擇，對科技、使用者體驗和易用性的期望也越來越高。這給 IT 帶來了巨大的壓力，要求 IT 部門提高回應速度並加快內部升級週期（以確保提供有競爭力的產品和可用性）。當組織內的領導者圍繞 IT 並購買 SaaS（軟體即服務）或最初可能會或可能不會受到企業 IT 認可的替代技術時，這一點尤其明顯。
- 行動裝置、平板電腦和遠端裝置支援的壓力主要是由消費者世界中這些工具的舒適度和依賴性的增加所驅動的。在 BYOD（自帶設備）環境中，IT 部門面臨越來越大的壓力，需要為歷史上可能未受支援或考慮的設備提供支援和選項。
- 近年來，我們所有人的工作方式發生了巨大變化。即使是最近放棄對行動員工需求的組織也在改變其業務以納入行動員工。有些組織甚至放棄了辦公室，轉而採用行動辦公室或家庭辦公機會。這些變化要求企業內部網路能夠支援這種非常規的新工作方式。
2.1.更好的使用者體驗
即使舊版的 SharePoint 只提供了適量的功能來滿足要求，我們也應該記住，它們的使用者介面是多年前設計的。使用者介面的演變是一個快速發展的過程。我們大多數人會因為各種目的而使用多個網路平台（例如 Facebook、Twitter、LinkedIn 等）。這些平台的提供者正熱切地致力於保持其使用者介面更新，甚至整合現代 UI 元素。作為這些互聯網平台的用戶，我們都習慣了現代用戶介面及其以高效和以用戶為中心的方式提供功能的方式。如果組織繼續使用舊版的 SharePoint，它將遇到使用者採用、效率和功能缺失等問題。企業內部網路推出時效果很好的東西如今卻缺乏功能和效率。
關於使用者體驗，組織應考慮遷移到 Microsoft 365 或 SharePoint 2019 主要有兩個原因：
- 用戶採用/用戶滿意度： 組織的員工正在使用公司內部網路來管理他們的日常業務。對他們來說，企業內部網路更像是工具，而且這個工具應該使用起來簡單直覺。它應該提供與前面提到的大多數互聯網平台提供的類似的用戶介面。換句話說：該工具應該採用當今廣泛認可的使用者介面，因為使用者介面的任何重大差異都會導致額外的成本，並可能導致挫折感 - 在極端情況下甚至導致熟練員工移民。
- 功能/效率： 如果一個組織為所有員工提供企業內部網路作為工具，那麼該工具應該是最新的，以便為員工提供最佳支援。您可能認為上傳文件在現代環境中只需單擊 5 次，而在現有環境中單擊 XNUMX 次並不重要。但正是這兩次點擊決定了傳統與效率的差異。換句話說：這兩次點擊將大大提高可用性和用戶採用率。
2.2.更好地支援業務流程
企業內部網路不再是與其他系統結合使用的獨立工具。如今，企業內部網路更像是所有員工的數位工作場所，而這個數位工作場所也需要包含或支援業務流程。對於前amp文件中，管理員工的行蹤或休假請求不應推廣到組織網路內的外部系統。現代數位工作場所的基本理念是將業務流程盡可能無縫地整合到員工的日常業務中，以避免任何分散注意力的上下文切換。
舊版的 SharePoint 為整合業務流程提供了一些支援。與 Microsoft 365 或 SharePoint 2019 提供的選項相比，舊版的業務流程支援看起來很小。讓我們以前任身分使用 Power Automateamp勒。透過 Power Automate，您可以輕鬆將 Microsoft 365 和 SharePoint 連接到外部系統以交換資料。對於舊版本的 SharePoint，要實現這一點要困難得多。您需要使用 BCS（業務連線服務）來設定僅提供有限功能的外部連線。
對於一個組織來說，ROI（投資報酬率）是一個至關重要的因素。假設組織想要推出他們的客製化數位工作場所版本，以最好地支援其員工。在這種情況下，應選擇一個能夠提供最佳支援的平台，以盡可能無縫地整合業務流程 - 在這裡，SharePoint 2019 或 Microsoft 365 等現代平台可以發揮其優勢tages.
2.3.更好地支援協作
以前，員工或多或少都是靠自己的努力來實現特定的目標或里程碑。今天我們知道，這種工作方式並沒有提供最佳效率，也沒有促進組織內部的團結（我們的感覺）。事實證明，團隊合作效率更高——即使員工在不同時區的不同地點工作。現代數位工作場所需要支援團隊和團隊合作，由於團隊合作是一種非常靈活和敏捷的工作方式，因此現代數位工作場所也需要具有靈活性。如果組織繼續使用難以支持靈活團隊合作的舊平台，那麼提高效率、降低成本和提高用戶滿意度的選擇就會被浪費。
完全適合團隊需求的協作領域透過提高效率來節省成本。規劃和創建這種客製化的協作區域會涉及一些成本，但投資回報率將在短時間內得到認可。舊版的 SharePoint 遠遠落後於 Microsoft 365 提供的潛力，這也是組織考慮遷移的另一個原因。
2.4.更好地支援行動設備
如果有一個科技領域發展最快，那就是行動裝置。如今，辦公室安裝的行動裝置比桌上型電腦多得多。我們中的許多人甚至使用多個行動裝置。這種趨勢目前還看不到結束的跡象。相反，行動裝置很快就會比當今大多數桌上型電腦更強大。硬體製造商甚至正在考慮開發功能強大的智慧型手機，使其可以用作辦公室工作的桌上型電腦。
行動辦公人員的數量逐年穩定成長，能夠使用行動裝置不受任何限製或限制地存取企業內網已成為必備條件。舊版的 SharePoint 提供了一些行動支持，從技術角度來看，這種行動支援還可以增強。儘管如此，在大多數情況下，所涉及的成本幾乎沒有任何理由。通常，遷移到 Microsoft 365 或 SharePoint 2019 會更具成本效益，以便從這兩個平台提供的開箱即用的強大行動支援中受益。
2.5.降低硬體維護成本
先前版本的 SharePoint 需要安裝在專用伺服器上，這些伺服器被分組為伺服器集區。這些伺服器需要大量維護才能保持正常運作。他們消耗了大量的能量，需要不斷地努力管理備份。遷移到 SharePoint 2019 時這一點不會改變，但組織在遷移到 Microsoft 365 時將大幅降低硬體維護成本。
2.6。提高安全性
許多組織認為他們的資料和文件在其環境中更安全，就像保存到雲端一樣。事實上，事實恰恰相反。 Microsoft 正在投入大量資金和人員來保護其雲端環境以及客戶的資料和文件。幾乎沒有任何組織能夠花費相當數量的精力和資源來保護其本地環境。 eCloud 託管是 Microsoft 的核心業務（Microsoft 365、SharePoint Online、Microsoft Azure），盡可能保持環境安全符合 Microsoft 的切身利益。與早年的雲端託管相比，如今，保存到 Microsoft 365 的資料和文件比大多數（如果不是全部）本地環境要安全得多。
遷移關鍵考慮因素
一旦規劃完成並且計劃經過多次驗證，您的組織將繼續進行遷移活動和遷移執行。將內容從一種環境遷移到另一種環境並不像遷移那麼容易 file從一個資料夾到另一個資料夾。當計劃在專業環境中遷移資料時，我們需要考慮如何在對業務造成最小影響的情況下最好地遷移資料。本文檔的以下部分提供了一個完整的view 最常見的遷移考慮因素。
3.1.儘早且經常詢問的關鍵遷移問題
在規劃遷移時，您將盡力回答關鍵問題。以下是您應該考慮的一些進階問題（以及為什麼遷移可能比最初想像的更複雜）。
- 您的遷移是否需要重新組織或最佳化資訊？
o 技術遷移通常更容易確定範圍、管理和控製成本。
然而，優化和重組工作時所需的業務互動、批准和參與往往會導致範圍複雜且預算難以管理。 - 您能否將以重組/優化為重點的工作與技術工作分開？
o 您的下一次升級/遷移是什麼時候？展望未來，即使在 Microsoft 365 中，仍需要進一步優化。組織。使其更易於導航、更容易找到、更適用。 - 需要遷移的內容量是多少？
o 這需要了解文件和清單、函式庫、結構、解決方案等。您知道您的組織中存在哪些內容嗎？ - 您目前的系統中儲存了哪些類型的內容？
- 內容儲存在哪裡以及如何儲存？
- 目前內容是如何添加到您的系統中的？
o 注意掃描和擷取集成，因為這是一個經常被忽視的典型複雜性。 - 您目前的方法是否使用大量資料夾而不是元資料？
- 如今的結構有多扁平（能夠快速地重新組織和優化知識集合）？
o 在 Microsoft 365 中，當組織從經典過渡到現代時，需要將許多網站結構從子網站嵌套結構展平為自己的網站集。這些補充了中心網站作為一種組織形式、更大的靈活性、套件功能（例如 Microsoft 團隊）等等。 - 今天如何管理和處理安全？
o 隨著您的進步，使用 AD 群組總是比使用 SharePoint 群組更好。
這在 Microsoft 365 中更為明顯，其中 Azure/Microsoft 365 群組可用於跨服務實現一致的成員身份，並透過配置（例如基於 AD 屬性自動應用的動態權限等）進行增強。 - 外部使用者如何管理，以及他們如何存取資源/內容？
- 您制定了哪些保留政策（如果有）？是否可以留下或刪除任何內容？您將如何遷移這些策略並確保兩個環境之間關於記錄和保留管理方式的一致性？您知道您已經並將如何處理內容生命週期嗎？
- 您知道當今參考文獻、複合文件或外部連結文件的使用頻率嗎？
o 對於前amp文件中，當您有指向另一個 Excel 文件的連結時，這可能需要進一步處理或手動修復遷移後工作簿才能按需要工作。
3.2.遷移方法
在考慮遷移方法時，通常會先想到兩種方法。
儘管以下方法是最常用的，但沒有哪一種方法是最常用的。
最適合特定組織的遷移方法取決於許多因素，例如資料量、內部結構或工作方式。組織利用兩全其美並基於以下前兩種方法的基本思想建立遷移方法的情況並不罕見。
一次性方法
這種方法通常也被稱為“大爆炸方法”。這意味著遷移是一步執行的。作為前任amp例如，週五下午，現有系統轉為所有員工的唯讀模式。遷移和驗證在周末進行，週一早上，所有員工都可以繼續使用新系統工作。對於需要遷移的資料量較少的小型組織來說，這是一種合適的方法。
根據經驗，我們可以假設大約 5 GB/小時可以遷移到 SharePoint Online（取決於實際的 Internet 效能）。這個估計豪url傳輸速率是這種遷移方法的限制因素。雖然有一些技術可以提高遷移速度，但克服 Microsoft 365 限制通常非常具有挑戰性，特別是當你要遷移到的目標租用戶已在使用中時。
分階段方法
與前一種方法相反，分階段方法是一個接一個地遷移公司實體。作為前任amp樂：首先，HR部門遷移到新平台。人資部門成功遷移後，行銷部門也會遷移，等等。這裡的目標是將內容分成集合或批次，並依照預先規劃的分階段順序遷移。當數量對於一次性方法來說太大並且新舊系統需要並行使用一段時間時，這種方法會派上用場。與一次性方法相比，此方法需要更廣泛的規劃，特別是在需要考慮依賴性的情況下。
增量或增量遷移
無論遷移方法如何，通常都會使用增量遷移或增量遷移。當要遷移的資料量過多並在常規非工作時間進行驗證時，這一點也極為重要。本質上，用戶繼續使用舊系統，而先前遷移的內容仍然經過驗證。第一個內容集合經過遷移和驗證後，僅需要在第二次遷移中遷移增量（即：在第一個內容集合得到驗證時創建或修改的內容）。
為了確保遷移的資料準確性和完整性，遲早需要將來源環境設定為唯讀，並且在最終的「增量」或增量遷移期間不允許進行任何更改。通常，第二個集合的內容比第一個集合少得多，這意味著第二個集合可以在常規非工作時間或更短的時間內遷移。
大多數專業遷移工具都提供內建遷移的支援。他們可以遷移最近更新的內容，而無需遷移上次遷移和最新增量/增量遷移之間看似未更改的內容。
無論您使用哪種方法，為遷移本身製定逐步且詳細的計劃都很重要。根據評估活動，您將確定在規劃階段應如何處理每個內容批次的遷移本身。
遷移策略與規劃
當遷移到 Microsoft 365 和 SharePoint Online 時，各組織所採取的方法通常非常相似，因為從評估到遷移後的任何遷移都有充滿戰術活動的階段。對於大多數 SharePoint Server 遷移也是如此。通常，升級支援過程不會用於避免支付額外的硬體配置和設定費用，以從舊版本的 SharePoint Server 跳到新版本（因為每個版本都支援從上一個版本升級）。
作為前任amp文件中，以下是一個簡單的圖表，描述了大多數 SharePoint Online 遷移的典型流程。
圖 1 – Samp文件遷移過程
雖然專注於戰術考量很關鍵，但制定正確的策略和調整也很重要。本節將重新view 典型遷移的每個“階段”，並概述關鍵注意事項、最佳實踐等，以幫助您的組織在您希望遷移到 SharePoint Online 和 Microsoft 365 時做好更充分的準備並取得成功。
請記住，您可能更多地基於角色而不是階段來考慮遷移工作。如下圖所示，您仍然可以根據遷移過程中誰做了什麼來預先規劃和思考遷移流程。為了簡潔起見，我們將把指導重點放在階段活動上，而不是組織今天用於遷移的許多角色/方法。
圖 2 – Samp勒夫 File 共享遷移映射的遷移步驟
4.1. 評估階段
每次遷移都需要從評估開始，因為您需要準確地了解要遷移的內容以規劃和準備遷移。
從簡單和高層次的角度來看，我們需要識別和決定將遷移的內容，確定優先順序（基於業務和技術複雜性/挑戰）、誰擁有內容以及內容本身。最後，重要的是不要忘記也應該評估目標 Microsoft 365 環境的準備。
正如以下幾節將概述的，需要評估的不僅僅是要遷移的集合的大小。
4.1.1 場地結構評估
站點結構評估就是對現有入口網站的站點結構進行快照。但本次評估並沒有就此結束。評估現有站點結構後，通常需要更新或調整以反映公司變更或其他要求。許多組織正在利用這個機會更新現有的站點結構，特別是如果現有的站點結構是多年前創建的。在考慮不同的網站結構時，組織應遵循 Microsoft 關於 SharePoint 中網站集的最新建議。從本質上講，這意味著應盡可能避免使用子網站。 Microsoft 建議使用多個網站集，而不是建立嵌套的子網站結構。邏輯結構不再由父網站/子網站關係應用，而是由應用於導覽的邏輯結構應用。
新的 SharePoint 中心網站還可以建立邏輯網站/子網站結構，同時在背景建立平面技術網站結構。 「多個網站集」方法具有明顯的優勢tag關於靈活性和可管理性。
如果在遷移之前更新了網站結構，則必須使用對應表來將現有網站結構對應到新的/更新的網站結構。
此評估的結果是所有站點及其相關的列表 URLs、描述、用於創建網站的模板、網站所有者以及用作中心網站的網站的指示器。
建立所有現有網站清單的最佳選擇是使用 PowerShell 腳本，該腳本會迭代所有網站集和所有網站。使用 PowerShell 的好處是腳本可以檢索所有相關資訊以建立所有現有網站的詳細清單 - 並且可以安排它在繁忙的辦公時間之外運行。
4.1.2.內容評估
在內容評估期間，將評估文件和結構化資料（如資料清單）。此評估旨在了解舊環境中目前託管的資料和文件類型。另一個目標是確定舊環境中目前存在的資料量。雖然內容清理後資料量通常會減少，但了解將要遷移的資料量會很有幫助。
在內容評估期間，也會確定文件的版本。從較舊版本的 SharePoint 移轉到 Microsoft 365 或 SharePoint 2019 時，內容評估用於決定需要移轉哪些版本（如果不是所有版本）的文件。當從一個遷移 file-共享到Microsoft 365或SharePoint 2019，需要先識別文件版本。通常，版本號碼會加入到文件的標題中（例如 Business Report 2018 – V1.4.docx）。困難的部分是聚合單個 file基於文件版本並建立與 SharePoint 相容的文件版本清單。
內容評估也是內容清理階段的重要準備。內容評估結果可用於確定不應遷移或不再使用的文件。
此評估的結果是所有文件及其內容的列表 URL/位置、它們的大小、它們的類型、版本數量（如果適用）、它們的建立/修改日期以及建立和修改文件的使用者。
建立所有現有文件清單的最佳選擇是利用 PowerShell 腳本來迭代所有現有文件庫或 file-股權結構。
4.1.3.工作流程評估
SharePoint 中使用工作流程來實作業務流程。許多組織使用不同類型的工作流程來實施其內部流程。在工作流程評估期間，將評估現有環境中使用的所有工作流程。此評估包括工作流程類型（內建、SharePoint Designer、自訂、第 3 方）、位置、使用案例和關聯的業務流程。此外，在此評估過程中，將識別標記為活動或正在進行時間異常長的工作流程。最好在遷移之前決定如何處理「凍結」工作流程。
工作流程評估需要提供的最重要資訊是工作流程類型，因為並非所有類型的工作流程都可以原樣遷移到 Microsoft 365 或 SharePoint 2019。
許多組織利用這個機會重新view 所有已識別的工作流程（不僅是那些無法移轉的工作流程），以檢查工作流程是否仍符合業務要求。組織在將舊技術（如 SharePoint Designer）建構的工作流程遷移到目標環境之前對其進行現代化改造的情況並不少見。
此評估的結果是工作流程列表， URL 使用工作流程的位置、工作流程的類型（OOTB、SPD、自訂或第 3 方）以及潛在的遷移路徑。無法原樣遷移的工作流程需要使用合適的技術重新設計（例如 電力自動化).
4.1.4.客製化解決方案評估
自訂解決方案（或自訂應用程式）主要用於兩個目的：增強現有功能或新增 SharePoint 中不存在的功能。大多數客製化解決方案要么基於伺服器端程式碼，要么基於客戶端程式碼構建，並且它們要么是內部構建的，要么是從第三方供應商購買的。
自訂解決方案評估用於建立所有自訂解決方案的清單，該清單用作決定是否以及如何將每個已識別的自訂解決方案遷移到新環境的基礎。許多組織使用此選項來重新view 所有已確定的客製化解決方案，以檢查它們是否仍然滿足核心要求。自訂解決方案評估還提供了考慮應用程式現代化的選項。即使現有的客製化解決方案仍然符合核心要求，花一些時間對現有應用程式進行現代化改造也是有意義的——例如改進/增強功能或使用不同的平台來託管應用程式（例如 微軟Azure).
此評估的結果是所有客製化解決方案的列表， URL 解決方案的使用位置、類型、業務用例、負責聯絡人以及潛在的遷移路徑。最好也加入原始開發文件的超連結。
建立所有現有自訂解決方案清單的最佳選擇是利用 PowerShell 腳本迭代所有現有網站。
4.1.5.評估工具
SharePoint 遷移評估工具 (SMAT) 是一個簡單的命令列執行文件，它將掃描 SharePoint 場的內容，以協助識別您計劃遷移到 SharePoint Online 的資料的任何問題。結果報告會向您指出一些文章，以幫助您解決您所發現的任何問題。該工具在背景運行，不會影響您的生產環境。
SharePoint 遷移評估工具(SMAT) 是一個簡單的命令列執行文件，它將掃描SharePoint 場的內容，以協助確定使用Microsoft 365 將伺服器移轉到SharePoint Online 的影響。工具執行透過掃描 SharePoint、Active Directory 和 Azure Active Directory 進行身分識別對應。由於該工具設計為在不影響您的環境的情況下運行，您可能會發現該工具需要一到兩天才能完成對您的環境的掃描。在此期間，該工具將在控制台視窗中報告進度。
掃描完成後可以發現輸出 file位於 Logs 目錄中。您可以在此處找到有關可能受遷移影響的場景的摘要和更詳細的見解。該工具將匿名統計資訊報告給微軟，以提高微軟產品和服務的品質。或者，您可以在掃描結束時出現提示時識別您的組織。如果該工具無法連接到互聯網來報告此信息，該工具仍將按預期運行。
下載該工具： SharePoint 移轉評估工具 (SMAT)
4.2.準備階段
在評估您將遷移到的內容和環境後，準備好將哪些內容遷移到何處、如何以及何時遷移至關重要。透過清理、減少總目標內容或明確定義應更改的內容，可以使這變得更容易。在某些情況下，例如遷移到 SharePoint Online 時，在遷移之前預先建立目標結構可能會更好。
4.2.1.場地結構準備
根據網站結構評估結果，需要在新環境中建立網站。如果新結構與現有結構不同，則需要根據相關部分中所述的映射表來建立新結構。如果使用新的網站結構，則新的網站結構可能會遵循 Microsoft 關於 SharePoint 中的網站集的建議。為了能夠實現邏輯結構，需要將特定站點轉變為中心站點，相關站點需要與其中心站點相關聯。
在實施新的站點結構之前，需要重新調整新的結構view編輯。這重新view 應由不同（如果不是全部）部門或公司實體的成員執行。
4.2.2.內容準備
根據內容評估的結果，需要啟動清理過程。
清理意味著重新確定已識別文件清單view尋找不應遷移到新環境的文檔 - 這些可以是臨時文檔、過時文檔或不再相關的文檔。由於大多數文件屬於特定的公司實體（例如部門），因此相關公司實體的內容所有者或成員應負責清理其文件。
如果文件來自 file-share 應遷移到 SharePoint，很可能存在文件的多個版本。作為一個 file-share 不提供對文件版本的任何支持，編輯者通常將版本號附加到文件標題中。這些「標題版本」文件在遷移到 SharePoint 之前需要進行識別，因為 SharePoint 文件庫可以處理文件的多個版本。已確定的「標題版本」文件需要傳輸到 SharePoint 文件庫的版本控制機制中。
如果新環境的網站結構與舊環境的網站結構不同，文件也可能會儲存到不同的位置。如果存在網站對應表，則需要更新文件清單以反映每個文件的新網站。清理後更新文件清單是有意義的。
如果您打算在遷移過程中實現現代化，則此映射還應該考慮所需的未來狀態。這不僅是 SharePoint 遷移所特有的，也與 file 共享遷移。
4.2.3.工作流程準備
根據工作流程評估結果，需要為每個已識別的工作流程建立遷移路徑。工作流程的類型對於決定遷移路徑至關重要。要做的第一個決定是工作流程是否應該在功能方面進行更新/現代化。如果正在更新或現代化工作流程，則很可能需要使用現代技術（例如 Power Automate）來重建工作流程。
如果您想開始建立遷移路徑，以下要點清單可能會有所幫助：
- 開箱即用工作流程： 通常，這些工作流程可以毫無問題地遷移。
- SharePoint Designer 工作流程： 通常，這些工作流程可以毫無問題地遷移，但某些工作流程可能需要一些手動調整或調整。
- 自訂工作流程： 通常，這些是基於伺服器端程式碼的編碼工作流程，這意味著它們無法遷移到 SharePoint Online。可能可以移轉到較新版本的本機 SharePoint。
- 第三方工作流程： 在大多數情況下，這些是 Nintex 或 K2 工作流程，製造商很可能提供升級路徑或升級程序。
根據評估的升級路徑，需要為所有工作流程建立估計和時間表，而這些工作流程無法按原樣遷移。對於每個受影響的工作流程，需要評估準備遷移（包括重新建立/重新編碼）所需的工作。相應的時間軸顯示準備新環境工作流程的整個過程將花費多長時間。在工作流程準備階段結束時，應該有一個詳細列表，其中包含所有工作流程、遷移工作和時間表以及每個工作流程的持續時間。
4.2.4.客製化解決方案準備
與工作流程準備階段非常相似，自訂解決方案準備階段都是為了準備用於遷移的自訂解決方案。客製化解決方案的類型對於決定遷移路徑至關重要。與工作流程一樣，第一個決定是自訂解決方案是否應在功能和/或使用者體驗方面進行更新/現代化。如果自訂解決方案正在更新或現代化，則很可能需要使用現代技術或現代平台（例如 Microsoft Azure）重新建置自訂解決方案。
如前所述，自訂解決方案的遷移路徑取決於自訂解決方案的方式
解決方案已建立。以下要點清單可能會有所幫助：
- 伺服器端程式碼： 透過合理的努力，這種類型的解決方案有可能遷移到本機 SharePoint。如果目標平台是 Microsoft 365，則需要重新建立基於伺服器端程式碼建置的解決方案，因為無法使用自訂伺服器端程式碼。
- 客戶端程式碼： 有很好的機會將此類自訂解決方案遷移到 SharePoint Online 或本機 SharePoint，但可能需要進行一些更新。
- 第三方解決方案： 最好的選擇是聯絡供應商，檢查是否有專用的遷移路徑。
4.2.5.規劃
評估和準備之後，需要製定詳細的遷移計劃。詳細的遷移計劃包括以下內容：
- 所選的遷移方法以及選擇特定方法的原因
- 需要遷移的所有網站和網站集的清單以及映射表（如果新結構與舊結構不同）
- 需要遷移的所有文件的列表，以及它們在舊環境和新環境中的位置
- 所有工作流程（現有的、重新建立的、新的）的清單需要存在於新環境及其位置。如果需要其他步驟（例如將工作流程重新連接到資料來源），則還需要新增這些步驟
- 所有自訂解決方案（現有的、重新建立的、新的）的清單需要存在於新環境及其位置中。如果需要其他步驟（例如將解決方案重新連接到資料來源或特定安裝說明），則還需要新增這些步驟
- 遷移期間需要執行的任何其他活動和依賴項
- 遷移每個步驟都有負責人的詳細時間表
4.3.遷移階段
現在計劃和準備工作已經完成；我們可以遷移內容、結構和解決方案。為此，我們需要使用遷移工具、有效溝通並遵循流程。
4.3.1。 工具
遷移意味著將內容從一種環境移動到另一種環境。儘管大多數內容可以手動移動到 Microsoft 365 或 SharePoint 2019，但使用專用移轉工具將很快獲得回報。
請記住，從 SharePoint 2016 或早期版本遷移到 SharePoint 2019 或本機也可能允許使用本機「升級」方法。因此，如果該選項對您的組織可行或可用，請務必探索該選項。通常，如果您沒有最新版本，則可能需要進行雙跳升級並解決在遷移中更好處理的其他複雜問題。除非您要從 2013 年遷移到 2016 年或從 2016 年遷移到 2019 年，否則我們建議使用遷移方法。
| 1。 手冊 |
2.微軟工具 | 3. 第三方工具 |
| ● 透過上傳手動移動內容 ● 免費 ● 對於大量數據，手動操作可能不可行。 files |
●內容透過SharePoint 移轉工具(SPMT) 移動 ● 免費 ● 不斷成長的功能集 ● 僅支援特定場景*（File 股票、SP2010、SP2013、SP2016） * 看 發行說明 |
● 內容透過工具（例如ShareGate、AvePoint、Metalogix）移動 ● Powertul 功能集（例如版本歷史記錄） ● 成本更高，但在大型、更複雜的遷移中很容易證明成本是合理的 |
主要缺點tag手動將內容移至新環境（透過瀏覽器拖曳、同步等）會遺失基本元資料。對於前amp文件：如果將文件從舊版本的 SharePoint 手動移至 SharePoint Online 等，則有關建立日期和作者的資訊可能會遺失。這是因為 SharePoint Online 可能會將遷移的文檔視為新文檔，因為提取的內容可能是今天「建立」的。如果需要保留基本元資料（建立日期、作者、編輯者、修改日期），通常必須使用專用的遷移工具。
對於手動遷移，有一些解決方法。如果使用者使用庫的同步功能並且元資料在 file 當他們將其拖放到同步資料夾中時，它將保留內容的元資料。這是幫助組織推出 OneDrive for Business 的常用方法，因為使用者可以使用同步功能並從其個人磁碟機中移動內容，同時仍保持上次修改日期不變。
除了上述保留基本元資料的支援之外，遷移工具還有其他優點tages.大多數遷移工具都包含遷移前檢查功能，可協助檢查潛在問題，而無需實際執行遷移。此外，大多數移轉工具都包含驗證功能。如果遷移工具報告遷移任務成功，則可以假設內容已遷移且沒有任何錯誤。這大大減少了驗證階段所需的工作量。
使用專用遷移工具的另一個重要原因是元資料支援。許多遷移工具可以自動將託管元資料從舊環境遷移到新環境。假設舊環境中的託管元資料結構與新環境中的託管元資料結構不同。在這種情況下，某些遷移工具提供了建立內部元資料映射的選項。
某些遷移工具透過提供軟體介面來為複雜遷移提供額外支持，該軟體介面可以利用 PowerShell 腳本來控制內容遷移方式或自動執行遷移任務。
在大多數情況下，建議使用專用的遷移工具。整合的遷移前檢查、整合的驗證和遷移結果報告將證明購買遷移工具的額外成本是合理的。
好消息是，微軟正在努力縮小這一差距並提供更好的體驗。 SharePoint 移轉工具已更新多次。如果您有 SharePoint 2013 Server、SharePoint 2010 Server 或 File 您想要移至 SharePoint Online 的共用。 SharePoint 移轉工具可讓您移轉清單或 file來自 SharePoint 本機文件庫或本機 file 共用並輕鬆將其移至 Microsoft 365 中的 SharePoint 或 OneDrive。
如果您處於非常不幸的情況，沒有支援從來源系統遷移的產品，那麼您將需要自行建立遷移工具。對於這些場景，請記住，Microsoft（和第 3 方）擁有出色的解決方案，可用於從 file 分享到 SharePoint Online 或 SharePoint 2019。
向供應商詢問的問題
了解供應商、他們的工具及其功能非常重要。以下是您在規劃 SharePoint 遷移以確定其產品擁有哪些功能時可能會詢問遷移供應商的問題清單。
技術供應商評估問題
以下是一些對於評估任何技術都很重要的簡單起始問題。
- 產品是什麼版本？
- 產品成熟度如何？
o 產品的支援生態系和供應商有多成熟？ - 產品的可擴展性和可自訂性如何？
- 產品的使用者友善性和可用性如何？
o 產品如何處理異常？
o UI 是為誰設計的？ - 管理和管理產品有多困難？
o 如何更新產品？
o 安裝有多複雜，依賴關係有多複雜？
o 它支援自動化嗎？ （您可以批次腳本或自動執行管理任務嗎？） - 還有誰在使用該工具？
o 他們對該工具的體驗如何？
o 他們有類似的需求嗎？ - 供應商如何提供支援？
o 供應商的支援聲譽如何？ - 產品適用性（基於產品概念驗證/演示）
- 詳細的價格建議（包括整合成本、支援和培訓的估算）
o 這些也應該考慮到您組織內的現有投資。
除了這些基本問題之外，您還可以深入研究特定的功能比較和功能分析。
複製 SharePoint 內容問題
- 複製 SharePoint 內容時 SharePoint 移轉工具如何運作？
o 是否允許使用者使用 OOTB SharePoint 介面複製內容？
▪ 防爆ample：透過 SharePoint 功能區？
o 是否允許使用者透過自訂介面複製內容？
▪ 能否對使用者進行培訓和/或提供存取此介面的權限？ - 該工具可以支援複製哪些 SharePoint 內容？
o 該工具是否瞭解現代網站/頁面，並且是否支援遷移到這些網站/頁面？
o 該工具是否支援複製一個或多個清單？
▪ 該工具是否支援在清單之間複製內容？
• 該工具是否支援複製列表 views?
o 該工具是否支援複製一個或多個庫？
▪ 該工具是否支援在庫之間複製內容？
• 該工具是否支援複製庫 views?
o 該工具是否支援複製附有附件的項目？
o 該工具是否支援複製或包含清單和庫項目上的版本 該工具是否支援複製文件集？
o 該工具是否支援複製頁面？
▪ 該工具是否支援複製 web 部分頁面？
▪ 該工具是否支援複製wiki 頁面？
▪ 該工具是否支援複製發布頁面？
o 該工具是否支援複製一個或多個站點？
▪ 該工具是否支援複製所有站點類型？
• 它是否支援複製團隊網站？
• 它是否支援複製發布網站？
• 支援複製部落格嗎？
• 是否支援複製Wiki？
o 該工具是否支援複製一個或多個網站集？
o 該工具是否支援複製網站集庫內容？
▪ 該工具是否支援複製頁面佈局？
▪ 該工具是否支援複製母版頁？
▪ 該工具是否支援複製清單範本？
▪ 該工具是否支援複製站點範本？
o 該工具是否支援複製樣式庫？
o 該工具是否支援複製網站內容類型？
o 該工具是否支援複製網站列？
o 該工具是否支援複製文件範本？
o 該工具是否支援複製 web 部分？
o 該工具是否支援複製以下欄位？
▪ 託管元資料字段
▪ 超連結字段
▪ 選擇字段
▪ 多值字段
▪ 企業關鍵字字段
▪ 個人或群組字段
▪ 日期、數字、貨幣、文字、註釋、複選框字段
▪ 查找字段
o 該工具是否支援複製權限？
▪ 該工具是否支援複製權限等級？
▪ 該工具是否支援複製組？
▪ 該工具是否支援複製繼承設定？
▪ 該工具是否支援複製唯一權限？
• 在文件/專案層級？
• 在資料夾/文件集層級？
• 在清單/庫層級？
• 在網站層級？
• 在網站集層級？
o 工具是否支援複製網站集管理員？
o 該工具是否支援複製/合併術語庫組和術語集？
o 該工具是否支援複製主題或外觀設定？
▪ 從2013 年到2013 年？那麼其他版本呢？
o 該工具是否支援複製站點設定/資料？
▪ 該工具是否支援複製網站導航？
o 該工具是否支援複製 InfoPath 表單？
o 該工具是否支援複製 InfoPath 表單內容？ （XML）
o 該工具是否支援複製工作流程？
▪ 該工具是否支援複製 OOTB（開箱即用）工作流程？
▪ 該工具是否支援複製SharePoint Designer 工作流程？
• 這是否包含複製可重複使用SharePoint Designer 工作流程的支援？
▪ 該工具是否支援複製SharePoint Designer 物件？
• 該工具是否支援複製DataFormWeb部分？
• 該工具是否支援複製自訂操作？
o 該工具是否支援複製警報？
重組和靈活性問題
- 該工具是否允許對現有結構進行重新映射或計劃改進？
o 該工具是否允許在複製過程中重新對應內容類型？
o 該工具是否允許在複製期間重新對應欄位（列）？
o 該工具是否支援在複製之前或複製過程中過濾內容？
o 該工具是否支援將 MS Office 屬性對應到 SharePoint 欄位？
o 該工具是否支援在複製過程中刪除現有資料夾結構？
o 該工具是否支援在複製過程中將資料夾名稱對應到欄位？
o 該工具是否支援在複製過程中將資料夾對應到文件集？
o 當欄位啟用「允許填寫選擇」時，該工具是否允許建立新欄位值？
o 該工具是否允許自動 tag複製過程中內容的變化？ - Example：基於欄位值、文件名稱等 - 將 XYZ 值指派給欄位 A。
o 該工具是否支援欄位類型轉換？
▪ 該工具是否支援將字串欄位轉換為人員或群組欄位？
▪ 該工具是否支援將字串欄位或選擇欄位轉換為查找欄位？
▪ 該工具是否支援將字串、選擇或查找欄位轉換為託管元資料欄位？
o 該工具是否支援在複製過程中重新對應使用者和群組帳戶？ - 該工具支援資料保存嗎？
o 該工具是否支援保存建立和修改的屬性？
o 該工具是否支援保留託管元資料欄位值？
o 該工具是否支援保存查找欄位值？
o 該工具是否支援保留核准狀態？ - 該工具在複製過程中是否提供重要的靈活選項？
o 該工具可以在複製過程中忽略必填欄位嗎？
o 使用者是否可以覆寫/指定用於由值建立/修改的帳戶？
o 該工具可以在複製過程中修復連結嗎？
o 該工具可以更改多個頁面的發佈頁面佈局嗎？
o 工具是否支援在複製過程中變更清單範本？
o 該工具是否支援在複製過程中變更網站範本？
o 該工具能否將網站提升到自己的網站集？
o 該工具可以大量核准或拒絕 SharePoint 專案嗎？
o 工具是否允許管理員根據正規表示式標準掃描內容 file沙 file 確定遷移範圍的屬性？
o 該工具能否在複雜結構中組合和嵌套條件/表達式以支援遷移範圍或重組工作？
o 該工具是否支援內容的增量或增量複製？
▪ 此支援有哪些限制？
自動化與管理問題
- 該工具是否支援使用腳本、命令列介面或透過 PowerShell 執行操作？
- 該工具是否支援根據遷移計劃安排和執行遷移？
- 該工具是否支援根據先前的遷移或計劃的遷移建立範本？
o 該工具是否支援建立欄位對應範本？ - 該工具是否支援利用 CSV 複製內容？
o 您可以使用此方法複製清單/庫嗎？
o 您可以使用此方法複製網站嗎？
o 此複製使用的 CSV 是否支援多個位置？
o 此 CSV 流程能否支持 tag物品/文件的管理 - 該工具是否為遷移中執行的作業/活動產生日誌？
- 該工具是否保留先前遷移的歷史記錄？
o 此歷史記錄是否記錄問題、警告、錯誤和成功？ - 該工具是否支援重新處理或遷移失敗的內容？
- 該工具是否允許對某些遷移活動/遷移處理進行優先排序？
- 該工具是否有安全的方式來儲存用於遷移活動的憑證？
遷移前支援問題
- 該工具是否支援預遷移過程？
o 工具是否提供遷移前報告？
▪ 該報告是否發現了廣泛清單中的潛在問題？
• 它是否確定了這些廣泛的清單在哪裡？
▪ 該報告是否發現了大型清單的潛在問題？
• 它是否能確定這些大列表的位置？
▪ 該報告是否發現了客製化方面的潛在問題？
• 它是否確定了這些客製化的位置？
▪ 該報告是否發現了工作流程的潛在問題？
• 它是否可以識別 OOTB、SharePoint Designer、自訂或第三方工作流程（例如amp樂：Nintex）？
▪ 該報告是否發現了大型資料庫或網站集的潛在問題？
▪ 該報告是否確定了可能需要遷移的正在使用和可用的內容類型？
▪ 此報告是否識別已使用的網站範本和清單範本？
• 這是否包括您的組織所建立的自訂網站範本/清單範本？
▪ 該工具是否提供權限、使用者、群組和權限等級報告？
• 該工具是否支援掃描權限繼承被破壞的內容？
▪ 該工具是否提供內容報告 file 股票？
o 工具是否提供詞彙、分類或概念報告？
▪ 這樣做是為了幫助改善元資料的開發還是開發託管元資料儲存？
▪ 能否利用此報告在遷移時分配元資料？
o 該工具是否能夠偵測 PII（個人識別資訊）、PHI（受保護的健康資訊）和其他內部隱私數據 files?
遷移後支援問題
- 該工具是否提供比較報告或比較功能？
o 這是否允許比較網站、清單和項目之間的權限？
▪ 這是否允許比較兩個單獨網站集中的網站？
o 這是否允許比較網站集、網站、清單和資料夾內容？
▪ 這是否允許比較兩個網站集、網站或清單中的內容類型和欄位？
• 這是否也允許比較列值（元資料）？
o 該工具是否允許比較兩個伺服器集區之間的術語庫？
o 您能否根據比較報告的結果啟動遷移或複製/同步？
技術支援問題
- 遷移工具支援哪些版本的 SharePoint？
o 工具是否支援 SharePoint Online (Microsoft 365)？
o 工具是否支援 SharePoint 2019？
o 工具是否支援 SharePoint 2016？
o 工具是否支援 SharePoint 2013？
o 工具是否支援 SharePoint 2010？
o 工具是否支援 SharePoint 2007？
o 工具是否支援 SharePoint 2003？ - 該工具是否支援交互 File 系統？
o 該工具是否支援上傳 file是從 File 系統？
▪ 該工具能否將NTFS 屬性對應到SharePoint 欄位？
▪ 該工具能否在上傳過程中自動修復非法字元？
• 該工具是否允許自訂非法字元替換？
▪ 該工具可以在上傳過程中忽略必填欄位嗎？
▪ 該工具可以自動 tag 根據條件上傳期間的內容？
• 條件是什麼或 tag有可用的選項嗎？
▪ 該工具能否在上傳過程中將資料夾轉換為文件集？
o 該工具是否支援下載 file到 File 系統？ - 該工具是否支援與電子郵件和 Exchange 資料互動？
o 工具是否支援將郵件信箱和公用資料夾資料複製到 SharePoint？
▪ 該工具是否支援使用CSV 將多個郵箱和公用資料夾複製到SharePoint？
▪ 該工具是否支援將 Outlook PST 檔案複製到 SharePoint？
▪ 該工具是否支援將電子郵件和公用資料夾屬性對應到SharePoint 欄位？
▪ 該工具是否支援將Exchange 公用資料夾權限複製到SharePoint？
4.3.2.溝通
如果沒有員工的參與，遷移就無法完成。儘管只有少數員工積極致力於遷移，但組織中的每個人都需要了解遷移、時間表以及遷移對日常業務的任何影響。
建議定期向組織的所有使用者發送通知，以使他們了解有關遷移計劃的最新資訊。
無論是分階段執行還是一次性執行，都需要在遷移活動之前通知受影響的用戶。每個通知應包含以下資訊：
- 將要執行的遷移活動的描述，包括時間表
- 受影響的資料/受影響的網站或網站集
- 遷移活動的預期結果
- 權限變更（例如特定網站將轉為唯讀模式）
- 指向新環境和遷移內容的鏈接
- 專職聯絡人
每次遷移都會對業務和員工的日常工作產生影響。每次遷移的主要目標應該是將對業務的影響降至最低。這可以透過徹底規劃遷移、讓員工參與以及清晰和主動的溝通來實現。
4.3.3.遷移過程
有兩種遷移方法（已在 3.2. 遷移 節中介紹）：一次性方法（有時也稱為大爆炸方法）和分階段方法。使事情變得複雜的是，有時一次性方法在幕後被處理為分階段方法。
讓我們澄清一下這一點。在考慮遷移方法時，我們需要區分使用者如何看待遷移以及內部如何執行遷移。
讓我們從使用者如何看待遷移開始。對使用者來說，一次性方法是這樣的：在星期五，現有系統變成唯讀模式，在週末，舊系統遷移到新環境。週一早上，用戶使用新環境繼續日常業務。儘管這只能在較小的環境中完成，但這種遷移方法的使用並不少見。許多中小企業正在使用這種方法。
如果使用分階段方法，使用者將認識到遷移是由業務實體（如逐部門）完成的。通常，這種方法對業務的影響比一次性方法小。儘管如此，這仍然需要更長的時間，這就是大型組織使用這種方法的原因。
當審視遷移過程本身（遷移的技術過程）時，我們將再次看到這兩種方法。一次性方法通常用於透過專用遷移工具將單一網站集遷移到新環境。本質上，這意味著遷移工具用於進行直接遷移，或者換句話說：遷移工具用於在新環境中建立舊環境的精確副本。
分階段的方法意味著從技術角度來看，逐一站點遷移到新環境。這也包括由於目標環境的資訊體系結構與來源環境不同而遷移到不同網站集的網站。在這種情況下，網站會分批遷移和驗證——通常按複雜性確定優先順序。
有了前面的解釋，我們再回到本節開頭的那句話。
對於用戶來說，遷移看起來像是一次性（或大爆炸）方法，而從技術上講，執行遷移的團隊使用的是分階段方法。
無論哪種方式，該方法仍然利用遷移批次，每個遷移批次都會在成功遷移後進行驗證。
我們（通常）還追蹤每批遷移的驗證、切換和變更管理支援。
4.3.4.遷移持續時間
無論採用哪種方法，規劃對於任何類型的遷移至關重要。在開始遷移內容之前，應多次檢查遷移計劃，並且還應多次驗證時間表和里程碑。
在規劃時間表時，建議為不可預見的情況或中斷增加一些時間。這是一個前任ample：根據經驗，我們 2toLead 計算到 SharePoint Online 的遷移的平均傳輸速率約為 5 GB/小時。假設無論出於何種原因，傳輸速率都低於您執行遷移當天的預期。在這種情況下，較低的傳輸速率造成的延遲將對時間軸產生負面影響。這個基本的前amp該文件顯示了擁有詳細且經過驗證的時間表以及大量細節和里程碑的重要性。在遷移過程中，需要非常密切地監視和控制時間線，並且對於每個里程碑，如果無法達到里程碑，則需要有一個回退計劃。
遷移到 SharePoint Online 等 SaaS 服務時最具挑戰性的事情之一是，由於基於使用情況和複雜模式的限制，無法準確預測遷移持續時間。許多因素會影響遷移所需的時間或遷移持續時間。其中一些因素是可以管理的，而另一些則超出了遷移團隊的控制範圍。以下是嘗試預測場景中的遷移速度時的一些簡單最佳實踐：
在鎖定時間表/日期之前，至少測試幾次遷移速度。
估計遷移速度最簡單的方法是透過測試收集預期速度的見解和證據。請記住，即使您進行了測試，遷移持續時間也可能存在波動的原因。作為前任ample，遷移持續時間預測可能會根據測試的大小而波動 file 尺寸。所以，擁有各種 file 類型是最好的，並且對持續時間進行範圍估計至關重要。
了解節流和速率限制的工作原理。
SharePoint Online 是一個 SaaS 解決方案，並且是一個多租用戶環境。為了確保共享硬體/服務上所有客戶的服務質量，他們實施限製或速率限制。 SharePoint Online 限制引擎是動態的。有時遷移處理可能會消耗更多資源，有時可用資源卻少得多。必須進行顯著的限制才能保持環境對所有租戶做出回應。
如果您要移轉到經常使用的目標 SharePoint Online 環境，這尤其具有挑戰性。在「綠地」場景中，遷移更容易預測，但在活躍使用的環境中，時間軸和持續時間可能會顯著波動，並且更難以預測。請記住，如果您有大量的批次或集合需要遷移，可能需要數月或數年的時間才能遷移，這將進一步帶來挑戰，因為隨著更多用戶過渡到線上租戶，在線租戶的使用量將隨著時間的推移而增加。
來源系統和遷移硬體可能會影響持續時間。
來源系統和遷移硬體的品質會對持續時間產生正面或負面的影響。對於老年人來說這是很常見的 file 由於效能不佳或硬體較舊，共用或遺留文件管理系統會影響整體遷移吞吐量。
4.4.測試/驗證階段
遷移內容時，應進行一致且頻繁的測試。自動化測試和用戶主導的測試都適用。
4.4.1.內容驗證
SharePoint 內容主要分為三種：結構化資料（如清單和行事曆）、文件和頁面。
如果使用專用移轉工具，則該移轉工具很可能包括驗證功能。這意味著使用遷移工具遷移的文檔（和頁面）不需要單獨驗證。如果驗證工具報告文件已被移轉和驗證，則幾乎不需要再次手動驗證文件。
SharePoint 頁面會以 ASPX 文件儲存到特定文件庫。儘管它們可以被視為文檔，但與常規文檔有一個顯著的區別。 SharePoint 頁面可以託管應用程式和 web 部分。大多數遷移工具都可以遷移動態內容（例如應用程式和 web 部分）到新環境，但他們無法在功能和配置方面驗證它們。這意味著每個遷移的 SharePoint 頁面都需要手動驗證，其中包括每個嵌入式應用程式或 web 部分。
4.4.2 工作流程的驗證
專用遷移工具還可以將工作流程從舊環境遷移到新環境。對於 OOTB 工作流程和 SharePoint Designer 工作流程也是如此，並且取決於遷移工具 - 包括基本驗證。但是，這並不意味著所有遷移的工作流程都將在新環境中毫無錯誤地運作。
通常，工作流程是根據其功能的詳細描述建立的，包括圖表和測試說明（例如，使用者驗收測試）。建議以與部署到舊環境之前測試相同的方式再次測試任何遷移的工作流程。這意味著在遷移到新環境後，可以重複使用現有的測試指令來測試工作流程的功能。
基於特定遷移路徑遷移的工作流程（如第 3 方工作流程）將需要類似的驗證。儘管如此，可以假設製造商已經測試了第三方工作流程的基本功能。
4.4.3 客製化解決方案的驗證
自訂解決方案的驗證與自訂工作流程的驗證類似，如上一節所述。假設自訂解決方案從 SharePoint 本機遷移到較新版本的 SharePoint 本機（例如 SharePoint 2019）。在這種情況下，客製化解決方案很可能會在新環境中工作，只需較少的手動調整，但這並不能忽視驗證的需要。
假設自訂解決方案遷移到相同類型的環境（例如從本機 SharePoint 遷移到本機 SharePoint）。在這種情況下，可以根據舊環境中使用的測試說明來驗證遷移的自訂解決方案。有時，舊的測試說明需要進行一些更新才能將其調整到較新（和現代）的環境。
從本機環境遷移到 SharePoint Online 的自訂解決方案之前通常已重新編碼或重新創建，這意味著它們需要完全通過測試。
4.5.遷移後階段
遷移後階段經常被忽視，因為組織不知道此階段需要採取的行動及其重要性。 
4.5.1.使用者培訓
即使遷移只是遷移到新環境（不改變任何結構），使用者也需要量身訂製的培訓，至少針對新平台。
如果沒有適當的使用者培訓，遷移所提供的許多好處就會被破壞。在前面的一節中，我提到企業內部網路可以被視為員工用來處理日常業務的工具。如果更換工具，則需要進行培訓以確保以盡可能高的效率使用新工具。
通常，有三組使用者需要客製化培訓：
- 管理員
- 網站所有者
- 普通用戶
應仔細規劃針對所有上述群體的培訓課程。對於較大的組織，每年提供多次使用者培訓是有意義的，以確保新員工盡快接受適當的培訓。對於較小的組織，可以記錄初始使用者培訓。新進員工在入職期間將可以存取這些錄音。
使用者培訓不應僅由 IT 部門提供。通常，讓外部專家（如專業主持人）參與培訓課程是有意義的。
4.5.2.用戶採用規劃
用戶採用至關重要的原因主要有兩個。任何組織都必須能夠衡量員工如何使用遷移的入口網站。這是一個前任ample：我們假設遷移的原因之一是提供改進的搜尋體驗並使使用者能夠快速檢索文件。在這種情況下，衡量使用者採用率（以及遷移成功）的一種方法是監視搜尋查詢的數量或不傳回任何結果的搜尋查詢的數量。衡量這些成功標準並不難（因為有免費的 Microsoft 365 使用者採用內容包），但要找出檢索到的分析結果以及從中得出的結論，可能會困難得多。
關於使用者採用的一項重要行動是在執行遷移後至少持續衡量已確定的成功標準，並從檢索到的分析中推斷出適當的操作，以確保遷移保持成功。
4.5.3.伴隨行動
除了使用者培訓和採用規劃之外，還有其他行動。這些行動包括（但不限於）以下內容：
- 服務台： 即使員工參加了適當且量身定制的使用者培訓，使用者也會對功能或業務流程提出其他問題。遷移後為用戶提供幫助非常重要，用戶應該知道如果有疑問、想要報告錯誤或只是想提供回饋應該聯繫誰。忽視幫助台的重要性可能會導致使用者接受度降低。
- 收集回饋： 收集回饋不是遷移後立即採取的一次性行動，而是一個持續的過程，包括評估回饋以採取旨在抵消任何負面發展的行動。
- 吸引用戶： 新的企業內部網路通常提供促進用戶參與並鼓勵用戶擴大企業網路的機會。有些用戶可能需要額外的鼓勵才能如預期般使用新的公司內部網路。促進用戶參與的一種方法是利用遊戲化的想法。前任ample就是發布問卷或競賽，向使用者展示如何好玩地使用新的企業內部網路。
4.5.4.修復損壞的鏈接和參考鏈接
從一個內容儲存轉移到另一個內容儲存時， URL 模式可能會改變。這可能意味著在 SharePoint（或來源系統）中相互引用的文件不再能夠正確解析這些連結或連接。好消息是，許多第三方解決方案可讓您掃描並識別損壞的連結。這些工具通常還允許您使用這些工具替換或修復那些損壞的連結。
如果您的團隊覺得可以輕鬆完成這項工作，您甚至可以自己使用程式碼或 PowerShell 來完成此操作。對於前ample，這篇堆疊溢位文章參考瞭如何寫PowerShell來尋找和替換 URL在 Excel 公式中批次使用。
成功的風險
有幾個因素可能會影響專案團隊和外部利害關係人對內容遷移工作的成功感知。
- 技術變革與組織變革 – 在大多數組織中，您不僅僅是將相同的結構從來源提升到目標。在您認為專案已完成或成功之前，您通常會在內容遷移期間或「之後」進行最佳化、重組或改進。這裡的困難在於，技術遷移專案通常範圍廣泛，通常按預算運行，並且通常按時完成。不幸的是，組織變革/重組和優化工作的範圍通常很差，變更範圍更頻繁地超出預算，並且通常需要更長的時間（延長了許多遷移專案的時間表）。我們強烈建議將它們視為兩個項目。遷移專案和資訊/SharePoint 最佳化專案。這樣，您可以更好地管理最佳化項目，這與更明確的技術遷移項目不同。 Additionally, once you move to the cloud, you will still need to perform these optimization projects from time to time (like every few years our industries, companies, processes, and more change – requiring investment if we want to get the most out of our資訊).
- 一般期望 – 在任何專案中，內容遷移都是一項非常乏味的任務，需要仔細觀察並致力於所需的工作。很多時候，人們的期望是內容可以輕鬆移動view 或事後介入。鑑於網站重新設計包括將內容移至新位置，採取先進的tag新的功能和功能，以及外觀和感覺的整體改進，這不是一個公平的期望。專案團隊通常非常清楚這些並且有適當的期望。然而，僅要求進行遷移的外部利害關係人或團隊成員可能不會有同樣程度的低估。確保期望與所有群體保持一致對於遷移的成功至關重要。
- 何時重新內容view – 確定最佳或最有效的內容重新view 時機往往會成為一個問題。鑑於其耗時的性質，很難說服外部利害關係人重新view 提前將其內容移至新網站以確保其值得轉移。有一種常見的誘惑是：“我們將把當前網站遷移到新的系統/服務中，這樣清理起來會更容易。”
不幸的是，這在實踐中很少起作用。一旦新網站上線，清理內容的壓力就會消失，頁面會被孤立，內容更新會集中在現在和未來，而不是過去。如果選擇這種方法，至少可以確定哪些內容可以保留以“稍後清理”，從而最大限度地利用昂貴的遷移資源，並製定解決“遺留問題”的策略。
雖然在移動之前進行調整可能是最佳選擇，但 SharePoint 的新技術具有很大的價值。在許多情況下，搜尋、使用分析等都有助於提高舊的和未使用的可見性。對於前ample，如果一個組織正在從 file 分享到 SharePoint，他們無法判斷哪些內容仍在使用 view編輯。不過，一旦您進入 SharePoint，您就可以證明某些內容是否已被刪除。 view編輯，因為它已被遷移，以最終在適當的情況下刪除/刪除它或存檔它。 - 選擇正確的方法和工具 – 初步分析內容並定義遷移方法。遷移方法和遷移工具應與內容的數量和規模以及目標環境要求相符（Microsoft 365 ex）amp樂）。選擇錯誤的工具或在開始遷移之前未選擇工具可能會導致大量的返工。
- 確保您已將內容分解得足夠多 – 假設您使用移轉工具；您必須將內容分成不同的部分並為內容分配所有者。整理所有內容。我們使用了電子表格、SharePoint 列表，甚至可以使用 Access DB，這樣您就可以在一個位置管理所有內容。如果不這樣做，那麼詳細程度就不夠具體或不夠深入，並且通常會錯過應該評估或測試的關鍵領域，直到遷移之後，有時甚至是網站啟動之後。平衡故障的詳細程度以及合理的重新調整view 可能具有挑戰性。最理想的情況是，始終根據時間表、預算和資源限制盡可能地進行分解。
- 驗證目標準備狀況 – 驗證配額和儲存是否足夠大，您有足夠的許可，並確保在遷移之前確認特性/功能未受到限制、關閉或停用。這應該在評估階段儘早完成，因為在大型全球組織中調整這些設定/配置可能需要相當長的時間。
不要低估驗證頻寬、身分、安全性以及其他可用且準備好遷移的配置的重要性。 - 測試遷移並獲得範圍持續時間估計 – 執行模擬遷移並測試結果以確保內容能夠傳達。這也是預測遷移需要多長時間的最佳方法。測試遷移應該在您的系統中。這有助於識別可能阻礙遷移（但超出使用者控制範圍）的任何安全性、使用者帳戶或網路問題。
總是預期遷移會花費更長的時間，並保守地預算您的時間安排，這樣當隨著越來越多的用戶訪問目標系統而導致遷移花費更長的時間時（尤其是較大/較長的遷移），您就不會感到驚訝。 - 遷移簽核 – 如果可能的話，在您的 IA 被（內部）客戶端鎖定、實施和簽署之前，您不想開始遷移。如果你開始得太早，你就會得到一個移動的目標，並且因為協調和沒有為新的影響做好計劃/準備而遇到額外的失敗。在緊迫的期限內，有時內部客戶可能會要求盡快開始（在您準備好之前），但這並不可取。採用增量簽核的增量方法通常可以減輕這種風險。
如果您必須加快遷移時間表，請務必在遷移後包含強制的最佳化/額外支援後續階段（假設您可以在預算方面發揮創意）。
重點
成功的遷移利用本白皮書中列出的最佳實踐（在遷移過程之前、期間和之後）。與任何遷移一樣，您需要對遺留系統以及它將如何對應到 SharePoint 進行適當的規劃和分析。您需要為新內容和用途準備目標環境。您需要確保遷移導致盡可能少的用戶中斷。最後，您需要確保新的 SharePoint 架構能夠確保當前和未來更好的體驗。
- 投資於更了解您的內容及其當前的使用方式。
- 投資更多的遷移規劃，以實現更成功的遷移。
- 在支持、採用和變更管理等遷移後活動上投入更多資金。
- 不要單獨或在沒有專家的情況下完成這項工作，從而投資更多的專業知識。找一個曾經做過這件事並且知道會發生什麼的朋友或伴侶。
這並不總是那麼容易，因此我們盡力分享一些可能對您有幫助的指導。在此之前，我們所有團隊和更廣泛的 SharePoint 社群祝您遷移順利。
筆記： 我們在本白皮書中盡量不強調我們的服務，但這是我們熱衷並為許多組織提供幫助的主題。請隨時給我們留言 你好@2toLead.com 如果您有興趣從我們的專家團隊獲得一些額外的建議或幫助；問一問總無妨。
資源
我們運用多年的專業知識來整理這些白皮書。我們從我們屢獲殊榮的努力中以及與 Microsoft 365 社群的朋友們一起學習。我們想在下面的部分中重點強調這兩點。
7.1.我們的白皮書及相關資源
我們的一些受歡迎的（且全面的）白皮書：
最常見的 SharePoint 和團隊蔓延問題以及如何找到它們
這本電子書 涵蓋了組織當今面臨的 8 個最常見的蔓延問題。這些問題困擾著世界各地的組織，解決這些問題對於增加員工時間和成本至關重要。您不僅將深入了解解決這些問題的方法，還將了解為什麼這些問題對 IT 和最終用戶都很重要。
核心電子書主題
- 了解數位化工作場所的蔓延
- 最常見的蔓延問題以及如何解決它們
Microsoft 365 內部網路：您需要了解的內容
這 160+頁白皮書 擁有成功利用 Microsoft 365 內部網路和數位工作場所所需了解的一切 amp將內部溝通與協作提升到新的高度。
核心白皮書主題
- 了解 Microsoft 365 通訊與協作工具
- Microsoft 365 Intranet 與數位工作場所的優勢
- 技術、設計和領導力的最佳實踐
使用 Office 365 進行外部分享：您需要了解的內容
這 30+頁白皮書 概述了在 Office 365 中啟用外部共用以及您可能想要配置或擴展這些功能的時間/地點時的所有關鍵決策以及如何做出這些決策。
會發生什麼
- 外部共享決策與指導
- 外部共享和外部用戶路線圖
Office 365 中的“何時使用什麼”
這 70+頁白皮書 是為 Office 365 提供正確的企業使用者指導的指南。
會發生什麼
- 何時使用哪種工具：選項、場景建議和範例amp萊斯
衡量 Office 365 的業務影響和投資報酬率
這 60+頁白皮書 概述了許多有關如何衡量 Office 365 對業務的影響的關鍵考慮因素，同時也概述了 Office 365 如何提供當今有效的報告功能。
會發生什麼
- 理解並調整業務目標
- Office 365 能力映射的業務影響和投資報酬率
- 業務影響和投資報酬率計算和測量Examp萊斯
推動 Office 365 的採用與使用：您需要了解的內容
這 70+頁白皮書 概述了規劃和改進 Office 365 技術和最終用戶採用時的所有關鍵注意事項。
會發生什麼
- 推動採用最佳實踐
- 關於建立有效採用 C 的綜合指南amp對準
- 領養活動清單
許多其他優質資源和服務amp這些文件可以找到並定期發佈在我們的資源網站上： http://Office365Resources.com.
7.2.推薦產業觀點
關於 Intranet 的新功能、創新內容以及屢獲殊榮的 Intranet 的構成要素，有許多精彩的報告和文章。您是否正在尋找關於什麼是好的 Intranet 的更有趣的觀點？請務必查看流行年度報告中的最新趨勢，例如 Nielsen Norman 關於 Intranet 設計的報告, 第二步關於內部網路創新的報告，非常值得一讀。我們很榮幸地匯集了 Neilson Norman、Step Two 和其他各種獎項得主以及其他令人難以置信的行業專業人士組成的團隊。
向其他行業專家致敬
正如我們所提到的，我們也與一些才華橫溢的專家一起了解到，我們在整個社區或全球許多 Microsoft 365 活動中不止一次與他們有過接觸。我們想在這裡對他們進行重點介紹。
蘇珊·漢利
「Sue 是設計、開發和實施成功入口網站解決方案的公認專家，尤其擅長 Microsoft SharePoint。自 2015 年以來，Sue 一直被評為 Microsoft Office 應用與服務 MVP。她經常就構建有效的協作門戶、門戶治理、用戶採用和資訊架構以及建立實踐社區和衡量知識管理投資的價值等主題發表文章和演講。
米哈爾·皮薩雷克
「Orchestry Software 執行長 Michal Pisarek 是 Microsoft SharePoint MVP，該獎項頒發給 Microsoft SharePoint 社群中的專家，以表彰他們分享的熱情、技術專長和實際知識。他被公認為 SharePoint 領域的思想領袖，經常在許多國際活動中發表演講，並在 Gartner 和 StepTwo 等組織的出版物和演示中被引用。
喬安妮·C·克萊因
Joanne 關注的一個關鍵領域「…是 Microsoft 365 工具，旨在幫助組織保護、保留和保障其正在以指數速度產生的非結構化內容。對於組織及其資訊工作者來說，這是在當今現代數位工作場所中需要做出的重要轉變。
弗拉德·卡特里內斯庫
「Vlad 自 2013 年以來也是 Microsoft 最有價值專家 (MVP)，並擁有自己的部落格： https://VladTalksTech.com。他還透過在全球會議和當地社區活動中發表演講來分享他的知識。弗拉德經常被認為是其他行業相關的專家 web網站和部落格。
關於2toLead
2toLead 被其客戶和員工稱為慷慨的 Microsoft 顧問公司。 2toLead 聘用值得信賴、充滿熱情且經驗豐富的顧問，他們努力解決客戶面臨的最具挑戰性的業務和技術問題。
得獎經驗，隨時為您提供協助
無論您是要重振 Microsoft 365 數位工作場所還是考慮開始您的旅程，Microsoft 365 都是改善數位通訊和協作的必由之路。
開箱即用的 Microsoft 365 已經是朝著正確方向邁出的一大步，但進階功能tag如果有適當的指導，es 可能會達到天文數字。我們很樂意成為幫助指導您實現最佳數位工作場所的顧問。我們的團隊已準備好向您展示「您會喜歡我們的工作方式。一起。
3toLead 幫助客戶的 2 種主要方式
提高採用率 不僅是正確部署，還要確保您的組織積極主動地從技術投資中獲得最大價值。
改善體驗和參與度 透過了解用戶在何處、如何以及為何與您的企業互動，同時建立世界一流的入口網站、社交網路和 web您的客戶、合作夥伴和使用者喜愛的網站。
利用雲端 透過利用 Office 365 和 Azure 等雲端技術來降低成本、提高組織內部和外部的業務敏捷性和能力。
欲了解更多資訊：
- 訪問我們的 web站點位於 www.2toLead.com
- 在 LinkedIn 上關注我們
- 在 Facebook 上為我們按讚
- 在 Twitter 上關注我們@2toLead
坎瓦爾·基普爾
Kanwal 是 2toLead 的創辦人兼首席執行官，也是 SharePoint 業界領先的使用者體驗專家，在建立採用先進技術的屢獲殊榮的入口網站和解決方案方面擁有豐富的經驗。tagMicrosoft 雲端平台（SharePoint、Microsoft 365 和 Azure）的 e。 Kanwal 作為專案創意和技術領導者對成功的推動使他獲得了 Neilson Norman 十大內部網路獎（10 年和 2014 年）。
Kanwal 的熱情在於在為世界上大多數最大的品牌重新設計內部網路時繼續推動用戶體驗創新。他繼續宣揚以可用性為主要焦點的設計的重要性。 Kanwal 對分享知識的渴望使他成為 SharePoint 社群中的傑出人物。由於他對許多社群驅動的活動的熱情和參與，包括在加拿大和美國建立成功的使用者群組，Kanwal 被 Microsoft 評為 SharePoint MVP（2009 年至 2020 年）和 Microsoft 365 MVP（2014 年至 2021 年） 。他也合著了一本有關 Pro SharePoint 2013 和 Responsive 的書 Web 發展 http://amzn.to/sp2013rwd
如果您想討論您的專案、想由他來實施一個想法，或只是想聯繫一位友好的技術專家，請隨時與他聯繫。
http://www.twitter.com/kkhipple
www.LinkedIn.com/in/KanwalKhipple
www.Slideshare.net/kkhipple
+1-416-888-7777
Kanwal@2toLead.com
理查德·哈布里奇
Richard 是 2toLead 的技術長和所有者。理查德作為數百個組織值得信賴的顧問，幫助他們了解當前的需求、未來的需求以及為發展和實現大膽抱負而應採取的行動。
Richard 仍然親力親為，領導、架構和實施了數百個業務和技術解決方案，幫助組織數位化和組織轉型。理查德熱衷於幫助組織取得更多成就，無論是幫助組織建立美麗的 web網站支援精彩的內容和社交策略，或幫助組織利用新興的雲端和行動技術來更好地服務其會員或他們所服務的社區。
Richard 是一位作家，也是 Microsoft 技術、行銷和專業服務領域的國際公認專家。作為一位廣受歡迎的演講者，理查德經常有機會在全球眾多行業活動中分享他對品牌、合作夥伴管理、社交網絡、協作、投資回報率、技術/流程採用和業務發展的見解、經驗和建議。當不在行業活動中發言時，Richard 會作為業務和技術顧問與 Microsoft、合作夥伴和客戶合作，並在多個委員會任職、領導用戶組，並且是 Microsoft 社群領導委員會的董事會成員。
http://www.twitter.com/rharbridge
http://www.LinkedIn.com/in/rharbridge
www.Slideshare.net/rharbridge
+1-416-300-3678
richard@2toLead.com
只是開始
我們已經幫助 100 多個組織建立了更強大的內部網路和內部通訊。
在多位 Microsoft MVP 和 Neilson Norman 獎得主的指導下，我們很樂意向您展示如何提升您的內部網路和數位工作場所。
您的數位工作場所之旅始於對您的數位工作場所進行 2 小時免費評估，無需承擔任何義務或承諾。
順利遷移的第一步
您一定會喜歡我們的工作方式。
一起。
文件/資源
 |
SharePoint 移轉到 Sharepoint Online 和 On Prem [pdf] 使用者指南 移轉到 Sharepoint Online 和 On Prem, 移轉到 Sharepoint Online 和 On Prem, Online 和 On Prem, On Prem |