迁移的订阅里有很多种不同的资源，有虚拟机，也有各种认知服务，有 WebApp 服务，也有对应的应用服务计划。迁移的方式也很简单，登录到 Azure 门户，打开需要迁移的资源所在资源组，勾选需要迁移的资源，然后在上端找到“移动”下拉菜单，选择“移动到另一个订阅”。Azure 门户会开启一个迁移向导，在这个向导里，你需要指定目标订阅和目标资源组，然后点击“下一步”，Azure 会验证是否能够完成迁移。
看着很简单吧？可是迁移一堆资源的时候，我发现报错了…提示貌似是 Web 应用服务和应用服务计划所在的资源组不对。怎么会呢？要迁移的资源不是已经乖乖地待在资源组里吗？那就查查文档吧。
Azure 其实支持特定的资源进行三种迁移：迁移到另一个资源组，迁移到另一个订阅和迁移到另一个区域。比较容易理解的是资源之间具有依存关系，所以需要整合到一个资源组一起迁移——这都是我已经特别注意的，但为什么会报错呢？难道是不支持迁移吗？报错信息不像啊…
先查一下哪些资源可以迁移。在 Azure 的文档里专门介绍了支持迁移的资源 ，列出了几乎所有 Azure 的资源类型是否支持三种迁移。不过，在文档里各种资源是以资源类型显示的。事后我来查看当然没啥问题，因为资源类型可以通过 Azure 门户里资源概述页面右上角的 JSON 视图查看，可以很明显的看到类似如下的属性描述：
"name": "modoo","type": "Microsoft.Web/sites", "kind": "app", "location": "West US",
以上仅截取部分属性显示。“type” 属性即为资源类型定义。这里显示的就是 Web 应用服务，其属性为“Microsoft.Web/sites”。在文档中查找“Microsoft.Web”小节，就能看到对应表格里，有 sites 的资源类型对应的迁移能力为：
当然，列出的“sites”只是一个，对于我来说还需要知道一起捆绑的应用服务计划，也列出如下：
资源类型
| 资源组
| 订阅
| 区域移动
|
| serverfarms | 是
| 是
| 否
|
其实相关的资源还有很多，只是这个例子里我只迁移这两类资源。如果您的迁移里涉及到其他资源，可以用这篇文档来进行迁移能力确认。如果不支持直接的迁移，可能就需要做其他搬家方式的计划。例如导出为模板，修改之后在新的订阅或资源组导入。好了，现在确认了 Web 应用和应用服务计划都可以进行跨订阅的迁移。那为什么会报错呢？
我们先看看报错长什么样子。
这个报错其实不是原始报错截图啦～是我后面为了研究问题（什么问题先卖个关子）特意复现的。点击“错误详细信息”进去，能看到某资源在某资源组，而不在原来某资源组之类的信息，但确实可读性不高。所以我意识到，Web 应用服务和应用服务计划貌似不像虚拟机一样，直接就一股脑迁移了。似乎有着某种限制要求。
如果此时的我，是当时的我，问题就简单了。其实在我们前面查阅迁移支持的时候，在“Microsoft.Web”小节就有个重要提示：这说明，应用服务迁移和其他类型的资源迁移操作是不同的。而在文档 “跨资源组/订阅移动” 中，也相当明确的给出了描述——跨订阅移动 Web 应用时，应遵循以下指导：
将资源移动到新的资源组或订阅属于元数据更改，不应影响资源的任何运作方式。例如，移动应用服务时，应用服务的入站 IP 地址不会更改。（所以我并不需要调整自己域名的 DNS 记录了）
目标资源组中不能有任何现有的应用服务资源。应用服务资源包括：
Web 应用（这次我想迁移的）
应用服务计划（也是这次我想迁移的）
上传或导入的 TLS/SSL 证书（这次迁移的环境没启用SSL）
应用服务环境
资源组中的所有应用服务资源必须一起移动。（这个好理解，否则依存关系检查估计不能通过）
应用服务环境不能移到新资源组，也不能移到新订阅。但是，可以将某个 Web 应用和应用服务计划转移到新订阅，而无需移动应用服务环境。
只要将证书与资源组中的所有其他资源一起移动，就可以将绑定的证书移到 Web，而无需删除 TLS 绑定。但是，无法移动免费的应用服务托管证书。对于该情况，请参阅移动免费托管证书 。（其实就是删除免费应用服务托管证书迁移之后再重新创建）
含专用终结点的 Azure 应用服务应用无法移动。删除专用终结点，并在移动后重新创建。(如果采用专用终结点保护应用服务访问，需要迁移之前记录并删除，迁移之后重建)
只能从最初创建应用服务资源的资源组中移动它们。如果应用服务资源不再位于其原始资源组中，请将其移回其原始资源组。然后，在订阅之间移动资源。（这就是报错的原因了！）
那么，怎么知道这些资源的原始资源组是哪个呢？
点击打开准备迁移的 Web 应用服务资源，在左侧的菜单栏找到“诊断并解决问题”，点击之后，在右侧页面找到“配置和管理”（Configuration and Management）。
进入到“配置和管理”页面之后，在左侧菜单栏点击“迁移操作“菜单，Azure 门户将会运行一个报告。等报告生成之后，就可以看到所有涉及需要一并迁移的 Web 应用服务和应用服务计划了。报告中很明显地指出了每一个资源目前和初始的资源组。
依据这个指示，将资源迁回原始的资源组，然后再一并迁移到新的订阅就可以了。除了使用 Azure 门户的 UI 界面，还可以使用 Azure PowerShell、Azure CLI 或 Azure 的 REST API 来移动资源。资源迁移之后，其对应的资源 ID 将发生变化。资源 ID 的标准格式为：
/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceProviderNamespace}/{resourceType}/{resourceName}。
将资源移到新的资源组或订阅时，会更改该路径中的一个或多个值。
多问几个为什么？
如果这篇文章在这里结束，其实就一点意义也没有了。因为内容在微软文档站点都能找到。我要问自己一个经典的问题：为什么？
为什么必须将资源迁回原始资源组呢？为什么虚拟机等资源迁移就不需要呢？
Azure 门户里能看到的信息毕竟是有限的，所以我决定用命令行来查看迁移前后 Web 应用服务和应用服务计划资源的不同。于是我又把资源迁回去了……
试了一下，使用如下的 PowerShell 可以获取我最希望得到的资源信息。
Get-AzResource -Name modoo -ResourceGroupName modoo.top -ResourceType Microsoft.Web/sites | fc -Property properties > modoo.site.1.txtGet-AzResource -Name modoo -ResourceGroupName modoo.top -ResourceType Microsoft.Web/serverfarms | fc -Property properties > modoo.plan.1.txt
可以看到，命令行里使用了资源类型的定义，来输出特定资源的信息。同时，我使用了管道来指定输出格式，使用 format custom 才能够看到“@”开头的全部属性信息。最后我把输出写入到一个文本文件进行比较。
同样，我昨晚迁移之后，又重复了一遍这个操作。
Get-AzResource -Name modoo -ResourceGroupName Test.Lab.US -ResourceType Microsoft.Web/sites | fc -Property properties > modoo.site.2.txtGet-AzResource -Name modoo -ResourceGroupName Test.Lab.US -ResourceType Microsoft.Web/serverfarms | fc -Property properties > modoo.plan.2.txt
然后我们比较一下，迁移前后的资源，到底哪里不一样。
Web 应用服务资源其实就两个地方不同：serverFarmId 和 resourceGroup，时间相关的不同我们可以忽略。
而应用服务计划就只有一处不同：resourceGroup。
这也就验证了前文文档里提及的，迁移其实只是修改了元数据，并未“真的”修改我们的资源。那为什么一定要迁移回“原始资源组”才能跨订阅迁移呢？
如果您创建 Web 应用服务，就会发现在创建向导中必须指定应用服务计划。这意味着，基于共享资源提供的应用服务，需要首先确定所使用的物理资源的位置。因为多个 Web 应用服务（当然不仅限于 Web 应用服务，所有使用应用服务计划的资源都一样）可以使用相同的应用服务计划，所以应用服务计划的作用对于解答我们的疑问就很重要了。
实际上，应用服务计划概述文档中已经告诉了我们足够的信息。应用服务计划为要运行的 Web 应用定义一组计算资源。这些计算资源类似传统 Web 托管方案中的服务器场。实际上，也就是针对“真实”计算资源的定义：
这使得基于该应用服务计划的 Web 服务资源能够对应到指定资源级别、指定服务价格的硬件来运行。在 Azure PowerShell 的输出信息里查找，确实找到了相关的信息：
webSpace。我的例子里为”modoo.top-WestUSwebspace"。实际上我有理由猜测，这就是原始资源组信息的来源。也就是创建应用服务计划时，所在的资源组信息。
subscrition。订阅的 ID 号。当我完成跨订阅的迁移时，我看到这个订阅 ID 确实改成了目标订阅的订阅 ID。
mdmId。我猜测这是管理硬件需要的信息。我的例子里这是以“waws-prod-bay-"开始的一串字符，我觉得这有可能就是硬件相关资源的标识。在跨资源组迁移、跨订阅迁移过程中，这个值一直没有变化。
正是由于一系列 Web 应用必须关联到某一特定应用服务计划，而应用服务计划又关联到逻辑上的应用服务场，所以跨订阅迁移才要求把所有的资源挪回原始资源组一并迁移吧。这时迁移动作会一并修改“webSpace”属性的值，从而让应用服务计划在新的订阅里可以有一个新的“原始资源组”，然后再将这个应用服务计划，也就是应用服务场关联的所有应用服务进行元数据的修改，完成迁移工作。
那么如果一开始我创建的 Web 应用服务和应用服务计划就不在一个资源组呢？（这就是文章开始卖的那个关子）那迁移的时候以谁为准呢？于是我又动手试了一下，实际上即使在其他资源组创建应用服务，应用服务仍然会以创建应用服务计划的资源组作为所有这些资源的“原始资源组”。
我们终于搞清楚了Web应用服务和应用服务计划迁移的细节，这更坚定了我使用应用服务而不是虚拟机放置我的网站的信心～毕竟，应用服务可省钱多了～
参考链接
- https://docs.microsoft.com/zh-cn/azure/azure-resource-manager/management/move-support-resources?WT.mc_id=Azure-MVP-33253
- https://docs.microsoft.com/zh-cn/azure/azure-resource-manager/management/move-resource-group-and-subscription?WT.mc_id=Azure-MVP-33253
https://docs.microsoft.com/zh-cn/azure/app-service/overview-hosting-plans?WT.mc_id=Azure-MVP-33253
*未经授权请勿私自转载此文章及图片。