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

Observação

O recurso de migração descrito neste artigo é usado para a migração automatizada in-loco (mesma sub-rede) do Ambiente do Serviço de Aplicativo v1 e v2 para o Ambiente do Serviço de Aplicativo v3. Se você não solicitou um período de cortesia de 30 dias, revise a visão geral sobre o período de cortesia e solicite um período de cortesia acessando o portal do Azure e visitando a folha Migração para cada um de seus Ambientes do Serviço de Aplicativo.

Se você estiver procurando informações sobre o recurso de migração lado a lado, consulte Migrar para o Ambiente do Serviço de Aplicativo v3 usando o recurso de migração lado a lado. Se você estiver procurando informações sobre opções de migração manual, consulte Opções de migração manual. Para obter ajuda para decidir qual opção de migração é ideal para você, confira a Árvore de decisão do caminho de migração. Para obter mais informações sobre o Ambiente do Serviço de Aplicativo v3, consulte Visão geral do Ambiente do Serviço de Aplicativo v3.

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.

Importante

É recomendável usar esse recurso para ambientes de desenvolvimento primeiro antes de migrar ambientes de produção, para garantir que não haja problemas inesperados. Forneça comentários relacionados a este artigo ou ao recurso usando os botões na parte inferior da página.

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.

Configuração	Configuração do Ambiente do Serviço de Aplicativo v3
Ambiente do Serviço de Aplicativo v2 de ILB (Balanceador de Carga Interno)	Ambiente do Serviço de Aplicativo v3 de ILB
Ambiente do Serviço de Aplicativo v2 do Externo (ELB/para internet com IP público)	Ambiente do Serviço de Aplicativo v3 do ELB
|Ambiente do Serviço de Aplicativo v2 com ILB com sufixo de domínio personalizado	|Ambiente do Serviço de Aplicativo v3 de ILB com sufixo de domínio personalizado
Ambiente do Serviço de Aplicativo v1 de ILB	Ambiente do Serviço de Aplicativo v3 de ILB
Ambiente do Serviço de Aplicativo v1 do ELB	Ambiente do Serviço de Aplicativo v3 do ELB
|Ambiente do Serviço de Aplicativo v1 com ILB com sufixo de domínio personalizado	|Ambiente do Serviço de Aplicativo v3 de ILB com sufixo de domínio personalizado
Ambiente do Serviço de Aplicativo v2 fixado à zona	Ambiente do Serviço de Aplicativo v3 com configuração opcional de redundância de zona

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.

Observação

O Ambiente do Serviço de Aplicativo v3 não tem suporte para IP SSL. Se você usar o IP SSL, deverá remover todas as associações de IP SSL antes de migrar para o Ambiente de Serviço de Aplicativo v3. O recurso de migração dará suporte ao seu ambiente quando todas as associações de IP SSL forem removidas.

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:

