Migração para Ambiente do Serviço de Aplicativo v3 com o recurso de migração no local

O Serviço de Aplicativo pode automatizar a migração do Ambiente do Serviço de Aplicativo v1 e v2 para um Ambiente do Serviço de Aplicativo v3. Há várias opções de migração. Examine a árvore de decisão de caminho de migração para decidir qual opção é melhor para seu caso de uso. O Ambiente do Serviço de Aplicativo v3 fornece vantagens e diferenças de recursos em relação às versões anteriores. Examine os recursos com suporte do Ambiente do Serviço de Aplicativo v3 antes de migrar para reduzir o risco de um problema inesperado com o aplicativo.

O recurso de migração in-loco automatiza sua migração para o Ambiente do Serviço de Aplicativo v3 atualizando seu Ambiente do Serviço de Aplicativo existente na mesma sub-rede. Esta opção de migração é melhor para clientes que desejam migrar para o Ambiente do Serviço de Aplicativo v3 com alterações mínimas nas configurações de rede. Também deve ser possível dar suporte a cerca de uma hora de inatividade do aplicativo. Se você não puder dar suporte ao tempo de inatividade, consulte o recurso de migração lado a lado ou as opções de migração manual.

Cenários com suporte

No momento, o recurso de migração in-loco não dá suporte às migrações para o Ambiente do Serviço de Aplicativo v3 nas seguintes regiões:

Microsoft Azure operado pela 21Vianet

• Leste da China 2
• Norte da China 2

As seguintes configurações do Ambiente do Serviço de Aplicativo podem ser migradas usando o recurso de migração in-loco. A tabela fornece a configuração do Ambiente do Serviço de Aplicativo v3 ao usar o recurso de migração in-loco com base no Ambiente do Serviço de Aplicativo existente. Todos os Ambientes do Serviço de Aplicativo com suporte poderão ser migrados para um Ambiente do Serviço de Aplicativo v3 com redundância de zona usando o recurso de migração in-loco se o ambiente estiver em uma região com suporte para redundância de zona. Você poderá configurar a redundância de zona durante o processo de migração.

Se você quiser que o novo Ambiente do Serviço de Aplicativo v3 use um sufixo de domínio personalizado e não estiver usando um atualmente, o sufixo de domínio personalizado poderá ser configurado a qualquer momento após a conclusão da migração. Para obter mais informações, consulte Configurar o sufixo de domínio personalizado para o Ambiente do Serviço de Aplicativo.

Você pode encontrar a versão de seu Ambiente do Serviço de Aplicativo navegando até ele no portal do Azure e selecionando Configuração em Configurações no lado esquerdo. Você também pode usar o Azure Resource Explorer e examinar o valor da propriedade kind para o Ambiente do Serviço de Aplicativo.

Limitações do recurso de migração in-loco

A seguir, são apresentadas as limitações ao usar o recurso de migração in-loco:

• O novo Ambiente do Serviço de Aplicativo v3 fica na sub-rede existente que foi usada para o ambiente antigo.
• Não será possível alterar a região em que o Ambiente do Serviço de Aplicativo está localizado.
• O Ambiente do Serviço de Aplicativo do ELB não pode ser migrado para o Ambiente do Serviço de Aplicativo v3 do ILB e vice-versa.
• Se o Ambiente do Serviço de Aplicativo existente usar um sufixo de domínio personalizado, será necessário configurar o sufixo de domínio personalizado para o Ambiente do Serviço de Aplicativo v3 durante o processo de migração.
  • Se você não quiser mais usar um sufixo de domínio personalizado, poderá removê-lo assim que a migração for concluída.

O Ambiente do Serviço de Aplicativo v3 não dá suporte aos recursos a seguir que talvez estejam sendo usados no Ambiente do Serviço de Aplicativo atual v1 ou v2.

• Configurar uma associação TLS/SSL baseada em IP com os seus aplicativos.
• O Ambiente do Serviço de Aplicativo v3 não recorrerá ao DNS do Azure se os servidores DNS personalizados configurados na rede virtual não puderem resolver determinado nome. Se esse comportamento for necessário, verifique se você tem um encaminhador para um DNS público ou inclua o DNS do Azure na lista de servidores DNS personalizados.

