Teams到Teams的遷移：遷移前，資料分析怎麼搞？
對源端資料探索發現的過程對資料移轉來說尤為重要，一天之計在於晨，良好的開始，等於成功的一半。
提到資料移轉，我們往往都更傾向於關注遷移什麼內容、其存儲在哪裡、所有者、結構以及重要程度，但是全面完整的Teams到Teams的遷移還應該考慮到資訊架構、配置、權限、使用者和授權等等。
遷移前期對資料的探索過程包括：
- 檢查您的專案需求和能力，確定您將使用哪個供應商，只遷移您自己的租戶，還是包括外包服務？
- 可以選擇試用AvePoint的遷移工具 FLY，零費用、自動化探索您的資料與內容。
- 利用遷移前的內容分析報告來確定哪些內容需要被帶走，哪些需要斷舍離。
- 存取源租戶和目的端租戶的管理中心，記錄設置並注意差異，或利用類似Elements Pro（測試版）的解決方案。
- 存取Microsoft 365管理中心，流覽計費單元，查看分配給個人用戶的授權數量。 注意：如果您想深入瞭解普通授權和高級授權是如何被使用的，Cense這樣的工具可以説明您優化目的端租戶的授權分配與預算。
決定您的遷移方式
如果您需要遷移文件和郵箱以外的內容，微軟的免費雲遷移工具或腳本並不適合您。如果您想遷移高級工作負載，比如Teams 對話，那像AvePoint這樣的供應商將會是您的首選，利用Microsoft Import API，遷移資料的準確度與延展性都將得到保障。
一些供應商，如AvePoint，可以遷移Teams選項卡和Wikis，但某些類型的應用程式或定制可能必須在新環境中重新構建。 如果您的日程緊張，或是您的團隊行無餘力，AvePoint提供的遷移服務很有可能會是最佳選擇。最後，AvePoint是為數不多的能夠遷移Planner或私人對話的供應商之一。
內容和工作流的注意事項
影響遷移的因素有很多，但是專案的數量（頻道、使用者、任務、執行緒對話等）以及相關檔的大小將決定遷移作業的時長，而如何分配取決於您的組織結構和內容的重要性。
將冗餘、過時或瑣碎的資訊排除也是資料移轉的一部分，這可以極大地減少遷移的時間和成本。根據需求對這些資訊進行歸檔或刪除（大多數組織選擇歸檔）。
需要注意的是：重構關鍵的業務流程、工作流、應用程式，以及糾正無主Teams產生的問題，或者處理敏感性資料，這些都會增加遷移作業的時長。有了AvePoint FLY，只要目標環境中存在配置好的相應的敏感性標籤，那麼資料移轉時，源端數據的該項設置也將被保留。
資訊架構注意事項
在啟動Teams到Teams遷移之前，應該三思而後行。 這是因為您不是將共用的協作建構移動到雲，而是將兩個協作建構合併在一起——如果不弄清楚結合的方式，您將得到一個混亂的環境，而這會影響用戶的生產力、採用率和滿意度。
例如，源端和目的地可能有兩種不同的命名規則； 一個可能將業務單元作為首碼，而另一個可能根據敏感性。 因此，租戶A中的公共關係團隊可能是MKT Public Relations_External，而租戶B中的同一團隊可能被標記為Confidential Public Relations_External。針對常見的映射設定和合併類型，命名規則需要進行修正的同時，還要對用戶進行培訓。
您可以在遷移過程中使用像FLY這樣的工具來完成這種任務，同時考慮利用像AvePoint Cloud Governance或Policies & Insights這樣的治理工具來幫忙，它可以在Group和Teams的創建和生命週期管理中強制執行命名規則。
想要查看Teams結構的資訊，您可以使用FLY或通過Microsoft Teams管理中心。
設置和權限的注意事項
對於許多組織而言，如果讓他們主動考慮治理和安全性，他們的第一反應是假定源租戶中的設置和策略將被目的端租戶中的設置和策略覆蓋。這種想法在並購驅動的遷移中尤其普遍，但其實並不是這麼簡單。
如果一個Microsoft Teams的環境配置不同，可能是因為法律或監管原因。 例如，源租戶中可能含有內容受 ITAR限制的Teams，這些內容需要更嚴格的外部共用策略。
雖然Microsoft 365和Microsoft Teams確實有許多“一個租戶一個規則”的設置，但像AvePoint Cloud Governance這樣的協力廠商工具可以根據不同工作組的需要對這些設置進行調整。無論哪種方式，理解、評估和糾正目的端和源環境配置之間的差異都是必須的。
另外，如果源租戶的設置過於鬆散（假設啟用了匿名連結），則可能需要以更相容的方式評估和處理敏感性資料權限。最好的辦法還是在遷移之前就修復源租戶中的權限問題。