Error message	Descrição	Recomendação
A migração só pode ser chamada em um ASE na VNET do ARM e esse ASE está na VNET Clássica.	O Ambiente do Serviço de Aplicativo em VNets Clássicas não podem migrar usando o recurso de migração in-loco.	Migrar usando uma das opções de migração manual.
A Migração ASEv3 ainda não está pronta.	A infraestrutura subjacente não está pronta para dar suporte a Ambiente do Serviço de Aplicativo v3.	Migre usando uma das opções de migração manual se você quiser migrar imediatamente. Caso contrário, aguarde até que o recurso de migração in-loco esteja disponível em sua região.
A migração não pode ser chamada neste ASE, entre em contato com o suporte para migração de ajuda.	O suporte precisa ser contratado para migrar esse Ambiente do Serviço de Aplicativo. Esse problema pode ocorrer devido a configurações personalizadas usadas pelo ambiente.	Abra uma solicitação de suporte para envolver a equipe de suporte para resolve seu problema.
A migração não poderá ser chamada se o IP SSL estiver habilitado em qualquer um dos sites.	O Ambiente do Serviço de Aplicativo que têm sites com IP SSL habilitado não podem ser migrados usando o recurso de migração.	Remova o SSL de IP de todos os seus aplicativos no Ambiente do Serviço de Aplicativo para habilitar o recurso de migração.
A migração completa não poderá ser chamada antes que os endereços IP sejam gerados.	Esse erro aparece se você tentar migrar antes de concluir as etapas de pré-migração.	Verifique se você concluiu todas as etapas de pré-migração antes de tentar migrar. Consulte o guia passo a passo para migração.
A migração para ASEv3 não é permitida para esse ASE.	Você não poderá migrar usando o recurso de migração.	Migrar usando uma das opções de migração manual.
A assinatura tem muitos Ambientes do Serviço de Aplicativo. Remova alguns antes de tentar criar mais.	A cota para sua assinatura do Ambiente do Serviço de Aplicativo foi atendida.	Remova os ambientes desnecessários ou contate o suporte para examinar as opções.
<ZoneRedundant><DedicatedHosts><ASEv3/ASE> não está disponível nesse local.	Esse erro aparece se você estiver tentando migrar um Ambiente do Serviço de Aplicativo em uma região que não dá suporte a um dos recursos solicitados.	Migre usando uma das opções de migração manual se você quiser migrar imediatamente. Caso contrário, aguarde o recurso de migração para dar o suporte a essa configuração do Ambiente do Serviço de Aplicativo.
A migração não pode ser chamada neste ASE até que a atualização ativa seja concluída.	Os Ambientes do Serviço de Aplicativo não podem ser migrados durante as atualizações da plataforma. Você pode definir sua preferência de atualização no portal do Azure. As atualizações levam de oito a 12 horas ou mais, dependendo do tamanho (número de instâncias/núcleos) do Ambiente do Serviço de Aplicativo.	Aguarde até que a atualização seja concluída e, em seguida, migre.
Operação de gerenciamento do Ambiente do Serviço de Aplicativo em andamento.	O Ambiente do Serviço de Aplicativo está passando por uma operação de gerenciamento. Essas operações podem incluir atividades como implantações ou atualizações. A migração estará bloqueada até a conclusão dessas operações.	Você poderá migrar depois que essas operações forem concluídas.
A migração não está disponível para essa assinatura.	O suporte precisa ser contratado para migrar esse Ambiente do Serviço de Aplicativo.	Abra uma solicitação de suporte para envolver a equipe de suporte para resolve seu problema.
Seu InteralLoadBalancingMode não é suportado no momento.	Os Ambientes de Serviço de Aplicativo que têm o InternalLoadBalancingMode definido com determinados valores não podem ser migrados usando o recurso de migração no momento. O InternalLoadBalancingMode deve ser alterado manualmente pela equipe da Microsoft.	Abra uma solicitação de suporte para envolver a equipe de suporte para resolve seu problema. Solicite uma atualização para o InternalLoadBalancingMode para permitir a migração.

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.

Observação

Habilitar a redundância de zona pode levar a cobranças adicionais. Analise o modelo de preço de redundância de zona para obter mais informações.

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.

Importante

Como o dimensionamento é bloqueado durante a migração, você deve dimensionar seu ambiente para o tamanho desejado antes de iniciar a migração. Se o escalonamento automático estiver habilitado e um evento de escalonamento ocorrer antes do início da migração, será necessário aguardar a conclusão dele para iniciar a migração. Para evitar esse problema, desabilite o escalonamento automático 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.

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:

Status	Descrição
Validando e preparando a migração.	A plataforma está validando o suporte à migração e executando as verificações necessárias.
Implantando a infraestrutura do Ambiente do Serviço de Aplicativo v3.	Sua nova infraestrutura do Ambiente do Serviço de Aplicativo v3 está sendo provisionada.
Aguardando a conclusão da infraestrutura.	A plataforma está validando sua nova infraestrutura e executando as verificações necessárias.
Configurando a rede. O período de inatividade da migração foi iniciado. Os aplicativos não são acessíveis.	A plataforma está excluindo sua infraestrutura antiga e movendo todos os seus aplicativos para seu novo Ambiente do Serviço de Aplicativo v3. Seus aplicativos estão inativos e não estão aceitando tráfego.
Executando validações pós-migração.	A plataforma está executando as verificações necessárias para garantir que a migração tenha êxito.
Finalizando a migração.	A plataforma está finalizando a 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.

