你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

使用就地迁移功能迁移到应用服务环境 v3

注意

本文中所述的迁移功能用于将应用服务环境 v1 和 v2 自动就地（同一子网）迁移到应用服务环境 v3。 如果要查找并行迁移功能的相关信息，请参阅使用并行迁移功能迁移到应用服务环境 v3。 如果要查找有关手动迁移选项的信息，请参阅手动迁移选项。 如果在确定适合你的迁移选项时需要帮助，请参阅迁移路径决策树。 若要详细了解应用服务环境 v3，请参阅应用服务环境 v3 概述。

应用服务可以将应用服务环境 v1 和 v2 自动迁移到应用服务环境 v3。 有不同的迁移选项。 查看迁移路径决策树，确定哪种选项最适合你的用例。 与早期版本相比，应用服务环境 v3 具有一些优点和功能差异。 请确保在迁移之前查看应用服务环境 v3 支持的功能，以降低出现意外应用程序问题的风险。

就地迁移功能通过在同一子网中升级现有应用服务环境，自动迁移到应用服务环境 v3。 如果客户想要迁移到应用服务环境 v3，并且只想对网络配置进行最小更改，那么此迁移选项最适合他们。 还必须能够支持大约 1 小时的应用程序停机时间。 如果不支持停机，请参阅旁迁移功能或手动迁移选项。

重要

建议先在开发环境中使用此功能，然后再迁移生产环境，以确保不会出现意外问题。 请使用页面底部的按钮提供与本文或所介绍功能相关的任何反馈。

支持的方案

目前，就地迁移功能不支持迁移到以下区域的应用服务环境 v3：

由世纪互联运营的 Microsoft Azure

• 中国东部 2
• 中国北部 2

可以使用就地迁移功能迁移以下应用服务环境配置。 该表提供了在使用基于现有应用服务环境的就地迁移功能时的应用服务环境 v3 配置。 只要环境位于支持区域冗余的 Azure 区域，就可以使用就地迁移功能将所有受支持的应用服务环境迁移到区域冗余应用服务环境 v3。 可以在迁移过程中配置区域冗余。

Configuration	应用服务环境 v3 配置
内部负载均衡器 (ILB) 应用服务环境 v2	ILB 应用服务环境 v3
外部（ELB/面向 Internet，使用公共 IP）应用服务环境 v2	ELB 应用服务环境 v3
具有自定义域后缀的 ILB 应用服务环境 v2	具有自定义域后缀的 ILB 应用服务环境 v3
ILB 应用服务环境 v1	ILB 应用服务环境 v3
ELB 应用服务环境 v1	ELB 应用服务环境 v3
具有自定义域后缀的 ILB 应用服务环境 v1	具有自定义域后缀的 ILB 应用服务环境 v3
区域固定的应用服务环境 v2	具有可选区域冗余配置的应用服务环境 v3

如果你希望新的应用服务环境 v3 使用自定义域后缀，而当前没有使用，可以在迁移完成后随时配置自定义域后缀。 有关详细信息，请参阅为应用服务环境配置自定义域后缀。

可以通过导航到 Azure 门户中的应用服务环境，然后在左侧的“设置”下选择“配置”来找到应用服务环境的版本。 还可使用 Azure 资源浏览器，并查看应用服务环境的 kind 属性的值。

就地迁移功能限制

下面是使用就地迁移功能时的限制：

• 新应用服务环境 v3 在用于旧环境的现有子网中。
• 无法更改应用服务环境所在的区域。
• ELB 应用服务环境无法迁移到 ILB 应用服务环境 v3，反之亦然。
• 如果现有的应用服务环境使用自定义域后缀，则必须在迁移过程中为应用服务环境 v3 配置自定义域后缀。
  • 如果你不再想使用自定义域后缀，可以在迁移完成后将其删除。

应用服务环境 v3 不支持你的当前应用服务环境 v1 或 v2 可能使用的以下功能。

• 为应用配置基于 IP 的 TLS/SSL 绑定。
• 如果虚拟网络中配置的自定义 DNS 服务器无法解析给定的名称，则应用服务环境 v3 不会回退到 Azure DNS。 如果需要此行为，请确保提供一个指向公共 DNS 的转发器，或者将 Azure DNS 包含在自定义 DNS 服务器的列表中。

就地迁移功能不支持以下方案。 如果你的应用服务环境属于这些类别之一，请参阅手动迁移选项。