O recurso de migração in-loco não dá suporte aos cenários a seguir. Consulte as opções de migração manual se o Ambiente do Serviço de Aplicativo se enquadrar em uma dessas categorias.

• Ambiente do Serviço de Aplicativo v1 em uma Rede virtual clássica
• Ambiente de Serviço de Aplicativo v2 do ELB com endereços IP SSL.
• Ambiente de Serviço de Aplicativo v1 do ELB com endereços IP SSL.
• Ambiente do Serviço de Aplicativo com um nome que não atende aos limites de caracteres. O nome completo, incluindo o sufixo do domínio, deve ter 64 caracteres ou menos. Por exemplo: my-ase-name.appserviceenvironment.net para ILB e my-ase-name.p.azurewebsites.net para ELB devem ter 64 caracteres ou menos. Se você não atender ao limite de caracteres, deverá fazer a migração manualmente. Os limites de caracteres especificamente para o nome do Ambiente do Serviço de Aplicativo são os seguintes:
  • Limite de caracteres do nome do Ambiente do Serviço de Aplicativo ILB: 36 caracteres
  • Limite de caracteres do nome do Ambiente do Serviço de Aplicativo ELB: 42 caracteres

A plataforma do Serviço de Aplicativo examina seu Ambiente do Serviço de Aplicativo para confirmar o suporte à migração in-loco. Se o cenário não passar em todas as verificações de validação, você não poderá migrar no momento usando o recurso de migração in-loco. Se seu ambiente estiver em um estado não íntegro ou suspenso, você não poderá migrar até fazer as atualizações necessárias.

Solução de problemas

Se o Ambiente do Serviço de Aplicativo não passar nas verificações de validação ou tentar executar uma etapa de migração na ordem incorreta, você poderá ver uma das seguintes mensagens de erro:

Visão geral do processo de migração in-loco usando o recurso de migração

A migração in-loco é composta por uma série de etapas que devem ser seguidas na ordem. Os pontos-chave são determinados para um subconjunto das etapas. É importante entender o que acontece durante essas etapas e como o ambiente e os aplicativos são afetados. Depois de revisar as informações a seguir e quando estiver pronto para migrar, siga o guia passo a passo.

Validar se a migração tem suporte usando o recurso de migração local para o Ambiente do Serviço de Aplicativo

A plataforma valida que o Ambiente do Serviço de Aplicativo pode ser migrado com o recurso de migração local. Se o Ambiente do Serviço de Aplicativo não passar em todas as verificações de validação, não será possível migrar no momento com o recurso de migração local. Confira a seção Solução de problemas para obter detalhes das possíveis causas de falha de validação. Se seu ambiente estiver em um estado não íntegro ou suspenso, você não poderá migrar até fazer as atualizações necessárias. Se não for possível migrar usando o recurso de migração local, consulte as opções de migração manual.

A validação também verifica se o Ambiente do Serviço de Aplicativo não está na compilação mínima exigida para a migração. Esse build pode ser mais recente do que o build padrão implantado com o ciclo de atualização/manutenção da plataforma de rotina. A compilação mínima é atualizada periodicamente para garantir que as correções de bug e melhorias mais recentes estejam disponíveis. Se o Ambiente do Serviço de Aplicativo não estiver na compilação mínima, você precisará iniciar a atualização por conta própria. Essa atualização é um processo padrão em que o Ambiente do Serviço de Aplicativo não será afetado, mas você não poderá dimensionar ou fazer alterações no Ambiente do Serviço de Aplicativo enquanto a atualização estiver em andamento. Não é possível migrar até que a atualização seja concluída. As atualizações podem levar de 8 a 12 horas para serem concluídas ou mais, dependendo do tamanho do ambiente. Se você planejar uma janela de tempo específica para a migração, deverá executar a verificação de validação de 24 a 48 horas antes do tempo de migração planejado para garantir que você tenha tempo para uma atualização, se necessária.

Gerar endereços IP para o novo Ambiente do Serviço de Aplicativo v3

A plataforma criará o novo IP de entrada (se estiver migrando um Ambiente do Serviço de Aplicativo de ELB) e os novos endereços IP de saída. Embora esses IPs sejam criados, a atividade com o Ambiente do Serviço de Aplicativo existente não é interrompida. No entanto, você não poderá dimensionar nem fazer alterações no ambiente existente. Esse processo leva cerca de 15 minutos para ser concluído.