Recomendamos que você use o portal do Azure para a experiência de migração in-loco. Se você decidir utilizar a CLI do Azure para realizar a migração, siga as etapas descritas aqui na ordem e conforme escritas, pois você está fazendo chamadas à API REST do Azure. Recomendamos que você use a CLI do Azure para fazer essas chamadas à API. Para obter informações sobre outros métodos, confira referência à API REST do Azure.

Para este guia, instale a CLI do Azure ou use o Azure Cloud Shell, e use um shell Bash.

Observação

Recomendamos que você use um shell Bash para executar os comandos indicados neste guia. Os comandos podem não ser compatíveis com convenções do PowerShell e caracteres de escape.

1. Obter sua ID do Ambiente do Serviço de Aplicativo

Execute os comandos a seguir para obter sua ID do Ambiente do Serviço de Aplicativo e armazená-la como uma variável de ambiente. Substitua os espaços reservados para nome e grupos de recursos pelos valores do Ambiente do Serviço de Aplicativo que você deseja migrar. ASE_RG e VNET_RG serão os mesmos se sua rede virtual e o Ambiente do Serviço de Aplicativo estiverem no mesmo grupo de recursos.

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. Validar que a migração tem suporte

O comando a seguir verifica se o seu Ambiente do Serviço de Aplicativo tem suporte para migração e valida se ele está na versão de build com suporte para migração.

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

Se não houver erros, sua migração terá suporte e você poderá prosseguir para a próxima etapa.

Se for necessário iniciar um upgrade do Ambiente do Serviço de Aplicativo para a versão de compilação com suporte, execute o comando a seguir. Execute esse comando somente se você falhar na etapa de validação e for instruído a atualizar o Ambiente do Serviço de Aplicativo.

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

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

Execute o comando a seguir para criar endereços IP. Essa etapa leva cerca de 15 minutos para ser concluída. Não dimensione nem faça alterações no seu Ambiente do Serviço de Aplicativo durante esse tempo.

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

Execute o seguinte comando para verificar o status desta etapa:

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

Se a etapa estiver em andamento, você receberá o status Migrating. Depois de obter o status Ready, execute o comando a seguir para visualizar seus novos IPs. Se você não vir os novos IPs imediatamente, aguarde alguns minutos e tente novamente.

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

4. Atualizar recursos dependentes com novos IPs

Usando os novos IPs, atualize qualquer um dos seus recursos ou componentes de rede para garantir que o novo ambiente funcione conforme esperado quando a migração for concluída. É sua responsabilidade fazer as atualizações necessárias.

5. 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. As versões anteriores não exigiam essa delegação. É necessário confirmar se sua sub-rede está delegada corretamente e atualizar a delegação (se necessário) antes de migrar. Você pode atualizar a delegação executando o comando a seguir ou navegando até a sub-rede no portal do Azure.

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

6. Confirme se não há bloqueios na rede virtual

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, você pode adicionar novamente os bloqueios após a conclusão da migração.

Use o seguinte comando para verificar se sua rede virtual tem algum bloqueio:

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

Exclua todos os bloqueios existentes usando o seguinte comando:

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

Para obter os comandos relacionados para verificar se a assinatura ou grupo de recursos tem bloqueios, consulte a referência da CLI do Azure quanto a bloqueios.

7. Preparar suas configurações

Você pode conferir redundância de zona ao seu novo recurso de Ambiente do Serviço de Aplicativo v3 se o ambiente existente estiver em uma região que dê suporte à redundância de zona. A redundância de zona pode ser configurada definindo a propriedade zoneRedundant como true.

