上文書說到，利用DMA和SSMS遷移阿裡PaaS SQL到Azure失敗了，并且初步查到了原因，是因為Ali RDS對系統庫的通路做了Deny。
解決的辦法是在本地（Ali雲）對資料庫進行導出導入：建立一個新的IaaS的資料庫，然後将PaaS上的資料導入。有了這個可以輸出的資料庫，就能夠在Azure快樂地進行輸入啦。
進行資料遷移，除了DMA之外，SSMS 2017的菜單裡也內建了Azure SQL的部署向導，能夠把SQL Server直接部署到Azure SQL的PaaS執行個體。
放這張圖的意義在于這句話“……将資料庫部署到Microsoft Azure SQL Database。您還可以使用該向導将 Microsoft Azure SQL Database部署到SQL Server的本地執行個體，或将資料庫從一個Microsoft Azure SQL Database執行個體移到另一個執行個體。”
我覺得，雲服務應該是能上能下的，而不是上了就下不來的。雖然這個向導的遷移并不是我期望的平滑同步遷移。SSMS使用的是BACPAC的遷移方式。
在這個場景中，我的筆記本同時連接配接到不同的雲平台，這意味着資料需要從Ali雲流到我的電腦，然後再流入Azure雲。實際部署中肯定應該把SSMS部署在雲中，提高複制速度減少流量。并且，需要保留足夠的存儲空間以存放BACPAC檔案。
回到這個故事的最初，朋友其實是有很大的資料庫需要遷移的。是以，這種導入導出的方式并不是我所期望的。我期望的是沒有什麼實際停機時間的平滑遷移。是以我覺得訂閱複制方式可能更加适合。
借這個機會，我也在Ali的SQL Server上啟用了分發，在Azure上啟用了訂閱。
從Ali的IaaS SQL到Azure，就沒啥問題了。轉過身，我當然也要試試DMA這個工具來遷移資料庫，
這一次，能夠通路系統庫的資料庫伺服器可以遷移了。DMA工具會對遷移進行評估，然後來建立遷移工作。在這個例子裡，因為存在跨庫查詢，是以遷移到PaaS的SQL執行個體會有報錯，建議修改使用彈性查詢。
通過這次折騰，我覺得比較好的遷移方式，是：
1、如果是個很小的資料庫，并且也不想做任何的修改調整的話，簡單粗暴的虛機導出導入~
2、如果希望通過遷移完成從IaaS到PaaS的變遷，建議首先評估PaaS是否有任何限制，上得去，是否下得來
3、源SQL到目标SQL的操作相容性。可以用DMA進行遷移評估，根據報告确認有哪些相容性調整的工作
4、資料庫稍大，就需要考慮資料連續性和遷移視窗的沖突，是否使用AlwaysOn或者釋出訂閱的方式來做資料庫複制
另外有個本來是NDA的消息，不過微軟的兄弟已經透露了，Azure上很快有更新的Managed SQL的版本，能夠減少更多的限制，提供更好的性能和靈活度。
上船容易，也要想想下船難不難。
本文轉自HaoHu 51CTO部落格，原文連結：http://blog.51cto.com/haohu/2059547，如需轉載請自行聯系原作者