Quando concluído, você receberá os novos IPs que o Ambiente do Serviço de Aplicativo v3 usará. Esses novos IPs não têm nenhum efeito sobre o ambiente existente. Os IPs usados pelo seu ambiente existente continuarão sendo usados até que seu ambiente existente seja desligado durante a etapa de migração.

Atualizar recursos dependentes com novos IPs

Depois que os novos IPs forem criados, você terá a nova saída padrão para os endereços públicos da Internet. Em preparação para a migração, você pode ajustar quaisquer firewalls externos, roteamento de DNS, grupos de segurança de rede e quaisquer outros recursos que dependam desses IPs. Para o Ambiente do Serviço de Aplicativo de ELB, você também tem o novo endereço IP de entrada que poderá ser usado para configurar os novos pontos de extremidade com os serviços como Gerenciador de Tráfego ou Azure Front Door. É sua responsabilidade atualizar todos os recursos que serão afetados pela alteração de endereço IP associada ao novo Ambiente do Serviço de Aplicativo v3. Não passe para a próxima etapa antes de fazer todas as atualizações necessárias. Essa etapa também é um bom momento para examinar as alterações de dependência de rede de entrada e saída ao mudar para o Ambiente do Serviço de Aplicativo v3, incluindo a alteração de porta para a investigação de integridade do Azure Load Balancer, que agora usa a porta 80.

Delegar a sub-rede do Ambiente do Serviço de Aplicativo

O Ambiente do Serviço de Aplicativo v3 requer que a sub-rede na qual ele está tenha apenas uma delegação de Microsoft.Web/hostingEnvironments. A migração não terá êxito se a sub-rede do Ambiente do Serviço de Aplicativo não for delegada ou for delegada a um recurso diferente.

Reconhecer alterações no tamanho da instância

Seus planos do Serviço de Aplicativo são convertidos de Isolado para a camada Isolada v2 correspondente como parte da migração. Por exemplo, o I2 é convertido em I2v2. Seus aplicativos podem ser provisionados em excesso após a migração, pois a camada Isolated v2 tem mais memória e CPU por tamanho de instância correspondente. Você tem a oportunidade de escalar seu ambiente conforme necessário após a conclusão da migração. Para obter mais informações, revise os Detalhes do SKU.

Verifique se não existem bloqueios em seus recursos

Os bloqueios da rede virtual bloqueiam as operações da plataforma durante a migração. Se sua rede virtual tiver bloqueios, você precisará removê-los antes de migrar. Se necessário, os bloqueios poderão ser adicionados novamente quando a migração for concluída. Os bloqueios podem existir em três escopos diferentes: assinatura, grupo de recursos e recurso. Quando você aplica um bloqueio a um escopo pai, todos os recursos filho herdam o mesmo bloqueio. Se você tiver bloqueios aplicados na assinatura, grupo de recursos ou escopo do recurso, eles precisarão ser removidos antes da migração. Para obter mais informações sobre bloqueios e herança de bloqueio, consulte Bloquear recursos para proteger a infraestrutura.

Verifique se não há nenhuma migração de bloqueio do Azure Policies

O Azure Policy pode ser usado para negar a criação e a modificação de recursos a determinadas entidades de segurança. Se você tiver uma política que bloqueie a criação de Ambientes do Serviço de Aplicativo ou a modificação de sub-redes, será necessário removê-la antes de migrar. Se necessário, os bloqueios poderão ser adicionados novamente quando a migração for concluída. Para obter mais informações sobre o Azure Policy, consulte a Visão geral do Azure Policy.

Escolher as configurações de Ambiente do Serviço de Aplicativo v3

O Ambiente do Serviço de Aplicativo v3 pode ser implantado em zonas de disponibilidade nas regiões com suporte. Essa arquitetura é conhecida como redundância de zona. A redundância de zona somente poderá ser configurada durante a criação do Ambiente do Serviço de Aplicativo. Se você quiser que o novo Ambiente do Serviço de Aplicativo v3 seja com redundância de zona, habilite a configuração durante o processo de migração. Qualquer Ambiente do Serviço de Aplicativo que estiver usando o recurso de migração in-loco para migrar poderá ser configurado como com redundância de zona, desde que esteja usando uma região com suporte a redundância de zona para Ambiente do Serviço de Aplicativo v3. Se o ambiente existente estiver em uma região sem suporte para redundância de zona, a opção de configuração será desabilitada e não será possível configurá-la. O recurso de migração in-loco não dá suporte para alteração de regiões. Se quiser usar uma região diferente, use uma das opções de migração manual.