• 经典虚拟网络中的应用服务环境 v1
• 使用 IP SSL 地址的 ELB 应用服务环境 v2
• 使用 IP SSL 地址的 ELB 应用服务环境 v1
• 名称不符合字符限制的应用服务环境。 整个名称（包括域后缀）不得超过 64 个字符。 例如：ILB 的 my-ase-name.appserviceenvironment.net 和 ELB 的 my-ase-name.p.azurewebsites.net 不得超过 64 个字符。 如果不满足字符限制，则必须手动迁移。 专门针对应用服务环境名称的字符限制如下：
  • ILB 应用服务环境名称字符限制：36 个字符
  • ELB 应用服务环境名称字符限制：42 个字符

应用服务平台会查看你的应用服务环境以确认就地迁移支持。 如果你的方案没有通过所有验证检查，则此时你无法使用就地迁移功能进行迁移。 如果环境处于不正常或挂起状态，在你进行所需的更新之前无法迁移。

注意

应用服务环境 v3 不支持 IP SSL。 如果使用 IP SSL，则必须在迁移到应用服务环境 v3 之前删除所有 IP SSL 绑定。 删除所有 IP SSL 绑定后，迁移功能将支持你的环境。

疑难解答

如果应用服务环境未通过验证检查，或者你尝试按不正确的顺序执行迁移步骤，则可能会看到以下错误消息之一：

错误消息	说明	建议
只能对 ARM VNET 中的 ASE 调用迁移，此 ASE 位于经典 VNET 中。	经典 VNet 中的应用服务环境无法使用就地迁移功能进行迁移。	使用手动迁移选项之一进行迁移。
ASEv3 迁移尚未准备就绪。	底层基础结构未准备好支持应用服务环境 v3。	如果要立即迁移，请使用手动迁移选项之一进行迁移。 否则，请等待就地迁移功能在你的区域推出。
无法对此 ASE 调用迁移，请联系支持人员以帮助迁移。	需要接洽支持人员以迁移此应用服务环境。 此问题可能是由于此环境使用的自定义设置所致。	创建支持案例，以联系支持人员来解决问题。
如果在任何站点上启用了 IP SSL，则无法调用迁移。	无法使用迁移功能迁移具有启用了 IP SSL 的站点的应用服务环境。	从应用服务环境的所有应用中删除 IP SSL，以启用迁移功能。
生成 IP 地址之前无法调用完整迁移。	如果在完成迁移前步骤之前尝试迁移，会出现此错误。	在尝试迁移之前，请确保完成所有预迁移步骤。 请参阅迁移分步指南。
此 ASE 不允许迁移到 ASEv3。	无法使用迁移功能进行迁移。	使用手动迁移选项之一进行迁移。
订阅的应用服务环境过多。 请在尝试创建更多环境之前移除一些。	已达到订阅的应用服务环境配额。	请移除不需要的环境，或联系支持人员来查看你的选项。
<ZoneRedundant><DedicatedHosts><ASEv3/ASE> 在此位置不可用。	如果尝试在不支持某个请求的功能的区域中迁移应用服务环境，此错误会出现。	如果要立即迁移，请使用手动迁移选项之一进行迁移。 否则，请等待迁移功能支持此应用服务环境配置。
在活动升级完成之前，无法对此 ASE 调用迁移。	在平台升级期间，应用服务环境无法迁移。 可以从 Azure 门户设置升级首选项。 升级需要 8-12 小时或更长时间，具体取决于应用服务环境的大小（实例/核心数）。	等待升级完成，然后迁移。
正在执行应用服务环境管理操作。	应用服务环境正在进行管理操作。 这些操作包括部署或升级等活动。 在这些操作完成之前，迁移将被阻止。	完成这些操作后，可以迁移。
迁移不适用于此订阅。	需要接洽支持人员以迁移此应用服务环境。	创建支持案例，以联系支持人员来解决问题。
目前不支持 InteralLoadBalancingMode。	对于已将 InternalLoadBalancingMode 设置为特定值的应用服务环境，目前无法使用迁移功能进行迁移。 InternalLoadBalancingMode 必须由 Microsoft 团队手动更改。	创建支持案例，以联系支持人员来解决问题。 请求更新 InternalLoadBalancingMode 以方便迁移。

使用就地迁移功能的迁移过程概述

就地迁移包括一系列必须按顺序执行的步骤。 下面介绍了一些步骤的要点。 重要的是要了解在这些步骤中会发生的情况以及你的环境和应用会受到怎样的影响。 查看以下信息并准备好进行迁移后，请按照分步指南操作。

验证是否支持使用就地迁移功能对应用服务环境进行迁移

该平台验证是否可使用就地迁移功能迁移应用服务环境。 如果你的应用服务环境没有通过所有验证检查，则此时你无法使用就地迁移功能进行迁移。 若要详细了解验证失败的可能原因，请参阅故障排除部分。 如果环境处于不正常或挂起状态，在你进行所需的更新之前无法迁移。 如果无法使用就地迁移功能进行迁移，请参阅手动迁移选项。

