这并不能完全回答你的问题，但它可能有助于教育你更多的问题，并提醒你。这些都是我们将系统迁移到Azure之前，期间或之后的经验教训。现在我们已经在那里，我们有一个~50GB的数据库，在~30个实例中运行~6个服务。只要我们的数据库备份行为，升级所有的总工作量不到一个小时（如果我们没有很多安全措施可以强制我们使用，那么可能会少得多）了解迁移过程中发生了什么 - 我们不希望它太易于部署，只是为了保护我们自己。）
准备将系统迁移到Azure：
如果您计划转到Azure，首先需要确保您的架构和技术兼容。这并不是说您必须编写Azure特有的所有内容。这意味着以下一些事项：
- 您应该意识到＆＃34;高可用性＆＃34; 不意味着＆＃34;没有错误＆＃34;。事实上，高可用性环境通常会有更多错误，您必须处理和管理。例如，如果您有一个请求通过网络连接到只有主板炸并且脱机的服务器，那么该网络请求将不会成功。这通常不是您在＆＃34;标准＆＃34;中编码的问题。服务器应用。更进一步，如果失败的网络是用于将数据库连接放回连接池的话，该怎么办？这将导致该连接在下次有人将其拉出时被中毒并被破坏，无论该服务器的未来状态如何！这里有一些额外的事情需要担心，因为你不再只依赖于一个网络上有4个服务器，但现在依赖于数百个拥有数千台服务器的网络。 0.05％的错误情况会比你过去经历过的更频繁地发生，你真的必须意识到这一点！
- 您应该使用依赖注入来轻松更改内容。正确分离关注点似乎很难在Azure中变得非常容易。
- 您应该将架构用于＆＃34;高可用性＆＃34; 。例如，在Web场中运行时会中断的Web应用程序也会在Azure中中断，但设计为在Web场中运行的Web应用程序将非常容易在Azure中运行。
- 您应该为所有应用程序进行自动部署和配置转换。除非它只是一个小网站或类似网站，否则其他任何东西都是不可持续的。
- 根据您的需要，您可以分阶段进行。如果数据库延迟不是什么大不了的事情，那么在您以后迁移数据库时，可能会首先在Azure中获取应用程序，从而采用混合方法（从Azure到数据中心的VPN）。或许相反。我们所做的是将主应用程序和数据库保留在我们的数据中心，但首先将辅助应用程序放在Azure中。然后是一些主要的应用程序（在一个月后性能受到影响）之后我们的数据库和关键应用程序。最后的移民肯定会在一个非常长的周末进行，而且睡眠时间不多，但是现在我们已经完成了SOO会更好！
将您的应用程序迁移到Azure：
这最终在很大程度上取决于您的应用程序是什么或做什么，并且每个方案都有不同的步骤/问题/好处。我不打算深入介绍，除了说，＆＃34;使用谷歌，它是你的朋友！＆＃34;。除此之外，对我们而言，与我们的数据相比，将我们的应用程序升级到Azure是最大的收益。我们的应用程序迁移的投资回报率在托管成本，许可和管理工作之间不到一个月。我现在可以花一天时间设置所有SaaS应用程序/数据库/等的全新且重复的环境，并让它们在~25个不同的云实例上运行，而不是花费几天时间来设置服务器！
不要试图告诉你如何迁移这些，而是让我给你一些警告，以便你早日知道：
- 如果您在Windows 2012中遇到应用程序问题，请幽默我在Windows 2008 R2中进行尝试。他们准备的2012年的一些图片中有一些错误。来回切换是非常微不足道的！
- 让您的日志记录比现在更好1000x。如果你现在不这样做，你会后悔的。
- 不要完全依赖易于实施的＆＃34; Azure Logging＆＃34;。它运行良好，但它或多或少要求您的应用程序成功启动，并且在调试启动问题时绝对无用。如果你没有替代方案，那么当你的应用程序启动时，你会浪费很多很多小时来调试愚蠢的小问题。当你完成它之后，你可以轻松地添加其他5个日志框架，并且有一个非常棒的日志系统和一个正在运行的应用程序，而不是一个正在运行的应用程序，以显示相同的时间。真的，这样做！ （分析也是一个好主意，尽管如果你有多个实例，Mini-Profiler会出现负载平衡问题。）
- 如果您向部署（端口等）添加新端点，则不能简单地＆＃34;升级＆＃34;现有部署。您必须删除它（部署，而不是服务）并从头开始安装。您可以删除Staging one，部署到Staging，然后交换。
- 如果您有WCF应用，请假装您不了解Windows激活服务。默认情况下，它们在Azure中被禁用。您可以破解它们（启动脚本）或创建自己的自托管应用程序。我们自我托管，因此我们可以在部署后更轻松地调整服务配置（以一种坚持Azure的方式编辑web.config文件并不容易）。 Web服务在＆＃34; IIS＆＃34;在Azure中，但TCP，命名管道等不会。
- 了解并将Transient Errors Application Block（或类似的东西）添加到您与之通信的任何内容中。如果你现在不这样做，你会后悔的。
- 让您的日志更好！真的，真的，真的这样做！
将SQL Server数据库迁移到Azure：
将数据库升级到Azure是一个痛苦的过程。没有一种快速简便的方法可以让它在那里工作并使其发挥作用。有些人必须做出一些重大改变，而其他人只需要在这里和那里调整一些可忽略的东西。但是，无论您的数据库有多大或多小，您真的必须花费大量时间来测试它。测试您的迁移过程。测试脚本以准备数据库。在云中测试数据库的性能和稳定性。测试您的备份程序。测试升级过程。测试备份恢复过程。测试所有这一切，因为我保证你会发现一些惊喜！
架构：
- 了解SQL Azure的所有限制。没有堆等等。在开始之前了解它们！现在去学习吧！他们大部分时间都非常合理。
- 请注意2GB T-Log限制！这意味着永远无法重建一些非常大的索引！ （也就是说，我们的30GB表还没有达到此目的）
- 要部署您的架构，请进入本地数据库的SSMS并使用＆＃34;任务 - ＆gt;提取数据层应用程序......＆＃34;功能（它在不同版本的SSMS中的菜单的不同区域）。获取此文件并进入SSMS以获取Azure数据库并使用＆＃34;部署数据层应用程序＆＃34;特征。 （这将帮助您捕获某些 Azure限制，如果此过程失败，您不会表示尊重。）到目前为止，这是将数据库的空版本升级到的最简单方法天青。
- 使用像Redgate SQL Compare这样的工具验证您的工作（您必须调整一些选项，例如
WITH NOCHECK以获得干净的比较）。
- 在你成功之前，你必须清理用户，模式，破碎的垃圾邮件等。 （这是件好事！）
数据：
- 了解SQL Azure的所有限制。在开始之前学习它们！现在去学习吧！他们大部分时间都非常合理。
- 从Codeplex（或最新版本的任何位置）下载Azure数据库迁移向导。它不是最神奇的软件（有点不稳定），但即使它在你身上崩溃了一两次，它仍会为你节省很多时间！
- 我强烈推荐RedGate的SQL数据比较。前面提到的迁移向导将帮助您识别问题（它可以帮助您解决这些问题），并且可以让您~98％迁移，但是您希望在此之后回来并进行清理。它有一些错误可以忽略可空的BIT字段（以及上部ascii字符）以及SQL Data Compare等工具可以轻松识别和修复的其他一些错误。它还可以让您高枕无忧，依赖于您的数据库。
- 如果您的数据库很大，请考虑在Azure中启动一个临时VM（它们预装了SQL Server并在约20分钟内可用）来进行迁移。如果你这样做，最好将压缩数据库备份上传到Blob存储（Cerebrata的存储也很好），然后抓住它并恢复到该VM中的SQL Server。然后从那里开始你的迁移！
测试，测试，测试!!!
小心在VM上运行SQL，它不是高可用性解决方案。 Azure VM很容易重新启动。除非您在可用性组中有多个运行SQL Server的VM，或者您具有某种镜像和负载平衡设置，否则您将无法获得高可用性解决方案。我最初也支持IaaS到PaaS路线，最终它似乎是一种虚假的经济，因为将IaaS迁移到PaaS与将内部迁移到PaaS的工作差不多。最后，我决定花时间优化我的PaaS应用程序，即将持久存储移动到blob，实现瞬态错误处理和重试逻辑等。
您提出的建议当然是可行的，但是提供多VM安排来提供高可用性SQL需要一些工作并且价格昂贵！阅读以下指南，当我开始迁移过程时，这对我很有帮助：
Top 7 Concerns of Migrating a .NET Application to Azure
就在昨天，微软宣布计划在其Azure平台上托管Iaas解决方案，而不仅仅是Saas解决方案。
http://weblogs.asp.net/scottgu/archive/2013/04/16/windows-azure-general-availability-of-infrastructure-as-a-service-iaas.aspx
关于迁移，这取决于。我们使用分发机制：TFS + Octopus，因此部署非常简单，并且适用于Iaas或SQL Azure，这并不重要。
搬到萨斯时还有其他事情需要考虑。如果代码不是面向Saas，或者您的应用程序可能比Azure具有非常高的托管成本，则可能会重构您的代码。