Se o Ambiente do Serviço de Aplicativo existente usar um sufixo de domínio personalizado, você será solicitado a configurar um sufixo de domínio personalizado para o novo Ambiente do Serviço de Aplicativo v3. Será necessário fornecer o nome de domínio personalizado, a identidade gerenciada e o certificado. Para obter mais informações sobre o sufixo de domínio personalizado do Ambiente do Serviço de Aplicativo v3, incluindo os requisitos, as instruções passo a passo e as melhores práticas, consulte Configurar o sufixo de domínio personalizado para o Ambiente do Serviço de Aplicativo. Um sufixo de domínio personalizado deverá ser configurado para o novo ambiente, mesmo que não queira mais usá-lo. Após concluir a migração, você poderá remover a configuração de sufixo de domínio personalizado, se necessário.

Se a migração incluir um sufixo de domínio personalizado, para o Ambiente do Serviço de Aplicativo v3, o domínio personalizado não será mostrado na seção Essentials da página Visão Geral do portal, como é para o Ambiente do Serviço de Aplicativo v1/v2. Em vez disso, para o Ambiente do Serviço de Aplicativo v3, vá para a página Sufixo de domínio personalizado em que você poderá confirmar se o sufixo de domínio personalizado está configurado corretamente. Além disso, no Ambiente do Serviço de Aplicativo v2, se você tiver um sufixo de domínio personalizado, o nome do host padrão incluirá o seu sufixo de domínio personalizado e estará no formulário APP-NAME.internal.contoso.com. No Ambiente do Serviço de Aplicativo v3, o nome do host padrão sempre usa o sufixo de domínio padrão e estará no formulário APP-NAME.ASE-NAME.appserviceenvironment.net. Essa diferença ocorre porque o Ambiente do Serviço de Aplicativo v3 mantém o sufixo de domínio padrão quando você adiciona um sufixo de domínio personalizado. Com o Ambiente do Serviço de Aplicativo v2, há apenas um único sufixo de domínio.

Migrar para o Ambiente do Serviço de Aplicativo v3

Após concluir as etapas anteriores, será necessário continuar com a migração o mais rápido possível.

A migração exige uma janela de serviço de três a seis horas para migrações do Ambiente de Serviço de Aplicativo v2 para v3. É necessária uma janela de serviço de até seis horas, dependendo do tamanho do ambiente para migrações de v1 para v3. Observe que a janela de serviço pode ser estendida nos casos raros em que a intervenção manual da equipe de serviço é necessária. Durante a migração, as configurações de dimensionamento e ambiente são bloqueadas e os seguintes eventos ocorrem:

• O Ambiente do Serviço de Aplicativo existente é desligado e substituído pelo novo Ambiente do Serviço de Aplicativo v3.
• Todos os planos do Serviço do Aplicativo no Ambiente do Serviço do Aplicativo são convertidos da camada Isolado para Isolado v2.
• Todos os aplicativos em seu Ambiente do Serviço de Aplicativo ficam temporariamente inativos. Será necessário esperar cerca de uma hora de tempo de inatividade durante esse período.
  • Se passar por um tempo de inatividade não é uma opção para você, consulte o recurso de migração lado a lado ou as alternativas de migração.
• Os endereços públicos usados pelo Ambiente do Serviço de Aplicativo são alterados para os IPs gerados durante a etapa de geração de IP.

Os seguintes status estão disponíveis durante o processo de migração:

Como na etapa de geração de IP, você não poderá dimensionar, modificar o Ambiente do Serviço de Aplicativo ou implantar aplicativos nele durante esse processo. Quando a migração for concluída, os aplicativos que estavam no antigo Ambiente do Serviço de Aplicativo serão executados no novo Ambiente do Serviço de Aplicativo v3.

Usar o recurso de migração in-loco

Pré-requisitos

Certifique-se de entender como a migração para um Ambiente do Serviço de Aplicativo v3 afeta seus aplicativos. Revise o processo de migração para entender a linha do tempo do processo e quando e em que ponto você precisa se envolver. Além disso, revise as perguntas frequentes, que podem responder a algumas das suas dúvidas.