此验证还会检查你的应用服务环境是否在使用迁移所需的最低版本。 此版本可能比通过常规平台升级/维护周期部署的标准版本更新。 最低版本会定期更新，以确保有最新的 bug 修复和改进可用。 如果你的应用服务环境没有使用最低版本，你需要自行启动升级。 此升级是一个标准过程，其中你的应用服务环境不会受到影响，但你在升级过程中无法缩放或更改应用服务环境。 在升级完成之前，将无法迁移。 升级可能需要 8-12 小时或更长时间才能完成，具体取决于环境的大小。 如果计划迁移的特定时间范围，则应在计划迁移时间前 24-48 小时运行验证检查，以确保有时间进行升级（如果需要）。

为新的应用服务环境 v3 生成 IP 地址

平台会创建新的入站 IP（如果要迁移 ELB 应用服务环境）和新的出站 IP 地址。 创建这些 IP 时，现有应用服务环境的活动不会中断，但是，你将无法扩展或更改现有环境。 此过程需要大约 15 分钟才能完成。

完成后，会向你提供你的未来应用服务环境 v3 使用的新 IP。 这些新 IP 对现有环境没有任何影响。 现有环境使用的 IP 会继续被使用，直到在迁移步骤中关闭现有环境。

使用新 IP 更新依赖资源

创建新的 IP 后，你将拥有新的默认出站到 Internet 公共地址。 在准备迁移时，可以调整任何外部防火墙、DNS 路由、网络安全组以及依赖于这些 IP 的任何其他资源。 对于 ELB 应用服务环境，你还会有新的入站 IP 地址，可使用它通过流量管理器或 Azure Front Door 等服务设置新的终结点。 你负责更新将受与新应用服务环境 v3 关联的 IP 地址更改影响的所有资源。 在完成所有必要的更新之前，请不要继续执行下一步。 此步骤也提供了一个很好的机会来查看在迁移到应用服务环境 v3 时入站和出站网络依赖项的变化，包括 Azure 负载均衡器运行状况探测的端口变化，它现在使用端口 80。

委托应用服务环境子网

应用服务环境 v3 要求其中的子网具有 Microsoft.Web/hostingEnvironments 的单一委托。 如果没有委托应用服务环境的子网，或将其委托给其他资源，则迁移无法成功。

确认实例大小更改

在迁移过程中，你的应用服务计划会从“独立”转换为相应的“独立 v2 层”。 例如，I2 会转换为 I2v2。 你的应用可能会在迁移后过度预配，因为独立 v2 层在每个相应实例大小上具有更多内存和 CPU。 迁移完成后，可以根据需要缩放环境。 有关详细信息，请查看 SKU 详细信息。

确保资源中没有锁

在迁移期间，虚拟网络锁会阻止平台操作。 如果虚拟网络具有锁，则需要在迁移之前将其删除。 迁移完成后，可以根据需要读取锁。 锁可以存在于三个不同的范围：订阅、资源组和资源。 在父范围应用锁时，该范围内所有资源都会继承相同的锁。 如果在订阅、资源组或资源范围内应用了锁，则需要在迁移前将其删除。 有关锁和锁继承的详细信息，请参阅锁定资源以保护基础结构。

确保没有阻止迁移的 Azure Policy

Azure Policy 可用于拒绝对某些主体创建和修改资源。 如果有策略阻止创建应用服务环境或修改子网，则需要在迁移之前将其删除。 迁移完成后，可以根据需要读取策略。 有关 Azure Policy 的详细信息，请参阅 Azure Policy 概述。

选择应用服务环境 v3 配置

可以在支持应用服务环境 v3 的 Azure 区域中跨可用性区域部署该服务。 此体系结构称为区域冗余。 只能在创建应用服务环境期间配置区域冗余。 如果你希望新的应用服务环境 v3 是区域冗余的，请在迁移过程中启用该配置。 只要使用的 Azure 区域支持应用服务环境 v3 的区域冗余，就可以将任何使用就地迁移功能进行迁移的应用服务环境配置为区域冗余。 如果你的现有环境位于不支持区域冗余的 Azure 区域，则该配置选项会被禁用，且你无法进行配置。 就地迁移功能不支持更改区域。 如果你想要使用不同的区域，请使用手动迁移选项之一。

注意

启用区域冗余可能会产生额外的费用。 有关详细信息，请查看区域冗余定价模型。

如果你的现有应用服务环境使用自定义域后缀，系统会提示你为新的应用服务环境 v3 配置自定义域后缀。 需要提供自定义域名、托管标识和证书。 有关应用服务环境 v3 自定义域后缀的详细信息，包括要求、分步说明和最佳做法，请参阅为应用服务环境配置自定义域后缀。 必须为新的环境配置自定义域后缀，即使你不再想使用自定义域后缀。 迁移完成后，可根据需要删除自定义域后缀配置。

