數據遷移是一個難度很大，並且業務方也不太理解的一種技術改造。這種驅動往往是技術團隊內部根據業務發展的規模以及目前技術棧變革、業務支撐的壓力負載等原因造成的。除了業務支撐不下去的理由之外，公司的業務團隊是不會認可這種改造帶來的風險，所以風險性極高。
我司前幾年做過一次大規模的數據遷移，主要原因是要去oracle，然后用PostgreSQL（PG）來替代，前前后后持續來接近半年才把所有系統都換成了PG。先是找一些數據量不是很大或者非主流的系統來試驗，在這個試驗中，其實就發現了很多問題，比如有一些安全攻擊帶來的特殊字符，轉成jsonb格式就出問題，還有新老數據庫切換開關的設置，等等這些問題的暴露和解決給后面全面替換oracle打下了基礎。
下面是我當時記錄的一些要點，可供大家參考：
1. 數據要雙寫，在遷移前段，數據同時寫入到老庫和新庫，並檢查新庫的落地情況，在遷移后期，服務都切到新庫了，也盡量做到雙寫，確保能夠回歸，如果不能，那么就要有數據導入方案（從新庫到老庫）
2. 要做好開關，從邏輯層確保能夠回滾
3. 對關聯方或者外邊系統提供的接口盡最大可能保存不變，否則極易引起生產問題
4. 新庫上的sequence，盡量設置的比較大，防止中遷移階段產生的數據和新庫中的數據造成沖突
5. Schema盡量用之前的，不然影響比較大
6. 寫一個工具來對比新老庫之間的schema及數據變動
7. 要把一個庫copy成臨時庫，不然不利於數據比對
8. 數據清洗，有BI的數據，安全攻擊的數據等，這些會帶入特殊字符，或者一些臟數據的處理，我們之前有些value從Oracle到PG，轉成jsonb格式的時候，字段出現了問題，后來都改成了text格式
9. 記錄一下遷移或者導庫的時間，方便做回滾或者遷移的決策，特別是切回回滾方案的時候
10. 在看庫的時候，有可能會看到一些注入攻擊的記錄，可以copy出來發給安全團隊作為參考，從前端做攔截，確保不入庫
11. 在測試環境的演練以及在灰度環境的試運行
12. 確定測試回歸范圍