分析工具選取項目和移轉模型的決策準則
我們現在已探索移轉方法的選項和工具選項，接著可探索需要考量的決策準則以執行適用於 PostgreSQL 的 Azure 資料庫移轉。 有助於決策的三個主要準則是停機時間、來源資料庫位置和自訂功能性。
停機
停機時間是移轉作業的關鍵面向，專案關係人可接受的持續時間可協助我們決定是否必須執行離線或線上移轉作業。
一般而言，移轉作業會事先規劃，以確保已完成作業的適當變更控制和相關管理。 此規劃可允許與關鍵專案關係人進行對話以了解系統離線的時間長度。 在此情況下，建議您了解不同選項建立預估最短和最大停機持續時間的長度。
建立執行應用程式完全移轉的最低停機時間是關鍵。 最後，此時間是系統離線所需的時間長度，即使是線上 (或最短停機時間) 移轉作業。 應用程式的複雜性將決定此時幅。 針對相對簡單的應用程式，此程序的情況可能是停止服務、更新設定檔，然後重些開啟。 在較複雜的環境中，若有多個伺服器和應用程式層，則此程序可能需要更長的時間。
了解線上或離線移轉作業所需的持續時間是後續與停機時間相關重要因素。 若是離線移轉，則驗證與確認後將資料自來源擷取、傳輸和載入至目的地所需的時間是您的停機時間。 然後，此停機時間介於關閉應用程式/工作負載所需時間與重新開啟應用程式/工作負載所需時間之間。
若是線上 (最短停機時間) 移轉，則停機時間是關閉應用程式後將最終變更自來源同步至目的地所需的持續時間。 在重新設定和啟用應用程式/工作負載前，新增至該停機時間、驗證與確認作業。
有此資訊後，即可查看移轉的技術元素以協助建立可行的選項。
來源資料庫位置
由於指定設定可能有條件約束，因此要移轉的資料庫來源位置將有所影響。
內部部署或非 Azure 來源
針對內部部署或非 Azure 所在資料庫，關鍵條件約束通常是來源和目標間的網路連線。 這裡要考量的三個點是頻寬、延遲和資料量。 了解這些點後，我們便可以針對可行移轉類型做出明智決策。
如果有大量要移轉的資料且頻寬比例較小，則可能無法進行簡單備份和還原。 然而，如果我們有大量資料和大量頻寬，則便不需要擔心。
同理，若是線上移轉且將進行資料同步，則延遲是其中一個關鍵因素。 如果延遲很高，則可能會對系統效能造成負面影響，因為同步程序需要過長的時間才能完成。
自其他雲端提供者移轉時也要考量的一個重要因素是這些雲端提供者是否會收取資料輸出的費用。 若是如此，則可考量最小化傳輸資料的實體磁碟使用量。 在此情況下，壓縮技術可能對同步所使用的備份或資料流非常重要。
其他以 Azure 為基礎的服務
在某些情況下，您會想要從其他以 Azure 為基礎的服務移轉至適用於 PostgreSQL 的 Azure 資料庫彈性伺服器。 這些來源資料庫可能位於 Azure VM、容器，或者可能位於適用於 PostgreSQL 的 Azure 資料庫單一伺服器。 若是，則需要探索一組不同的考量事項，但同時針對這些情況，也有很多機會能受益於 Azure 服務的最佳化。
自訂功能性
考量的最後領域是所需的自訂功能性程度。 此考量的形式可以是修改來源資料庫結構以支援資料複寫，或者也可以表示透過指令碼自動化的簡易程度。
其中一個良好範例是透過 pg_dump and pg_restore 自動化資料庫的離線移轉，但同時包含備份檔案的壓縮和解壓縮。
決策制訂
現在我們已完成收集所有此資訊的程序，接著可與專案關係人合作以決定指定情況的最佳選項。 決定要使用的方法和技術時，請務必同時與業務專案關係人與技術專案關係人合作。 此共同作業可協助避免企業推動最短停機時間移轉的情況，而技術小組因人員配置、資源或技術限制而無法達成。
這裡的關鍵是管理預期，並進行開方且誠實的對話。 此外，請也務必確保企業充分掌握驗證工作，這不屬於進行資料庫移轉的技術小組職權範圍。 此驗證可能涉及資料一致性和驗證檢查，以及使用者體驗測試。