如果迁移包含自定义域后缀，则对于应用服务环境 v3，自定义域不会显示在门户“概述”页面的“基本信息”部分中，因为它适用于应用服务环境 v1/v2。 对于应用服务环境 v3，请转到“自定义域后缀”页面，可在其中确认自定义域后缀配置是否正确。 此外，在应用服务环境 v2 上，如果有自定义域后缀，则默认主机名包括自定义域后缀，并且格式为 APP-NAME.internal.contoso.com。 在应用服务环境 v3 上，默认主机名始终使用默认域后缀，格式为 APP-NAME.ASE-NAME.appserviceenvironment.net。 区别在于，添加自定义域后缀时，应用服务环境 v3 保留默认域后缀。 使用应用服务环境 v2 时，只有一个域后缀。

迁移到应用服务环境 v3

完成上述步骤后，应尽快继续迁移。

重要

由于迁移期间阻止了缩放，因此在开始迁移之前，你应将环境缩放为所需的大小。 如果启用了自动缩放，并且在迁移开始之前发生了缩放事件，则你必须等待缩放事件完成，然后才能开始迁移。 应在开始迁移之前禁用自动缩放，以避免此问题。 如果需要在迁移后缩放环境，可以在迁移完成后执行此操作。

应用服务环境 v2 到 v3 的迁移需要三到六小时的服务时段。 根据 v1 到 v3 迁移的环境大小，最多需要 6 小时的服务时段。 在需要服务团队手动干预的极少数情况下，可能会扩展服务窗口。 在迁移期间，缩放和环境配置被阻止，并发生以下事件：

• 现有应用服务环境关闭并被替换为新的应用服务环境 v3。
• 应用服务环境中的所有应用服务计划都从隔离转换为隔离 v2 层。
• 应用服务环境中的所有应用都暂时关闭。 在此期间，预计大约有一小时的停机时间。
  • 如果你不支持停机，请参阅并排迁移功能或迁移替代选项。
• 应用服务环境使用的公共地址会更改为在 IP 生成步骤期间生成的 IP。

迁移过程中可使用以下状态：

状态	说明
验证和准备迁移。	平台正在验证迁移支持并执行必要的检查。
部署应用服务环境 v3 基础结构。	新的应用服务环境 v3 基础结构正在预配。
等待基础结构完成。	平台正在验证新基础结构并执行必要的检查。
设置网络。 迁移停机时间已开始。 无法访问应用程序。	平台正在删除旧基础结构并将所有应用移动到新的应用服务环境 v3。 应用已关闭且不接受流量。
运行迁移后验证。	平台正在执行必要的检查，确保迁移成功。
完成迁移。	平台正在完成迁移。

与 IP 生成步骤一样，在此过程中，你无法缩放或修改应用服务环境或向其部署应用。 迁移完成后，旧应用服务环境中的应用会在新的应用服务环境 v3 上运行。

使用就地迁移功能

先决条件

请确保了解迁移到应用服务环境 v3 对应用程序的影响。 查看迁移过程，了解流程时间线以及需要参与的时间和位置。 另请查看常见问题解答，其中可以回答一些问题。

请确保虚拟网络、资源组、资源或订阅中没有锁定。 在迁移期间，锁会阻止平台操作。

请确保没有 Azure 策略会阻止迁移所需的操作，包括子网修改和 Azure 应用服务资源创建。 阻止资源修改和创建的策略可能会导致迁移停滞或失败。

由于迁移期间阻止了缩放，因此在开始迁移之前，应将环境缩放为所需的大小。 如果需要在迁移后缩放环境，可以在迁移完成后执行此操作。 如果启用了自动缩放，并且在迁移开始之前发生了缩放事件，则迁移将被阻止，直到缩放事件完成。 应在开始迁移之前禁用自动缩放，以避免此问题。

建议使用 Azure 门户来进行就地迁移体验。 如果决定使用 Azure CLI 进行迁移，请按照本文中的顺序和所写内容执行所述步骤，因为要进行 Azure REST API 调用。 建议使用 Azure CLI 进行这些 API 调用。 有关其他方法的信息，请参阅 Azure REST API 参考。

对于本指南，请安装 Azure CLI，或使用 Azure Cloud Shell 并使用 Bash shell。

注意

我们建议使用 Bash shell 运行本指南中给出的命令。 这些命令可能与 PowerShell 约定和转义字符不兼容。

1. 获取应用服务环境 ID

请运行以下命令，以获取应用服务环境 ID，并将其存储为环境变量。 将名称和资源组的占位符替换为要迁移的应用服务环境的值。 如果虚拟网络和应用服务环境位于同一资源组中，则 ASE_RG 和 VNET_RG 相同。

