@ waring_id 美宜佳 系統(tǒng)架構(gòu)師 ：

5.做好應(yīng)急預(yù)案，出現(xiàn)異常情況可以及時處置或回退

@ 王小那個鑫 樂山市商業(yè)銀行 數(shù)據(jù)庫運維工程師 ：

不論是做一般的數(shù)據(jù)中心遷移，還是新創(chuàng)遷移等等，對于大體量的遷移，往往無法做到一次性完成，還是需要從業(yè)務(wù)重要性以及業(yè)務(wù)影響程度進(jìn)行分析，然后制定分批計劃，逐步完成，甚至可以細(xì)化到，某一個系統(tǒng)，先遷移應(yīng)用，再遷移數(shù)據(jù)庫等等。整個遷移過程可能涉及到的技術(shù)眾多，耗時可能會很長，一定是一項巨大的工程。

再具體的說下我的理解：

1.針對與java，可能相對比較好遷移，畢竟java是一個運行環(huán)境，調(diào)用執(zhí)行即可；

2.針對數(shù)據(jù)庫，目前市面上數(shù)據(jù)庫廠商有超過200家，針對不同的數(shù)據(jù)庫，也有不同的遷移方式，而且各個數(shù)據(jù)庫廠商也有一些較為完整的遷移工具和方式(特別是云平臺，基本都有自己的遷移工具),不過如果想平滑遷移，往往我們還是盡可能的以數(shù)據(jù)庫同步的方式來進(jìn)行(比如MySQL主從同步、 PostgreSQL的物理同步、邏輯同步，甚至可以借助OGG、DSG、kettle進(jìn)行)；

@navy river 京北方 平臺運維：

目前還沒遇到如此體量大的遷移。針對貴公司特點，我個人觀點認(rèn)為：如此龐大體量規(guī)模地遷移，應(yīng)該先按應(yīng)用類型去分類梳理，將遷移任務(wù)進(jìn)行分解，分階段開展遷移，對應(yīng)用和數(shù)據(jù)庫重要性進(jìn)行風(fēng)險評估，按照先外圍再核心的思想 ，最大限度降低風(fēng)險。一個業(yè)務(wù)條線在信創(chuàng)完成適配后，可以先并行一段時間，如果沒有重大問題，總結(jié)經(jīng)驗和教訓(xùn)后，即可開展下一個業(yè)務(wù)條線遷移準(zhǔn)備工作。這樣在遷移的過程中，也就逐步積累相關(guān)經(jīng)驗和教訓(xùn)，逐步減低風(fēng)險，最后實現(xiàn)總體遷移成功。以上個人觀點，有不足之處，歡迎指正。

@myciciy 某金融科技公司 IT顧問：

建議還是遵循，先易后難，穩(wěn)步推進(jìn)，評估，遷移、驗證，總結(jié)經(jīng)驗，為后續(xù)工作做鋪墊和經(jīng)驗積累。

歡迎點擊文末 閱讀原文 到社區(qū)閱讀和討論交流

覺得本文有用，請 轉(zhuǎn)發(fā) 或點擊 賞 ，讓更多同行看到