Se o Ambiente do Serviço de Aplicativo existente utilizar um sufixo de domínio personalizado, será necessário configurar um para o novo recurso de Ambiente do Serviço de Aplicativo v3 durante o processo de migração. A migração falhará se você não configurar um sufixo de domínio personalizado e estiver utilizando um atualmente. A migração também falhará se você tentar adicionar um sufixo de domínio personalizado durante a migração para um ambiente que não tenha um sufixo configurado. Para obter mais informações sobre os sufixos de domínio personalizado do Ambiente do Serviço de Aplicativo v3, incluindo os respectivos requisitos, instruções passo a passo e melhores práticas, confira Sufixo de domínio personalizado para Ambientes do Serviço de Aplicativo.

Observação

Se você estiver configurando um sufixo de domínio personalizado ao adicionar as permissões de rede no Azure Key Vault, verifique se o cofre de chaves permite o acesso dos novos endereços IP de saída do Ambiente do Serviço de Aplicativo gerados na etapa 3. Caso esteja acessando seu cofre de chaves usando um ponto de extremidade privado, verifique se configurou o acesso privado corretamente.

Se a migração não incluir um sufixo de domínio personalizado e você não quiser habilitar a redundância de zona, você poderá prosseguir para a migração.

Para definir essas configurações, crie um arquivo chamado parameters.json com os detalhes a seguir baseados no seu cenário. Não inclua as propriedades de sufixo de domínio personalizado se não estiver usando esse recurso na sua migração. Lembre-se de preencher com atenção o valor da propriedade zoneRedundant, pois essa configuração é irreversível após a migração. Defina o valor da propriedade kind com base na versão atual do seu Ambiente do Serviço de Aplicativo. Os valores aceitos para a propriedade kind são ASEV1 e ASEV2.

Se você estiver migrando sem um sufixo de domínio personalizado e estiver habilitando a redundância de zona, use este código:

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

Se você estiver usando uma identidade gerenciada atribuída pelo usuário para sua configuração de sufixo de domínio personalizado e estiver habilitando a redundância de zona, use este código:

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

Se você estiver usando uma identidade gerenciada atribuída pelo sistema para sua configuração de sufixo de domínio personalizado e não estiver habilitando a redundância de zona, use este código:

{
    "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. Migrar para o Ambiente do Serviço de Aplicativo v3 e verificar o status

Depois de concluir todas as etapas acima, você pode iniciar a migração. Verifique se você entende as implicações da migração.

Essa etapa leva de três a seis horas para migrações da v2 para a v3 e até seis horas para migrações da v1 para a v3, dependendo do tamanho do ambiente. Durante esse tempo, existe cerca de uma hora de tempo de inatividade do aplicativo. A colocação em escala, as implantações e as modificações em seu Ambiente do Serviço de Aplicativo existente são bloqueadas durante essa etapa.

Inclua o parâmetro body no comando a seguir se você estiver habilitando a redundância de zona e/ou estiver configurando um sufixo de domínio personalizado. Se nenhuma dessas configurações se aplicar à sua migração, você poderá remover o parâmetro do comando.

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

Execute os comandos a seguir para verificar o status detalhado da migração. Para obter informações sobre os status, consulte as descrições de status da migração.

O primeiro comando obtém a ID da operação para a migração. Copie o valor da propriedade ID.

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

Substitua o espaço reservado para a ID da operação no comando a seguir pelo valor copiado. Esse comando retorna o status detalhado da migração. Você pode executar esse comando sempre que necessário para obter o status mais recente.

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

Depois de obter o status Ready, a migração será feita e você terá um recurso de Ambiente do Serviço de Aplicativo v3. Seus aplicativos agora estão em execução no novo ambiente.

Obtenha os detalhes do novo ambiente executando o comando a seguir ou navegando até o portal do Azure.

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

1. Validar que a migração tem suporte

Do portal do Microsoft Azure, navegue até a página Migração do Ambiente do Serviço de Aplicativo que você está migrando. Você pode acessar a página Migração selecionando a faixa na parte superior da página Visão geral do seu Ambiente do Serviço de Aplicativo ou selecionando o item Migração no menu esquerdo.

Selecione a opção de migração "In-loco" para iniciar o processo de migração in-loco. Se você selecionar a opção de migração lado a lado, será levado para a documentação desse processo de migração. Não selecione a opção de migração lado a lado se quiser usar o recurso de migração in-loco.

Na página Migração, a plataforma valida se a migração é compatível com o seu Ambiente do Serviço de Aplicativo. Selecione Validar e confirme que deseja prosseguir com a validação. O processo de validação leva alguns segundos.

Se seu ambiente não for suportado para migração, uma faixa será exibida na parte superior da página e incluirá uma mensagem de erro com um motivo. Para obter descrições das mensagens de erro que podem aparecer se você não estiver qualificado para a migração, confira Solução de problemas.

Caso precise iniciar uma atualização para atualizar o Ambiente do Serviço de Aplicativo para a versão de build com suporte, será solicitado que você inicie a atualização, o que pode levar de 8 a 12 horas ou mais, dependendo do tamanho do seu ambiente. Selecione Atualizar para iniciar a atualização. Ao concluir a atualização, você passará pela validação e poderá usar o recurso de migração para iniciar a migração.

Se houver suporte à migração para o Ambiente do Serviço de Aplicativo, prossiga para a próxima etapa do processo. A página Migração o guiará por uma série de etapas para concluir a migração.

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

Em Obter novos endereços IP, confirme se você entendeu as implicações e selecione o botão Iniciar. Essa etapa leva cerca de 15 minutos para ser concluída. Não é possível escalar ou fazer alterações em seu Ambiente do Serviço de Aplicativo existente durante esse tempo.

3. Atualizar recursos dependentes com novos IPs

Quando a etapa anterior for concluída, você verá os endereços IP para o novo recurso de Ambiente do Serviço de Aplicativo v3. Use os novos IPs para atualizar todos os recursos e componentes de rede, para que seu novo ambiente funcione conforme o esperado quando a migração for concluída. É sua responsabilidade fazer as atualizações necessárias.

4. 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. As versões anteriores não exigiam essa delegação. É necessário confirmar se sua sub-rede está delegada corretamente e atualizar a delegação (se necessário) antes de migrar. Um link para sua sub-rede é fornecido para que você possa confirmar e atualizar conforme necessário.

5. Reconhecer as alterações no tamanho da instância

Selecione o botão Confirmar para afirmar que você entende que seus planos do Serviço de Aplicativo são convertidos do nível Isolado para o nível Isolado v2 correspondente como parte da migração.

6. Confirme se a rede virtual não tem bloqueios

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. Para obter detalhes sobre como verificar se sua assinatura ou grupo de recursos tem bloqueios, consulte Configurar bloqueios.

7. Escolha suas configurações

Você pode conferir redundância de zona ao seu novo recurso de Ambiente do Serviço de Aplicativo v3 se o ambiente existente estiver em uma região que dê suporte à redundância de zona.

Selecione a caixa de seleção Habilitado se desejar configurar a redundância de zona.

Se o seu ambiente estiver em uma região que não der suporte à redundância de zona, a caixa de seleção ficará indisponível. Se você precisar de um recurso de Ambiente do Serviço de Aplicativo v3 com redundância de zona, use uma das opções de migração manual e crie o recurso em uma das regiões que dão suporte à redundância de zona.

Se o Ambiente do Serviço de Aplicativo existente usar um sufixo de domínio personalizado, será necessário configurar um sufixo desse tipo para o novo recurso de Ambiente do Serviço de Aplicativo v3. As opções de configuração do sufixo de domínio personalizado serão mostradas se essa situação se aplicar a você. Não é possível migrar até que você forneça as informações exigidas.

Se quiser usar um sufixo de domínio personalizado, mas não tiver um configurado no momento, você poderá configurar um sufixo desse tipo após a conclusão da migração. Para obter mais informações sobre os sufixos de domínio personalizado do Ambiente do Serviço de Aplicativo v3, incluindo os respectivos requisitos, instruções passo a passo e melhores práticas, confira Sufixo de domínio personalizado para Ambientes do Serviço de Aplicativo.

Observação

Se você estiver configurando um sufixo de domínio personalizado ao adicionar as permissões de rede no Azure Key Vault, verifique se o cofre de chaves permite o acesso dos novos endereços IP de saída do Ambiente do Serviço de Aplicativo gerados na etapa 2. Caso esteja acessando seu cofre de chaves usando um ponto de extremidade privado, verifique se configurou o acesso privado corretamente.

Depois de você adicionar os detalhes do seu sufixo de domínio personalizado, o botão Migrar ficará disponível.

8. Migrar para o Ambiente do Serviço de Aplicativo v3

Depois de concluir todas as etapas acima, você pode iniciar a migração. Verifique se você entende as implicações da migração, inclusive o que acontece durante esse tempo.

Essa etapa leva de três a seis horas para migrações da v2 para a v3 e até seis horas para migrações da v1 para a v3, dependendo do tamanho do ambiente. A colocação em escala e as modificações em seu Ambiente do Serviço de Aplicativo existente são bloqueadas durante essa etapa.

Observação

Em casos raros, você poderá ver uma notificação no portal informando "Falha na migração para o Ambiente do Serviço de Aplicativo v3" após iniciar a migração. Há um bug conhecido que pode disparar essa notificação mesmo se a migração estiver progredindo. Verifique o log de atividades do Ambiente do Serviço de Aplicativo para determinar a validade dessa mensagem de erro. Na maioria dos casos, a atualização da página resolve o problema e a mensagem de erro desaparece. Se a mensagem de erro persistir, entre em contato com o suporte para obter assistência.

No momento, os status de migração detalhados só estão disponíveis ao usar a CLI do Azure. Para obter mais informações, consulte as diretrizes da CLI na seção CLI do Azure para migrar para o Ambiente do Serviço de Aplicativo v3. Você pode verificar o status da migração com a CLI, mesmo se usar o portal para fazer a migração.

Quando a migração estiver concluída, você terá um recurso de Ambiente do Serviço de Aplicativo v3 e todos os seus aplicativos estarão em execução no novo ambiente. Você pode confirmar a versão do ambiente verificando a página Configuração do seu Ambiente do Serviço de Aplicativo.

Se a migração incluir um sufixo de domínio personalizado, o domínio foi mostrado na seção Essentials da página Visão Geral do portal para o Ambiente do Serviço de Aplicativo do Azure v1/v2, mas não é mais mostrado no Ambiente do Serviço de Aplicativo v3. Em vez disso, para o Ambiente do Serviço de Aplicativo v3, acesse a página Sufixo de domínio personalizado para confirmar que o sufixo de domínio personalizado está configurado corretamente. Você também poderá remover a configuração se não precisar mais dela ou configurá-la caso não o tenha feito anteriormente.

Observação

Se a migração incluir um sufixo de domínio personalizado, a configuração do sufixo de domínio personalizado poderá ser mostrada como degradada depois que a migração for concluída devido a um bug conhecido. O Ambiente do Serviço de Aplicativo ainda deve funcionar conforme o esperado. O status degradado deve se resolver dentro de 6 a 8 horas. Se a configuração for degradada após 8 horas ou se o sufixo de domínio personalizado não estiver funcionando, entre em contato com o suporte.

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.

Observação

Devido à conversão dos planos do Serviço de Aplicativo de Isolado para Isolado v2, seus aplicativos poderão ser provisionados excessivamente após a migração, uma vez que a camada Isolado v2 tem mais memória e CPU por tamanho de instância correspondente. Você terá a oportunidade de escalar o ambiente conforme necessário quando a migração for concluída. Para obter mais informações, revise os Detalhes do SKU.

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

Rede do Ambiente do Serviço de Aplicativo v3

Usar um Ambiente do Serviço de Aplicativo v3

Sufixo do Custom Domain