ASE_NAME=<Your-App-Service-Environment-name>
ASE_RG=<Your-ASE-Resource-Group>
VNET_RG=<Your-VNet-Resource-Group>
ASE_ID=$(az appservice ase show --name $ASE_NAME --resource-group $ASE_RG --query id --output tsv)

2.验证是否支持迁移

以下命令检查应用服务环境是否支持迁移，并验证应用服务环境是否位于支持迁移的构建版本上。

az rest --method post --uri "${ASE_ID}/migrate?api-version=2021-02-01&phase=validation"

如果没有错误，则表示支持迁移，可以继续执行下一步。

如果需要开始升级来将应用服务环境升级到受支持的生成版本，请运行以下命令。 仅当验证步骤失败，并且系统要求你升级应用服务环境时，才运行此命令。

az rest --method post --uri "${ASE_ID}/migrate?api-version=2021-02-01&phase=PreMigrationUpgrade"

3.为新的应用服务环境 v3 资源生成 IP 地址

请运行以下命令，以创建新的 IP 地址。 完成此步骤大约需要 15 分钟。 在此期间，请不要缩放或更改现有应用服务环境。

az rest --method post --uri "${ASE_ID}/migrate?api-version=2021-02-01&phase=premigration"

请运行以下命令，以检查此步骤的状态：

az rest --method get --uri "${ASE_ID}?api-version=2021-02-01" --query properties.status

如果该步骤正在进行，则会获得 Migrating 状态。 获取 Ready 状态后，请运行以下命令以查看新 IP。 如果未立即看到新 IP，请等待几分钟，然后重试。

az rest --method get --uri "${ASE_ID}/configurations/networking?api-version=2021-02-01"

4. 使用新 IP 更新依赖资源

通过使用新的 IP，更新所有资源或网络组件，确保迁移完成后新环境按预期运行。 你应负责进行所有必要更新。

5. 委托应用服务环境子网

应用服务环境 v3 要求其所在子网具有 Microsoft.Web/hostingEnvironments 的单一委托。 以前的版本不需要此委托。 在迁移之前，需要确认子网已正确委派并更新委派（如有必要）。 你可以通过运行以下命令或在 Azure 门户中导航到该子网来更新委托。

az network vnet subnet update --resource-group $VNET_RG --name <subnet-name> --vnet-name <vnet-name> --delegations Microsoft.Web/hostingEnvironments

6. 确认虚拟网络中没有锁

在迁移期间，虚拟网络锁会阻止平台操作。 如果虚拟网络具有锁，则需要在迁移之前将其删除。 如有必要，可以在迁移完成后添加回锁定。

请使用以下命令检查虚拟网络是否具有任何锁定：

az lock list --resource-group $VNET_RG --resource <vnet-name> --resource-type Microsoft.Network/virtualNetworks

请使用以下命令删除任何现有的锁定：

az lock delete --resource-group $VNET_RG --name <lock-name> --resource <vnet-name> --resource-type Microsoft.Network/virtualNetworks

有关用于检查订阅或资源组是否具有锁定的相关命令，请参阅 Azure CLI 锁定参考。

7. 准备好配置

如果现有环境位于支持区域冗余的区域，可以将新的应用服务环境 v3 资源设置为区域冗余。 你可以通过将 zoneRedundant 属性设置为 true 来配置区域冗余。

如果现有的应用服务环境使用自定义域后缀，需要在迁移过程中为新的应用服务环境 v3 资源配置一个自定义域后缀。 如果未配置但当前要使用自定义域后缀，迁移会失败。 如果在迁移到未配置自定义域后缀的环境中尝试添加自定义域后缀，迁移也会失败。 有关应用服务环境 v3 自定义域后缀的详细信息（包括要求、分步说明和最佳做法），请参阅应用服务环境的自定义域后缀。

注意

如果要配置自定义域后缀，在向 Azure 密钥保管库添加网络权限时，请确保密钥保管库允许从应用服务环境的新出站 IP 地址（在步骤 3 中生成）进行访问。 如果使用专用终结点访问密钥保管库，请确保已正确配置专用访问。

如果迁移不包含自定义域后缀且未启用区域冗余，则可以继续迁移。

若要设置这些配置，请根据你自己的情况创建一个名为“parameters.json”的文件，其中包含以下详细信息。 如果自定义域后缀不适用于你的迁移，请不要包含自定义域后缀的属性。 请注意 zoneRedundant 属性的值，因为迁移后此配置不可逆。 根据现有的应用服务环境版本设置 kind 属性的值。 kind 属性的接受值是 ASEV1 和 ASEV2。

如果要在没有自定义域后缀的情况下迁移，并且要启用区域冗余，请使用以下代码：

