我们发现上图中的后一行要求我们为 *.bacpac 文件指定一个存储路径。*.bacpac 文件是迁移过程中生成的中间文件，当兼容性检查通过后，把数据库中的所有内容都导出到这个文件中。从这个信息我们可以得知，无论采用何种迁移方式，其核心操作都是两步：先从本地数据库生成 *.bacpac 文件，再从*.bacpac 文件恢复一个Azure SQL Database。
　　单击 "Next" 显示配置的详情，再下一步开始兼容性检查。如果没有兼容性问题，执行迁移操作。
　　我的数据库存在一些兼容性问题，所以显示了错误报告并终止了迁移操作：

　　点击 "Result" 列中的链接能看到详细的报告，前面已经介绍过兼容性问题，直接执行我们处理兼容性问题的脚本文件，然后再试一次！

　　这次的执行已经没有错误提示了，其实后台已经开始了迁移过程。比较不爽的是这个过程没有详细的进度提示，只能黑等。我的经验数据是8G的库完成迁移大概是 8-12小时。当然这和你连接 Azure 的带宽有很大的关系…
　　总结
　　由于整个迁移过程涉及的方方面面实在太多，本文只是概要式的介绍笔者认为迁移过程中的要点和自己碰到的问题。总的感觉是 MS 提供的工具还算比较完善，网络上的各种已知问题解决方案也很详尽。所以尽管笔者碰到了很多的问题，但没有卡壳的地方，总算磕磕绊绊的完成了数据库迁移的任务。
　　作者：sparkdev
　　出处：http://www.cnblogs.com/sparkdev/