Verifique se não há bloqueios em sua rede virtual, grupo de recursos, recurso ou assinatura. Os blocos bloqueiam as operações da plataforma durante a migração.

Verifique se não há políticas do Azure que bloqueiem as ações necessárias para a migração, incluindo modificações de sub-rede e criações de recursos do Serviço de Aplicativo do Azure. As políticas que bloqueiam modificações e criações de recursos podem fazer com que a migração fique paralisada ou falhe.

Como o dimensionamento é bloqueado durante a migração, você deve dimensionar seu ambiente para o tamanho desejado antes de iniciar a migração. Se você precisar dimensionar seu ambiente após a migração, poderá fazê-lo depois que a migração for concluída. Se o escalonamento automático estiver habilitado e um evento de escalonamento ocorrer antes do início da migração, ela ficará bloqueada até que o evento de escalonamento seja concluído. Você deve desabilitar o dimensionamento automático antes de iniciar a migração para evitar esse problema.

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)

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"

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

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

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

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

{
    "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"
        }
    }
}

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

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

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

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

Preços

Não há nenhum custo para migrar o Ambiente do Serviço de Aplicativo. Ao usar o recurso de migração in-loco, você deixa de ser cobrado pelo Ambiente do Serviço de Aplicativo anterior assim que ele é desligado durante o processo de migração. Você começa a ser cobrado pelo novo Ambiente do Serviço de Aplicativo v3 assim que ele for implantado. Para obter mais informações sobre os preços do Ambiente do Serviço de Aplicativo v3, consulte os detalhes de preços.

Ao migrar de versões anteriores para o Ambiente do Serviço de Aplicativo v3, há cenários que você deve considerar que podem reduzir o custo mensal. As reservas e os planos de economia podem reduzir ainda mais seus custos. Para obter informações sobre oportunidades de economia de custos, consulte Oportunidades de economia de custos após a atualização para o Ambiente do Serviço de Aplicativo v3.

Reduzir verticalmente seus planos do Serviço de Aplicativo

Os SKUs do plano do Serviço de Aplicativo disponíveis para Ambiente do Serviço de Aplicativo v3 são executados na camada Isolado v2 (Iv2). O número de núcleos e a quantidade de RAM são efetivamente dobrados por camada correspondente em comparação com a camada Isolada. Ao migrar, seus planos do Serviço de Aplicativo são convertidos na camada correspondente. Por exemplo, suas instâncias I2 são convertidas em I2v2. Embora a I2 tenha dois núcleos e 7 GB de RAM, a I2v2 tem quatro núcleos e 16 GB de RAM. Se você espera que seus requisitos de capacidade permaneçam iguais, você está superprovisionado e pagando por computação e memória que não está usando. Para esse cenário, você pode reduzir verticalmente sua instância I2v2 para I1v2 e acabar com um número semelhante de núcleos e RAM que você tinha anteriormente.

Perguntas frequentes

• E se não houver suporte para migrar meu Ambiente do Serviço de Aplicativo no momento?
  Nesse momento, você não poderá migrar usando o recurso de migração in-loco. Se você tiver um ambiente sem suporte e desejar migrar imediatamente, consulte as Opções de migração manual.
• Como faço para escolher a opção de migração ideal para mim?
  Leia a árvore de decisão de caminho de migração para decidir qual opção é melhor para seu caso de uso.
• Como saber se devo usar o recurso de migração in-loco?
  O serviço de migração in-loco é melhor para clientes que desejam migrar para o Ambiente do Serviço de Aplicativo v3 com alterações mínimas nas configurações de rede e podem dar suporte a cerca de uma hora de tempo de inatividade do aplicativo. Se você não puder dar suporte ao tempo de inatividade, consulte o recurso de migração lado a lado ou as opções de migração manual. O recurso de migração in-loco cria o Ambiente do Serviço de Aplicativo v3 na mesma sub-rede que o ambiente existente e usa a mesma infraestrutura de rede. Talvez seja necessário considerar as alterações de endereço IP de entrada e saída se você tiver dependências nesses IPs específicos.