{
    "type": "Microsoft.Web/hostingEnvironments",
    "name": "sample-ase-migration",
    "kind": "ASEV2",
    "location": "westcentralus",
    "properties": {
        "zoneRedundant": true
    }
}

如果为自定义域后缀配置使用用户分配的托管标识，并且要启用区域冗余，请使用以下代码：

{
    "type": "Microsoft.Web/hostingEnvironments",
    "name": "sample-ase-migration",
    "kind": "ASEV2",
    "location": "westcentralus",
    "properties": {
        "zoneRedundant": true,
        "customDnsSuffixConfiguration": {
            "dnsSuffix": "internal.contoso.com",
            "certificateUrl": "https://contoso.vault.azure.net/secrets/myCertificate",
            "keyVaultReferenceIdentity": "/subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/asev3-migration/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ase-managed-identity"
        }
    }
}

如果为自定义域后缀配置使用系统分配的托管标识，并且不启用区域冗余，请使用以下代码：

{
    "type": "Microsoft.Web/hostingEnvironments",
    "name": "sample-ase-migration",
    "kind": "ASEV2",
    "location": "westcentralus",
    "properties": {
        "customDnsSuffixConfiguration": {
            "dnsSuffix": "internal.contoso.com",
            "certificateUrl": "https://contoso.vault.azure.net/secrets/myCertificate",
            "keyVaultReferenceIdentity": "SystemAssigned"
        }
    }
}

8.迁移到应用服务环境 v3 并检查状态

完成上述所有步骤后，即可开始迁移。 请确保了解迁移的影响。

对于从 v2 到 v3 的迁移，此步骤需要三到六个小时，对于从 v1 到 v3 的迁移，则最多需要六个小时，具体取决于环境大小。 在此期间，应用程序大约停机一小时。 在此步骤中，会阻止对现有应用服务环境进行缩放、部署和修改。

如果要启用区域冗余和/或配置自定义域后缀，请在以下命令中包含 body 参数。 如果这些配置都不适用于你的迁移，可以从命令中移除该参数。

az rest --method post --uri "${ASE_ID}/migrate?api-version=2021-02-01&phase=fullmigration" --body @parameters.json

运行以下命令，检查迁移的详细状态。 有关状态的信息，请参阅迁移状态说明。

第一个命令获取迁移的操作 ID。 请复制 ID 属性的值。

az rest --method get --uri "${ASE_ID}/operations?api-version=2022-03-01"

将以下命令中操作 ID 的占位符替换为复制的值。 此命令返回迁移的详细状态。 可根据需要运行此命令以获取最新状态。

az rest --method get --uri "${ASE_ID}/operations/<operation-id>/details/default?api-version=2022-09-01"

获得 Ready 状态后，迁移就完成了，你就有了一个应用程序服务环境 v3 资源。 应用现在在新环境中运行。

运行以下命令或转到 Azure 门户即可获取新环境的详细信息。

az appservice ase show --name $ASE_NAME --resource-group $ASE_RG

1.验证是否支持迁移

在 Azure 门户中，转到要迁移的应用服务环境的“迁移”页面。 你可以通过选择应用服务环境的“概述”页面顶部的横幅，或选择左侧菜单上的“迁移”项，来转到“迁移”页面。

选择“就地”迁移选项以启动就地迁移过程。 如果选择了并行迁移的选项，则会看到该迁移过程的文档。 如果要使用就地迁移功能，请不要选择并排迁移选项。

在“迁移”页面中，平台会验证应用服务环境是否支持迁移。 选择“验证”，然后确认要继续验证。 验证过程需要几秒钟的时间。

如果环境不支持迁移，页面顶部会显示横幅，并包含一条指出原因的错误消息。 有关不符合迁移条件的错误消息的说明，请参阅故障排除。

如果需要启动升级以将应用服务环境升级到受支持的生成版本上，系统会提示启动升级，这可能需要 8-12 小时或更长时间，具体取决于环境的大小。 选择“升级”以启动升级。 升级完成后，你会通过验证，并且可以使用迁移功能启动迁移。

如果应用服务环境支持迁移，请继续执行该过程的下一步。 “迁移”页面会指导执行一系列步骤以完成迁移。

2.为新的应用服务环境 v3 资源生成 IP 地址

在“获取新的 IP 地址”下，确认你了解含义并选择“开始”按钮。 完成此步骤大约需要 15 分钟。 在此期间，无法缩放或更改现有应用服务环境。

3. 使用新 IP 更新依赖资源

上一步完成后，将显示新应用服务环境 v3 资源的 IP 地址。 请使用这些新 IP 更新任何资源和网络组件，以便新环境在迁移完成后按预期运行。 你应负责进行所有必要更新。

4. 委托应用服务环境子网

