資料移轉這項程序是指在不同的地點、格式或應用程式之間移動資料，通常是由於引進新的資料系統或資料地點所致。其商業驅力通常是應用程式遷移或整併，而需要以全新的應用程式取代或增強老舊系統，以共享同一資料集。如今，企業往往是為了最佳化或業務轉型而開始資料移轉，以便從內部部署的基礎架構和應用程式，將資料移轉至雲端型儲存設備和應用程式。
簡單來說，是因為資料引力 (data gravity)。雖然資料引力的概念已有一段時日，但隨著資料移轉到雲端基礎架構，挑戰也變得更艱鉅。簡而言之，資料引力是一個比喻，它描述了：
為了將應用程式和資料移轉到更有利的環境，Gartner 建議「梳理」資料和應用程式，作為克服資料引力的一種手段。企業可以在專案開始階段就釐清資料和應用程式之間的複雜關係，藉此改善資料管理，實現應用程式的移動性，並完善資料管制措施。
主要問題在於，每個應用程式都會將自己的應用程式邏輯元素引進資料管理層，這會使資料管理變得越來越複雜，而且每個應用程式並不在乎下一個資料使用案例，不同的業務流程都獨自使用資料、輸出自己的格式，然後將整合問題留給下一個流程自己去解決。因此，雖然應用程式設計、資料架構和業務流程必須相互呼應，但往往總有一方無法或不願意更改自己的做法。於是，應用程式管理員不得不放棄理想中的簡單工作流程，導致設計結果總是差強人意。此外，儘管當時可能基於必要而採取某種權宜做法，但這些遺留下來的技術債最終還是必須在資料移轉或整合專案期間加以解決。
鑑於這種複雜性，請考慮將資料移轉這項作業提升至「策略武器」層級，使其獲得適當 水準 的認知和資源。為了確保專案獲得所需的關注，請將重點放在移轉過程中最能鼓舞士氣的元素上，也就是舊系統即將關閉的事實，您一定可以吸引重要相關人員的注意，我們保證。
升級系統或將資料中心延伸至雲端，具有諸多商業優勢。對許多企業來說，這是一個非常自然的演變過程。使用雲端的公司希望能協助員工將精力集中在業務優先事項上、帶動頂尖業務成長、提高敏捷度、降低資本支出，並隨需付費。然而，所進行的移轉類型將決定 IT 員工可以騰出多少時間來處理其他專案。
首先，我們來定義移轉類型：
資料移轉需要 3 個基本步驟：
移轉重要或敏感資料，還有汰換舊有系統，都可能會讓相關人員如履薄冰。完善的計畫是一定要的；但是，您不必多此一舉，因為在網路上就可以找到許多資料移轉計畫範例和檢查清單。譬如，Data Migration Pro 就是一個由資料移轉專業人員組成的社群，他們提供一份完整的檢查清單，其流程粗略包括以下 7 個階段：
這似乎是一項艱鉅的工作，但並非每次移轉都需要執行上述所有步驟。每種情況各不相同，每家公司都會以不同的方式來處理這項任務。
儘管幾十年來資料移轉一直是 IT 作業的一部分，但每年仍有令人震驚的事件發生。以下是企業在移動資料時面臨的十大挑戰：
未聯繫重要相關人員：無論移轉規模為何，都有人在意您要搬移的資料。在開始執行任務之前，請先找出這些人，向其說明專案的必要性及影響。否則，您肯定會在某個階段聽到議論聲，他們很可能會打亂您的時間表。
未與受影響企業溝通：向相關人員說明專案後，請務必讓他們瞭解您的進度。最好固定在每週的某一天提供狀態報告，尤其是在實際情況偏離預期時。定期溝通對於與所有受影響的人建立信任，有很大的幫助。
缺乏資料管制措施：請務必清楚知道誰有權在來源系統中建立、核准、編輯或移除資料，並將這些資訊以書面形式記錄在專案計畫中。
專業知識匱乏：雖然這是一項簡單的工作，但移轉資料涉及許多複雜因素。擁有經驗豐富的專業人員及出色的參考資料，有助於順利完成此過程。
缺乏規劃：一個家庭平均花 10 至 20 小時規劃度假行程，但 IT 團隊可能只有一半時間可供規劃小型資料移轉作業。雖然費心數小時的規劃，不一定能保證成功，但制定可靠的資料移轉計畫，確實可以省下數小時的實際資料移動時間。
用於準備資料的軟體和技能不足：如果是大規模移轉（數百萬筆記錄或數百張資料表），請投資一流的資料品管軟體，並考慮聘請專業公司來協助執行。好消息是：可能有外部公司可租借軟體給您，協助您節省成本。
等待目標系統符合完美規格：如果實作團隊正在彙整設計準則，請繼續執行步驟 2 和 3。目標系統的整備度在專案後期是很重要，但不要讓它現在對您造成阻礙。
移轉方法未經實證：請進行一些研究，確保資料移動程序對像您這樣的其他公司來說效果卓著。請克制住誘惑，不要接受供應商提供的一般通用程序。
供應商與專案管理：廠商與專案都需要加以管理。如果您同時還要處理日常工作，請確保您有時間管理專案及任何相關供應商。
物件相依性：雖然目前有資料管理工具技術和功能可供使用，但直到後來才知道原始計畫並未納入所有相關資料集，依然是一件晴天霹靂。由於常常到了移轉過程的後期才發現物件之間具有相依性，因此請務必擬定應變計畫，以免無法達成整體交付日期。
資料移轉和資料轉換這兩個詞彙，有時會在網際網路上交替使用，所以讓我們來澄清一下：它們的含義不同。如前面所述，資料移轉是指在不同位置、格式或系統之間移動資料的過程。資料移轉包括目標系統中的資料剖析、資料清理、資料驗證，以及持續的資料品質保證流程。在典型的資料移轉情境中，資料轉換只是複雜程序的第一步。
「資料轉換」一詞是指將資料從一種格式轉換為另一種格式的過程。將資料從舊版應用程式移至同一個應用程式的升級版本，或者移至具有新結構、完全不同的應用程式時，則必須執行轉換。進行轉換時，必須根據一組需求，從來源擷取資料、進行變更，然後載入新的目標系統。
另一個詞彙有時會與資料移轉混淆，那就是資料整合。資料整合是指組合不同來源的資料，讓使用者能夠統一檢視所有資料的過程。整合來自多個來源的資料，是資料分析不可或缺的要素。資料整合的範例包括資料倉儲、資料湖和 NetApp® FabricPools，它們可在內部部署資料中心和雲端之間自動進行資料分層，或者在 AWS EBS 區塊儲存與 AWS S3 物件存放區之間自動分層資料。
移轉至 基礎架構即服務 (IaaS)：
移轉至 平台即服務 (PaaS)：
唯有選擇符合業務需求的部署模式，才能確保所有資料移轉作業順利成功，並在效能、安全性和 ROI 方面創造業務價值。
將應用程式與雲端中的新服務整合，甚至免除部分技術負擔！
加速資料中心移轉、降低風險、消除或大幅減少營運中斷，並確保資料中心具備雲端就緒功能。