所以我正在考虑将脚趾浸入Azure池中
我们的Web App Suite即将成为纯ASP.Net + SQL Server产品
由于各种原因，最初创建一个SQL VM并从那里开始运行所有内容将更为简单。
...要努力...
...将SQL从VM迁移到“云服务”或“数据管理”？
...将WebApp套件从VM迁移到“网站”？
我的理解是，完成此迁移后，操作系统级别的更新将不再是我关心的问题，因为它将由服务处理。因此，在这一点上，我将能够丢弃原始VM ：)
最佳答案
这并不能完全回答您的问题，但可以帮助您了解更多要问的问题，并助您一臂之力。这些都是在将系统迁移到Azure之前，之中或之后的经验教训。现在我们到了那里，我们有了一个〜50GB的数据库，其中〜6个服务在〜30个实例上运行。只要我们的数据库备份正常运行，升级所有这些文件的总工作时间就不会超过一个小时（如果我们没有足够的保障措施来迫使我们了解迁移过程中发生的事情，则花费的时间可能会更少。流程-我们不想为了保护我们自己而部署起来太容易了。
准备将系统迁移到Azure：
如果您打算使用Azure，则首先需要确保您的体系结构和技术兼容。这并不是说您必须编写特定于Azure的所有代码。这意味着以下一些事情：
您应该认识到“高可用性”并不意味着“没有错误”。实际上，高可用性环境通常会有更多的错误需要处理和管理。例如，如果您有一个请求，将请求通过网络发送到刚好有主板油炸物且已脱机的服务器，则该网络请求将失败。您通常不会在“标准”服务器应用程序中编码该问题。更进一步，如果该失败的网络是针对重新连接到连接池中的数据库连接的，该怎么办？这将导致该连接在下一次有人拔出时被毒化并断开，无论该服务器的将来状态如何！这里还有一些其他事情需要担心，因为您不再依赖于其中只有4个服务器的1个网络，而是现在依赖于其中有数千个服务器的数百个网络。发生这种0.05％错误的情况比您过去所经历的更多，并且您真的必须意识到这一点！
您应该使用依赖注入轻松地改变周围的事物。在Azure中，正确分离关注点将使看起来非常困难的更改变得非常容易。
您应该将架构用于“高可用性”。例如，在Web场中运行时将中断的Web应用程序在Azure中也将中断，但旨在在Web场中工作的Web应用程序将很容易在Azure中运行。
您应该为所有应用程序进行自动部署和配置转换。除非它只是一个小型网站或类似的网站，否则任何其他事情都是不可持续的。
根据您的需要，您可以分阶段进行。如果数据库延迟不是什么大问题，则可以采用混合方法（通过VPN从Azure到您的数据中心）来首先将应用程序置于Azure中，然后再迁移数据库。或相反。我们所做的是将主要应用程序和数据库保留在我们的数据中心中，但首先将辅助应用程序放置在Azure中。然后一些主要应用程序（对性能造成了一个月的打击）直到我们的数据库和关键应用程序。最终的迁移确保了一个漫长的周末，没有太多的睡眠，但是既然我们完成了，那就太好了！
将您的应用程序迁移到Azure：
最终，这在很大程度上取决于您的应用程序是什么或做什么，并且每种情况都有不同的步骤/问题/好处。除了说“使用Google，它是您的朋友！”之外，我不会对此进行深入介绍。除此之外，与我们的数据相比，将我们的应用程序升级到Azure是最大的收获。在托管成本，许可和管理工作之间，我们应用迁移的投资回报率不到一个月。现在，我无需花几天时间来设置服务器，而是花一天的时间来设置我们所有SaaS应用程序/数据库/等的全新且重复的环境，并使它们在大约25个不同的Cloud实例上运行！
我没有告诉您如何迁移它们，而是让我提一些警告，以便您早日知道：
如果您在Windows 2012中遇到应用程序问题，请幽默我，然后在Windows 2008 R2中尝试一下。他们准备的某些2012年图像中有一些错误。来回切换非常简单！
使您的日志记录比现在好1000倍。如果您现在不这样做，您将后悔。
不要100％依赖于易于实现的“ Azure Logging”。它运行良好，但或多或少要求您的应用程序成功启动，并且在调试启动问题时绝对没有用。如果没有其他选择，那么您将在启动应用程序时调试许多愚蠢的小问题，从而浪费大量时间。到完成时，您可以轻松添加其他5个日志记录框架，并拥有一个非常出色的日志记录系统以及一个正在运行的应用程序，而不是一个正在运行的应用程序来显示相同的时间。真的，做这个！ （虽然如果有多个实例，Mini-Profiler也会有负载平衡问题，但是进行概要分析也是一个好主意。）
如果将新端点添加到部署（端口等），则不能简单地“升级”现有部署。您必须删除它（部署，而不是服务）并从头开始安装。您可以删除暂存文件，部署到暂存文件，然后交换。
如果您有WCF应用程序，请假装对Windows激活服务一无所知。默认情况下，它们在Azure中被禁用。您可以破解它们以打开它们（启动脚本），也可以创建自己的自托管应用程序。我们自我托管，因此一旦部署，我们可以更轻松地调整服务配置（以粘贴在Azure中的方式编辑web.config文件并不容易）。 Web服务在Azure的“ IIS”中工作，但TCP，命名管道等则不行。
继续学习，并将“瞬态错误应用程序块”（或类似的东西）添加到与之通信的任何事物上。如果您现在不这样做，您将后悔。
去使您的日志记录更好！真的，真的，真的做到了！
将您的SQL Server数据库迁移到Azure：
使您的数据库进入Azure有点痛苦。没有快速简便的方法可以将其安装到位并使其工作。有些人必须进行一些重大更改，而其他人只需要在这里和那里调整一些可忽略的内容。但是，无论数据库大小，您实际上都必须花费大量时间来测试它。测试您的迁移过程。测试脚本以准备数据库。在云中测试数据库的性能和稳定性。测试您的备份过程。测试您的升级过程。测试您的备份还原过程。测试所有这些，因为我保证您会发现一些惊喜！
架构：
进一步了解SQL Azure的所有局限性。没有堆等等。在开始之前学习它们！现在去学习它们！它们大部分都非常合理。
请注意2GB T-Log限制！这意味着永远无法重建一些非常大的索引！ （也就是说，我们的30GB表尚未达到目标）
要部署架构，请进入本地数据库的SSMS，并使用“任务->提取数据层应用程序...”功能（在不同版本的SSMS中位于菜单的不同区域）。获取此文件，并为您的Azure数据库进入SSMS，并使用“部署数据层应用程序”功能。 （这将帮助您捕获一些失败的Azure限制，如果此过程失败的话）。到目前为止，这是将空版本的数据库引入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。然后从那里开始所有迁移！
测试，测试，测试！！！
关于sql-server - 在Azure上从IaaS迁移到PaaS的难度，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/16061705/