应用服务环境 v3 要求其所在子网具有单一委派 Microsoft.Web/hostingEnvironments。 以前的版本不需要此委托。 在迁移之前，需要确认子网已正确委派并更新委派（如有必要）。 门户将显示子网链接，以便你可以根据需要进行确认和更新。

5. 确认实例大小更改

选择“确认”按钮以确认你了解应用服务计划会在迁移过程中从“独立”层转换为相应的“独立 v2”层。

6.确认虚拟网络没有锁定

在迁移期间，虚拟网络锁会阻止平台操作。 如果虚拟网络具有锁，则需要在迁移之前将其删除。 有关如何检查订阅或资源组是否具有锁的详细信息，请参阅配置锁。

7. 选择配置

如果现有环境位于支持区域冗余的区域，可以将新的应用服务环境 v3 资源设置为区域冗余。

如果要配置区域冗余，请选中“已启用”复选框。

如果环境位于不支持区域冗余的区域，则该复选框不可用。 如果需要区域冗余的应用服务环境 v3 资源，请使用手动迁移选项之一，并在支持区域冗余的区域之一中创建资源。

如果现有的应用服务环境使用自定义域后缀，则必须为新的应用服务环境 v3 资源配置一个自定义域后缀。 如果你是这种情况，系统会显示自定义域后缀的配置选项。 在提供所需信息之前，无法进行迁移。

如果要使用自定义域后缀，但当前未配置任何此类后缀，可以在迁移完成后配置一个。 有关应用服务环境 v3 自定义域后缀的详细信息（包括要求、分步说明和最佳做法），请参阅应用服务环境的自定义域后缀。

注意

如果要配置自定义域后缀，在向 Azure 密钥保管库添加网络权限时，请确保密钥保管库允许从应用服务环境的新出站 IP 地址（在步骤 2 中生成）进行访问。 如果使用专用终结点访问密钥保管库，请确保已正确配置专用访问。

添加自定义域后缀的详细信息后，“迁移”按钮将可用。

8. 迁移到应用服务环境 v3

完成上述所有步骤后，即可开始迁移。 请确保了解迁移的含义，包括在此期间会发生的情况。

对于从 v2 到 v3 的迁移，此步骤需要三到六个小时，对于从 v1 到 v3 的迁移，则最多需要六个小时，具体取决于环境大小。 在此步骤过程中，会阻止对现有应用服务环境进行缩放和修改。

注意

在极少数情况下，开始迁移后，你可能会在门户中看到一条通知，显示“迁移到应用服务环境 v3 失败”。 存在已知 bug，即使迁移正在进行，也可能会触发此通知。 检查应用服务环境的活动日志以确定此错误消息的有效性。 在大多数情况下，刷新页面可以解决问题，错误消息会消失。 如果错误消息仍然存在，请联系支持人员获取帮助。

目前，只有在使用 Azure CLI 时，才会显示详细的迁移状态。 有关详细信息，请参阅有关迁移到应用服务环境 v3 的 Azure CLI 部分。 即使使用门户进行迁移，也可以使用 CLI 检查迁移的状态。

迁移完成后，你便会拥有应用服务环境 v3 资源，并且所有应用都将在新的环境中运行。 可以通过查看应用服务环境的“配置”页来确认环境的版本。

如果迁移包含自定义域后缀，相应域会显示在应用服务环境 v1/v2 门户“概述”页面的“基本信息”部分中，但在应用服务环境 v3 中不再显示在此处。 对于应用服务环境 v3，请转到“自定义域后缀”页面，确认已正确配置自定义域后缀。 如果不再需要该配置，也可以将其删除，或者如果以前没有该配置，可以配置一个。

注意

如果迁移包含自定义域后缀，则迁移完成后，自定义域后缀配置可能会因已知 bug 显示为已降级。 应用服务环境仍应按预期工作。 已降级状态应在 6-8 小时内自行解决。 如果配置在 8 小时后降级，或者自定义域后缀不起作用，请联系支持人员。

定价

迁移应用服务环境无需任何费用。 使用就地迁移功能时，当你之前的应用服务环境在迁移过程中关闭时，会立即停止对它的收费。 一旦部署新的应用服务环境 v3，就会开始向你收取费用。 有关应用服务环境 v3 定价的详细信息，请参阅定价详细信息。

从早期版本迁移到应用服务环境 v3 时，应考虑某些可能会降低每月成本的方案。 考虑预留和节省计划以进一步降低成本。 有关节省成本的机会的信息，请参阅升级到应用服务环境 v3 后的成本节省机会。

注意

由于应用服务计划从隔离转换为隔离 v2，你的应用可能会在迁移后过度预配，因为隔离 v2 层具有每个相应实例大小的更多内存和 CPU。 迁移完成后，可以根据需要缩放环境。 有关详细信息，请查看 SKU 详细信息。

