上文书说到，利用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的版本，能够减少更多的限制，提供更好的性能和灵活度。

    上船容易，也要想想下船难不难。