• Haverá tempo de inatividade durante a migração?
  Sim, será necessário esperar cerca de uma hora de tempo de inatividade durante o período de serviço de três a seis horas durante a etapa de migração, portanto, planeje adequadamente. Se você tiver um Ambiente de Serviço de Aplicativo diferente para o qual poderá apontar o tráfego durante a migração usando o recurso de migração in-loco, poderá eliminar o tempo de inatividade do aplicativo. Se você não tiver outro Ambiente do Serviço de Aplicativo e não puder dar suporte ao tempo de inatividade, consulte recurso de migração lado a lado ou as opções de migração manual.
• Precisarei fazer algo com meus aplicativos após a migração para colocá-los em execução no novo Ambiente do Serviço de Aplicativo?
  Não, todos os aplicativos em execução no ambiente antigo serão migrados automaticamente para o novo ambiente e executados como antes. Nenhuma entrada do usuário é necessária.
• E se meu Ambiente do Serviço de Aplicativo tiver um sufixo de domínio personalizado?
  O recurso de migração in-loco dá suporte a esse cenário de migração.
• E se meu Ambiente do Serviço de Aplicativo estiver fixado à zona?
  O Ambiente do Serviço de Aplicativo v2 fixado em zona agora é um cenário com suporte para migração usando o recurso de migração. O Ambiente do Serviço de Aplicativo v3 não dá suporte à anexação de zona. Ao migrar para o Ambiente do Serviço de Aplicativo v3, você pode escolher configurar ou não a redundância de zona.
• E se meu Ambiente de Serviço de Aplicativo tiver endereços IP SSL? Não há suporte para IP SSL no Ambiente de Serviço de Aplicativo v3. Você deve remover todos as associações de IP SSL antes de migrar usando o recurso de migração ou uma das opções manuais. Se você pretende usar o recurso de migração in-loco, depois de remover todos as associações de IP SSL, você passará por essa verificação de validação e poderá prosseguir com a migração automatizada.
• Quais propriedades de meu Ambiente do Serviço de Aplicativo serão alteradas?
  Você está no Ambiente do Serviço de Aplicativo v3, portanto, não deixe de examinar os recursos e as diferenças de recursos em comparação com as versões anteriores. Para o Ambiente do Serviço de Aplicativo com ILB, você manterá o mesmo endereço IP do ILB. Para o Ambiente do Serviço de Aplicativo voltado à internet, o endereço IP público e o endereço IP de saída são alterados. Observe que, para o Ambiente do Serviço de Aplicativo de ELB, anteriormente havia um único IP para entrada e saída. Para o Ambiente do Serviço de Aplicativo v3, eles são separados. Para saber mais, confira Rede do Ambiente do Serviço de Aplicativo v3. Para obter uma comparação completa das versões do Ambiente do Serviço de Aplicativo, consulte Comparação de versão do Ambiente do Serviço de Aplicativo.
• O que acontecerá se a migração falhar ou se houver um problema inesperado durante a migração?
  Se houver um problema inesperado, equipes de suporte estarão disponíveis. Você deve migrar ambientes de desenvolvimento antes de tocar em qualquer ambiente de produção para saber mais sobre o processo de migração e ver como isso afeta suas cargas de trabalho.
• O que acontecerá com meu Ambiente do Serviço de Aplicativo antigo?
  Se você decidir migrar um Ambiente do Serviço de Aplicativo usando o recurso de migração in-loco, o ambiente antigo será desligado, excluído e todos os aplicativos serão migrados para um novo ambiente. Seu ambiente antigo não estará mais acessível. Não será possível reverter para o ambiente antigo.
• O que acontecerá com os recursos do Ambiente do Serviço de Aplicativo V1/V2 depois de 31 de agosto de 2024?
  Após 31 de agosto de 2024, se você não tiver migrado para o Ambiente do Serviço de Aplicativo v3, seu Ambiente do Serviço de Aplicativo v1/v2s e os aplicativos implantados neles não estarão mais disponíveis. O Ambiente do Serviço de Aplicativo v1/v2 é hospedado em unidades de escala do serviço de aplicativo em execução na arquitetura de Serviços de nuvem (clássico) que será desativada em 31 de agosto de 2024. Por isso, o Ambiente do Serviço de Aplicativo v1/v2 não estará mais disponível após essa data. Migre para Ambiente do Serviço de Aplicativo v3 para manter seus aplicativos em execução ou salvar ou fazer backup de todos os recursos ou dados que você precisa manter.

Próximas etapas