纵向缩减应用服务计划

可用于应用服务环境 v3 的应用服务计划 SKU 在独立 v2 (Iv2) 层上运行。 与独立层相比，每个相应层的核心数和 RAM 量实际上翻了一番。 迁移时，应用服务计划会转换为相应的层。 例如，I2 实例将转换为 I2v2。 虽然 I2 有两个核心和 7 GB RAM，但 I2v2 有四个核心和 16 GB RAM。 如果你预计容量要求保持不变，则会过度预配，并支付未使用的计算和内存费用。 对于此方案，可以将 I2v2 实例缩减到 I1v2，最终得到与之前类似的核心数和 RAM。

常见问题解答

• 如果当前不支持迁移我的应用服务环境怎么办？
  你目前无法使用就地迁移功能进行迁移。 如果你的环境不受支持，并且想要立即迁移，请参阅手动迁移选项。
• 如何选择适合我的迁移选项？
  查看迁移路径决策树，确定哪种选项最适合你的用例。
• 如何知道我是否应该使用就地迁移功能？
  就地迁移功能最适合想要迁移到应用服务环境 v3，只想对网络配置进行最小更改，并可以支持大约一个小时的应用程序停机时间的客户。 如果不支持停机，请参阅旁迁移功能或手动迁移选项。 就地迁移功能会在你现有环境所在的子网中创建应用服务环境 v3，并使用相同的网络基础结构。 如果你对这些特定 IP 有任何依赖关系，可能需要考虑入站和出站 IP 地址更改。
• 迁移期间是否会出现停机？
  是的，在执行迁移步骤期间的三到六小时服务时段内，预计大约有一小时的停机时间，因此请做出相应的计划。 如果你有另外一个应用服务环境，并可以在使用就地迁移功能进行迁移时将流量指向它，则可以消除应用程序停机。 如果没有其他应用服务环境且无法支持停机，请参阅并排迁移功能或手动迁移选项。
• 迁移后，我是否需要对应用执行任何操作，使其在新应用服务环境上运行？
  不需要，在旧环境上运行的所有应用都会自动迁移到新环境，并像以前一样运行。 无需用户输入。
• 如果我的应用服务环境具有自定义域后缀，应该怎么办？
  就地迁移功能支持此迁移方案。
• 如果我的应用服务环境是区域固定的，应该怎么办？
  区域固定应用服务环境 v2 目前是使用迁移功能进行迁移的受支持方案。 应用服务环境 v3 不支持区域固定。 迁移到应用服务环境 v3 时，可以选择是否配置区域冗余。
• 如果我的应用服务环境具有 IP SSL 地址，该怎么办？ 应用服务环境 v3 不支持 IP SSL。 在使用迁移功能或手动选项之一进行迁移之前，必须删除所有 IP SSL 绑定。 如果打算使用就地迁移功能，在删除所有 IP SSL 绑定后，需通过验证检查，并可以继续进行自动迁移。
• 我的应用服务环境的哪些属性会更改？
  你在使用应用服务环境 v3，因此请务必查看与以前版本相比的特性和功能差异。 对于 ILB 应用服务环境，你会保留相同的 ILB IP 地址。 对于面向 Internet 的应用服务环境，公共 IP 地址和出站 IP 地址会更改。 请注意，对于 ELB 应用服务环境，以前入站和出站使用同一个 IP。 对于应用服务环境 v3，它们是独立的。 有关详细信息，请参阅应用服务环境 v3 网络。 有关应用服务环境版本的完整比较，请参阅应用服务环境版本比较。
• 如果迁移失败或迁移期间出现意外问题，该怎么办？
  如果出现意外问题，支持团队随时待命。 在接触任何生产环境之前，应先迁移开发环境，了解迁移过程，并了解它会如何影响工作负载。
• 我的旧应用服务环境会怎样？
  如果你决定使用就地迁移功能迁移应用服务环境，旧环境将被关闭并删除，你的所有应用都将迁移到新环境。 你的旧环境不再可访问。 无法回滚到旧环境。
• 2024 年 8 月 31 日之后，应用服务环境 v1/v2 资源会怎样？
  2024 年 8 月 31 日之后，如果不迁移到应用服务环境 v3，则应用服务环境 v1/v2 以及其中部署的应用将不再可用。 应用服务环境 v1/v2 托管在应用服务缩放单元上，缩放单元在云服务（经典）体系结构上运行，该体系结构将于 2024 年 8 月 31 日停用。 因此，应用服务环境 v1/v2 在该日期之后将不再可用。 迁移到应用服务环境 v3，使应用保持运行，或者保存或备份需要维护的任何资源或数据。

后续步骤

应用服务环境 V3 网络

使用应用服务环境 v3

自定义域后缀