Migração para o Ambiente do Serviço de Aplicativo v3 usando o recurso de migração in-loco

Nota

O recurso de migração descrito neste artigo é usado para 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 carência de 30 dias, revise a visão geral do período de carência e, em seguida, solicite um período de carência acessando o portal do Azure e visitando a folha Migração para cada um dos 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ê, consulte Árvore de decisão de 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 seu Ambiente do Serviço de Aplicativo v1 e v2 para um Ambiente do Serviço de Aplicativo v3. Existem diferentes opções de migração. Analise a árvore de decisão do caminho de migração para decidir qual opção é melhor para seu caso de uso. O Ambiente do Serviço de Aplicativo v3 oferece vantagens e diferenças de recursos em relação às versões anteriores. Certifique-se de revisar os recursos suportados do Ambiente do Serviço de Aplicativo v3 antes de migrar para reduzir o risco de um problema inesperado do aplicativo.

O recurso de migração in-loco automatiza a migração para o Ambiente do Serviço de Aplicativo v3 atualizando o Ambiente do Serviço de Aplicativo existente na mesma sub-rede. Essa 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 em suas configurações de rede. Você também deve ser capaz de suportar cerca de uma hora de tempo de inatividade do aplicativo. Se você não puder suportar o tempo de inatividade, consulte o recurso de migração lateral ou as opções de migração manual.

Importante

Recomenda-se usar esse recurso para ambientes de desenvolvimento primeiro antes de migrar qualquer ambiente de produção para garantir que não haja problemas inesperados. Por favor, forneça qualquer feedback relacionado a este artigo ou ao recurso usando os botões na parte inferior da página.

Cenários suportados

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

Microsoft Azure operado pela 21Vianet

• China Leste 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 seu Ambiente do Serviço de Aplicativo existente. Todos os Ambientes do Serviço de Aplicativo suportados podem ser migrados para um Ambiente do Serviço de Aplicativo v3 redundante de zona usando o recurso de migração in-loco, desde que o ambiente esteja em uma região que ofereça suporte à redundância de zona. Você pode 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 ILB (Balanceador de Carga Interno) v2	Ambiente do Serviço de Aplicativo ILB v3
Ambiente de Serviço de Aplicativo Externo (ELB/Internet voltado para IP público) v2	Ambiente do Serviço de Aplicativo ELB v3
ILB App Service Environment v2 com um sufixo de domínio personalizado	Ambiente do Serviço de Aplicativo ILB v3 com um sufixo de domínio personalizado
Ambiente do Serviço de Aplicativo ILB v1	Ambiente do Serviço de Aplicativo ILB v3
Ambiente do Serviço de Aplicativo ELB v1	Ambiente do Serviço de Aplicativo ELB v3
ILB App Service Environment v1 com um sufixo de domínio personalizado	Ambiente do Serviço de Aplicativo ILB v3 com um sufixo de domínio personalizado
Ambiente do Serviço de Aplicativo fixo por zona v2	Ambiente do Serviço de Aplicativo v3 com configuração opcional de redundância de zona

Se você quiser que seu 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 assim que a migração for concluída. Para obter mais informações, consulte Configurar sufixo de domínio personalizado para o Ambiente do Serviço de Aplicativo.

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

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

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

• O seu novo Ambiente do Serviço de Aplicações v3 está na sub-rede existente que foi utilizada para o seu ambiente antigo.
• Não é possível alterar a região na qual o Ambiente do Serviço de Aplicações está localizado.
• O Ambiente do Serviço de Aplicativo ELB não pode ser migrado para o Ambiente do Serviço de Aplicativo ILB v3 e vice-versa.
• Se o Ambiente do Serviço de Aplicações existente utilizar um sufixo de domínio personalizado, terá de configurar o sufixo de domínio personalizado para o Ambiente do Serviço de Aplicações v3 durante o processo de migração.
  • Se já não pretender utilizar um sufixo de domínio personalizado, pode removê-lo quando a migração estiver concluída.

O Ambiente do Serviço de Aplicativo v3 não oferece suporte aos seguintes recursos que podem ser usados com seu Ambiente do Serviço de Aplicativo v1 ou v2 atual.

• Configurar um enlace TLS/SSL baseado em IP com as aplicações.
• O Ambiente do Serviço de Aplicações v3 não reverte para o DNS do Azure se os seus servidores DNS personalizados configurados na rede virtual não conseguirem resolver um nome especificado. Se esse comportamento for necessário, certifique-se de que 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 suporta os seguintes cenários. 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 do Serviço de Aplicações v2 do ELB com endereços SSL IP
• Ambiente do Serviço de Aplicações v1 do ELB com endereços SSL IP
• Ambiente do Serviço de Aplicativo com um nome que não atende aos limites de caracteres. O nome inteiro, incluindo o sufixo de 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 atingir o limite de caracteres, deverá migrar 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 analisa seu Ambiente do Serviço de Aplicativo para confirmar o suporte à migração in-loco. Se o seu cenário não passar em todas as verificações de validação, você não poderá migrar neste momento usando o recurso de migração in-loco. Se o ambiente estiver em um estado não íntegro ou suspenso, você não poderá migrar até fazer as atualizações necessárias.

Nota

O Ambiente do Serviço de Aplicativo v3 não suporta IP SSL. Se você usar IP SSL, deverá remover todas as associações IP SSL antes de migrar para o Ambiente do Serviço de Aplicativo v3. O recurso de migração suportará seu ambiente assim que todas as ligações IP SSL forem removidas.

Resolução de Problemas

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

Mensagem de erro	Description	Recomendação
A migração só pode ser chamada em um ASE em ARM VNET e este ASE está em VNET Classic.	Os Ambientes do Serviço de Aplicativo em VNets clássicas não podem migrar usando o recurso de migração in-loco.	Migre 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 suportar o Ambiente do Serviço de Aplicativo v3.	Migre usando uma das opções de migração manual se quiser migrar imediatamente. Caso contrário, aguarde até que o recurso de migração in-loco esteja disponível na sua região.
A migração não pode ser chamada neste ASE, entre em contato com o suporte para obter ajuda na migração.	O suporte precisa ser contratado para migrar esse Ambiente do Serviço de Aplicativo. Esse problema é potencialmente devido às configurações personalizadas usadas por esse ambiente.	Abra um caso de suporte para contratar o suporte para resolver seu problema.
A migração não pode ser chamada se o IP SSL estiver habilitado em qualquer um dos sites.	Os Ambientes 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 IP SSL 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 pode ser chamada antes que os endereços IP sejam gerados.	Este erro aparece se você tentar migrar antes de concluir as etapas de pré-migração.	Certifique-se de concluir todas as etapas de pré-migração antes de tentar migrar. Consulte o guia passo a passo para migrar.
A migração para o ASEv3 não é permitida para este ASE.	Não é possível migrar usando o recurso de migração.	Migre usando uma das opções de migração manual.
A assinatura tem muitos ambientes do Serviço de Aplicativo. Por favor, remova alguns antes de tentar criar mais.	A cota do Ambiente do Serviço de Aplicativo para sua assinatura é atendida.	Remova ambientes desnecessários ou contacte o suporte para rever as suas opções.
<ZoneRedundant><DedicatedHosts><ASEv3/ASE> não está disponível neste local.	Este erro aparece se estiver a tentar migrar um Ambiente do Serviço de Aplicação numa região que não suporta uma das funcionalidades solicitadas.	Migre usando uma das opções de migração manual se quiser migrar imediatamente. Caso contrário, aguarde até que a funcionalidade de migração suporte esta configuração do Ambiente do Serviço de Aplicações.
A migração não pode ser chamada neste ASE até que a atualização ativa tenha sido concluída.	Os Ambientes do Serviço de Aplicativo não podem ser migrados durante as atualizações da plataforma. Pode definir a sua preferência de atualização no portal do Azure. As atualizações levam de 8 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 termine e, em seguida, migre.
Operação de gerenciamento do Ambiente do Serviço de Aplicativo em andamento.	Seu 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 é bloqueada até que estas operações estejam concluídas.	Você pode migrar assim que essas operações forem concluídas.
Migrar não está disponível para esta assinatura.	O suporte precisa ser contratado para migrar esse Ambiente do Serviço de Aplicativo.	Abra um caso de suporte para contratar o suporte para resolver seu problema.
Seu InternalLoadBalancingMode não é suportado no momento.	Os Ambientes do Serviço de Aplicativo que têm InternalLoadBalancingMode definido para 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 um caso de suporte para contratar o suporte para resolver seu problema. Solicite uma atualização para o InternalLoadBalancingMode para permitir a migração.

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

A migração in-loco consiste em uma série de etapas que devem ser seguidas em ordem. Os pontos principais são fornecidos para um subconjunto dos passos. É importante compreender o que acontece durante estes passos e como o seu ambiente e aplicações são afetados. Depois de analisar as informações seguintes e quando estiver pronto para migrar, siga o guia passo a passo.

Valide se a migração é suportada usando o recurso de migração in-loco para seu Ambiente do Serviço de Aplicativo

A plataforma valida que seu Ambiente do Serviço de Aplicativo pode ser migrado usando o recurso de migração in-loco. Se o Ambiente do Serviço de Aplicativo não passar em todas as verificações de validação, você não poderá migrar neste momento usando o recurso de migração in-loco. Consulte a seção de solução de problemas para obter detalhes sobre as possíveis causas da falha de validação. Se o 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 in-loco, consulte as opções de migração manual.

A validação também verifica se o Ambiente do Serviço de Aplicativo está na compilação mínima necessária para a migração. Essa compilação pode ser mais recente do que a compilação padrão implantada com o ciclo de atualização/manutenção da plataforma de rotina. A compilação mínima é atualizada periodicamente para garantir que as últimas correções de bugs e melhorias estejam disponíveis. Se o Ambiente do Serviço de Aplicativo não estiver na compilação mínima, você mesmo precisará iniciar a atualização. Essa atualização é um processo padrão em que o Ambiente do Serviço de Aplicativo não é afetado, mas você não pode 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 seu ambiente. Se você planejar uma janela de tempo específica para sua migração, deverá executar a verificação de validação 24 a 48 horas antes do horário de migração planejado para garantir que tenha tempo para uma atualização, se necessário.

Gerar endereços IP para o seu novo Ambiente do Serviço de Aplicações v3

A plataforma cria o novo IP de entrada (se você estiver migrando um Ambiente de Serviço de Aplicativo ELB) e os novos endereços IP de saída. Enquanto estes IPs estão a ser criados, a atividade no seu Ambiente do Serviço de Aplicações existente não é interrompida. No entanto, não pode dimensionar nem fazer alterações no seu ambiente existente. Este processo demora cerca de 15 minutos a concluir.

Quando terminar, irá receberá os novos IPs que o seu Ambiente do Serviço de Aplicações v3 futuro utiliza. Estes novos IPs não têm efeito no seu ambiente existente. Os IPs utilizados pelo ambiente existente continuam a ser utilizados até que o ambiente existente seja encerrado durante o passo de migração.

Atualizar recursos dependentes com novos IPs

Depois que os novos IPs são criados, você tem 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 DNS, grupos de segurança de rede e quaisquer outros recursos que dependam desses IPs. Para o Ambiente do Serviço de Aplicativo ELB, você também tem o novo endereço IP de entrada que pode ser usado para configurar novos pontos de extremidade com serviços como o Gerenciador de Tráfego ou o Azure Front Door. É sua responsabilidade atualizar todos e quaisquer 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 até ter feito todas as atualizações necessárias. Esta etapa também é um bom momento para revisar as alterações de dependência de rede de entrada e saída ao migrar para o Ambiente do Serviço de Aplicativo v3, incluindo a alteração de porta para a sonda de integridade do Balanceador de Carga do Azure, 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 em que está tenha uma única delegação de Microsoft.Web/hostingEnvironments. A migração não poderá ser bem-sucedida se a sub-rede do Ambiente do Serviço de Aplicativo não estiver delegada ou se você delegá-la a um recurso diferente.

Reconhecer alterações no tamanho da instância

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

Garantir que não existem bloqueios nos seus recursos

Os bloqueios de 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. Os bloqueios podem ser readicionados, se necessário, assim que 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 em um escopo pai, todos os recursos dentro desse escopo herdam o mesmo bloqueio. Se você tiver bloqueios aplicados na assinatura, no grupo de recursos ou no 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 seus recursos para proteger sua infraestrutura.

Verifique se não há Políticas do Azure bloqueando a migração

A Política do Azure pode ser usada para negar a criação e a modificação de recursos para determinadas entidades. 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. A política pode ser readicionada, se necessário, assim que a migração for concluída. Para obter mais informações sobre a Política do Azure, consulte Visão geral da Política do Azure.

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

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

Nota

Ativar a redundância de zona pode levar a cobranças adicionais. Analise o modelo de preços 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. Você precisa 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 requisitos, instruções passo a passo e práticas recomendadas, consulte Configurar sufixo de domínio personalizado para o Ambiente do Serviço de Aplicativo. Você deve configurar um sufixo de domínio personalizado para seu novo ambiente, mesmo que não queira mais usá-lo. Quando a migração estiver concluída, 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á exibido 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 onde você pode 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 de host padrão incluirá seu sufixo de domínio personalizado e estará na forma APP-NAME.internal.contoso.com. No Ambiente do Serviço de Aplicativo v3, o nome de host padrão sempre usa o sufixo de domínio padrão e está no formato 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 Aplicações v3

Depois de concluir os passos anteriores, deverá continuar a migração o mais rapidamente 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 você tiver o dimensionamento automático habilitado, se ocorrer um evento de dimensionamento antes do início da migração, será necessário aguardar até que o evento de dimensionamento seja concluído antes de iniciar a migração. Você deve desativar o dimensionamento automático antes de iniciar a migração para evitar esse problema. Se você precisar dimensionar seu ambiente após a migração, poderá fazê-lo assim que a migração for concluída.

A migração requer uma janela de serviço de três a seis horas para migrações do Ambiente do 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. A janela de serviço pode ser estendida em casos raros em que a intervenção manual da equipe de serviço é necessária. Durante a migração, as configurações do dimensionamento e do ambiente são bloqueados e ocorrem os seguintes eventos:

• O Ambiente do Serviço de Aplicações existente é encerrado e substituído pelo novo Ambiente do Serviço de Aplicações v3.
• Todos os planos do Serviço de Aplicativo no Ambiente do Serviço de Aplicativo são convertidos da camada Isolado para Isolado v2.
• Todas as aplicações que estão no seu Ambiente do Serviço de Aplicações estão temporariamente inativas. Você deve esperar cerca de uma hora de inatividade durante esse período.
  • Se você não puder suportar o tempo de inatividade, consulte o recurso de migração lado a lado ou as alternativas de migração.
• Os endereços públicos utilizados pelo Ambiente do Serviço de Aplicações mudam para os IPs gerados durante o passo de geração de IP.

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

Status	Description
Validação e preparação da migração.	A plataforma está validando o suporte à migração e realizando 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 realizando as verificações necessárias.
Configuração de networking. O período de inatividade da migração foi iniciado. Os aplicativos não estã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 fora do ar e não estão aceitando tráfego.
Executando validações pós-migração.	A plataforma está realizando as verificações necessárias para garantir que a migração seja bem-sucedida.
Finalizando a migração.	A plataforma está finalizando a migração.

Tal como no passo de geração de IP, não pode dimensionar, modificar o seu Ambiente do Serviço de Aplicações nem implementar aplicações neste durante este processo. Quando a migração estiver concluída, as aplicações que estavam no Ambiente do Serviço de Aplicações antigo serão executadas no novo Ambiente do Serviço de Aplicações v3.

Usar o recurso de migração in-loco

Pré-requisitos

Certifique-se de entender como a migração para o Ambiente do Serviço de Aplicativo v3 afeta seus aplicativos. Analise o processo de migração para entender o cronograma do processo e onde e quando você precisa se envolver. Consulte também as Perguntas Frequentes, que podem responder a algumas das suas perguntas.

Certifique-se de que não existem bloqueios na sua rede virtual, grupo de recursos, recurso ou subscrição. Bloqueia operações de plataforma de bloqueio durante a migração.

Certifique-se de que nenhuma política do Azure esteja bloqueando 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 bloqueada 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 assim que a migração for concluída. Se o dimensionamento automático estiver habilitado, se ocorrer um evento de dimensionamento antes do início da migração, a migração será bloqueada até que o evento de dimensionamento seja concluído. Você deve desativar 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 usar a CLI do Azure para a migração, siga as etapas descritas aqui na ordem e conforme escrito, porque você está fazendo chamadas de API REST do Azure. Recomendamos que você use a CLI do Azure para fazer essas chamadas de API. Para obter informações sobre outros métodos, consulte Referência da API REST do Azure.

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

Nota

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

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

Execute os comandos a seguir para obter sua ID de Ambiente do Serviço de Aplicativo e armazená-la como uma variável de ambiente. Substitua os espaços reservados para o nome e os grupos de recursos por seus valores para o Ambiente do Serviço de Aplicativo que você deseja migrar. ASE_RG e VNET_RG são os mesmos se a 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. Valide se a migração é suportada

O comando a seguir verifica se o Ambiente do Serviço de Aplicativo tem suporte para migração e valida se o Ambiente do Serviço de Aplicativo está na versão de compilação 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 será suportada e você poderá continuar para a próxima etapa.

Se você precisar iniciar uma atualização para atualizar seu Ambiente do Serviço de Aplicativo para a versão de compilação suportada, execute o seguinte comando. Execute este comando somente se você falhar na etapa de validação e for instruído a atualizar seu Ambiente do Serviço de Aplicativo.

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

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

Execute o seguinte comando para criar novos endereços IP. Esta etapa leva cerca de 15 minutos para ser concluída. Não dimensione ou faça alterações no seu Ambiente do Serviço de Aplicativo existente durante esse período.

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ê obterá um status de Migrating. Depois de obter um status de Ready, execute o seguinte comando para exibir 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. Atualize recursos dependentes com novos IPs

Usando os novos IPs, atualize qualquer um dos seus recursos ou componentes de rede para garantir que seu novo ambiente funcione como pretendido após a conclusão da migração. É da sua responsabilidade fazer as atualizações necessárias.

5. Delegue a sub-rede do Ambiente do Serviço de Aplicativo

O Ambiente do Serviço de Aplicativo v3 requer que a sub-rede em que está tenha uma única delegação de Microsoft.Web/hostingEnvironments. As versões anteriores não exigiam essa delegação. Você precisa 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 seguinte comando ou indo para 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 de 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 comandos relacionados para verificar se sua assinatura ou grupo de recursos tem bloqueios, consulte a referência da CLI do Azure para bloqueios.

7. Prepare suas configurações

Você pode tornar redundante sua nova zona de recursos do Ambiente do Serviço de Aplicativo v3 se o ambiente existente estiver em uma região que ofereça suporte à redundância de zona. Você pode configurar a redundância de zona definindo a zoneRedundant propriedade como true.

Se o Ambiente do Serviço de Aplicativo existente usar um sufixo de domínio personalizado, você precisará configurar um para o novo recurso do 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 usando 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 configurado. Para obter mais informações sobre sufixos de domínio personalizados do Ambiente do Serviço de Aplicativo v3, incluindo requisitos, instruções passo a passo e práticas recomendadas, consulte Sufixo de domínio personalizado para ambientes do Serviço de Aplicativo.

Nota

Se estiver a configurar um sufixo de domínio personalizado, quando estiver a adicionar as permissões de rede no cofre de chaves do Azure, certifique-se de que o cofre de chaves permite o acesso a partir dos novos endereços IP de saída do Ambiente do Serviço de Aplicação que foram gerados no passo 3. Se você estiver 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 estiver habilitando a redundância de zona, poderá passar para a migração.

Para definir essas configurações, crie um arquivo chamado parameters.json com os seguintes detalhes com base no seu cenário. Não inclua as propriedades de um sufixo de domínio personalizado se esse recurso não se aplicar à sua migração. Preste atenção ao valor do imóvel, pois essa configuração é irreversível após a zoneRedundant migração. Defina o kind valor da propriedade com base na versão existente do Ambiente do Serviço de Aplicativo. Os valores aceitos para a kind propriedade 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/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/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. Migre para o Ambiente do Serviço de Aplicativo v3 e verifique o status

Depois de concluir todas as etapas anteriores, você pode iniciar a migração. Certifique-se de que compreende as implicações da migração.

Esta etapa leva de três a seis horas para migrações de v2 para v3 e até seis horas para migrações de v1 para v3, dependendo do tamanho do ambiente. Durante esse tempo, há cerca de uma hora de inatividade do aplicativo. O dimensionamento, as implantações e as modificações no Ambiente do Serviço de Aplicativo existente são bloqueados durante esta etapa.

Inclua o parâmetro no comando a seguir se estiver habilitando a body redundância de zona e/ou configurando um sufixo de domínio personalizado. Se nenhuma dessas configurações se aplicar à 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 seguintes comandos para verificar o status detalhado da migração. Para obter informações sobre os status, consulte as descrições do status da migração.

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

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. Este comando retorna o status detalhado da migração. Você pode executar esse comando quantas vezes forem necessárias 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 um status de , a migração é concluída e você tem um recurso do Ambiente do ReadyServiço de Aplicativo v3. Seus aplicativos agora estão sendo executados em seu novo ambiente.

Obtenha os detalhes do seu novo ambiente executando o seguinte comando ou indo para o portal do Azure.

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

1. Valide se a migração é suportada

No portal do Azure, vá para 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 o banner 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 à esquerda.

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á direcionado 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 é suportada para o seu Ambiente do Serviço de Aplicativo. Selecione Validar e confirme que deseja continuar com a validação. O processo de validação leva alguns segundos.

Se o seu ambiente não for suportado para migração, um banner aparecerá 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 migração, consulte Solução de problemas.

Se você precisar iniciar uma atualização para atualizar seu Ambiente do Serviço de Aplicativo para a versão de compilação suportada, será solicitado que você inicie a atualização, que pode levar de 8 a 12 horas ou mais, dependendo do tamanho do seu ambiente. Selecione Atualizar para iniciar a atualização. Quando a atualização for concluída, você passará na validação e poderá usar o recurso de migração para iniciar a migração.

Se a migração for suportada para o seu Ambiente do Serviço de Aplicativo, prossiga para a próxima etapa do processo. A página Migração orienta você pela série de etapas para concluir a migração.

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

Em Obter novos endereços IP, confirme que compreende as implicações e selecione o botão Iniciar . Esta etapa leva cerca de 15 minutos para ser concluída. Não é possível dimensionar ou fazer alterações no Ambiente do Serviço de Aplicativo existente durante esse período.

3. Atualize recursos dependentes com novos IPs

Quando a etapa anterior terminar, os endereços IP do seu novo recurso Ambiente do Serviço de Aplicativo v3 serão exibidos. Use os novos IPs para atualizar quaisquer recursos e componentes de rede para que seu novo ambiente funcione como pretendido após a conclusão da migração. É da sua responsabilidade fazer as atualizações necessárias.

4. Delegue a sub-rede do Ambiente do Serviço de Aplicativo

O Ambiente do Serviço de Aplicativo v3 requer que a sub-rede em que está tenha uma única delegação de Microsoft.Web/hostingEnvironments. As versões anteriores não exigiam essa delegação. Você precisa confirmar se sua sub-rede está delegada corretamente e atualizar a delegação (se necessário) antes de migrar. O portal exibe um link para sua sub-rede para que você possa confirmar e atualizar conforme necessário.

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

Selecione o botão Confirmar para confirmar que você entende que seus planos do Serviço de Aplicativo são convertidos da camada Isolado para a camada Isolado v2 correspondente como parte da migração.

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

Os bloqueios de 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 a sua subscrição ou grupo de recursos tem bloqueios, consulte Configurar bloqueios.

7. Escolha as suas configurações

Você pode tornar redundante sua nova zona de recursos do Ambiente do Serviço de Aplicativo v3 se o ambiente existente estiver em uma região que ofereça suporte à redundância de zona.

Marque a caixa de seleção Habilitado se quiser configurar a redundância de zona.

Se o seu ambiente estiver em uma região que não oferece suporte à redundância de zona, a caixa de seleção não estará disponí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 oferecem suporte à redundância de zona.

Se o Ambiente do Serviço de Aplicativo existente usar um sufixo de domínio personalizado, você deverá configurar um para o novo recurso do Ambiente do Serviço de Aplicativo v3. As opções de configuração para um sufixo de domínio personalizado aparecem se essa situação se aplicar a você. Não é possível migrar até fornecer as informações necessárias.

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

Nota

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

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

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

Depois de concluir todas as etapas anteriores, você pode iniciar a migração. Certifique-se de que compreende as implicações da migração, incluindo o que acontece durante este período.

Esta etapa leva de três a seis horas para migrações de v2 para v3 e até seis horas para migrações de v1 para v3, dependendo do tamanho do ambiente. O dimensionamento e as modificações no Ambiente do Serviço de Aplicativo existente são bloqueados durante esta etapa.

Nota

Em casos raros, você pode ver uma notificação no portal dizendo "Falha na migração para o Ambiente do Serviço de Aplicativo v3" depois de iniciar a migração. Há um bug conhecido que pode acionar essa notificação, mesmo que a migração esteja 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, atualizar a página resolve o problema e a mensagem de erro desaparece. Se a mensagem de erro persistir, contacte o suporte para obter assistência.

No momento, os status de migração detalhados estão disponíveis somente quando você estiver usando a CLI do Azure. Para obter mais informações, consulte a 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 que use o portal para fazer a migração.

Quando a migração estiver concluída, você terá um recurso do Ambiente do Serviço de Aplicativo v3 e todos os seus aplicativos serão executados em seu 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 aparecerá na seção Essentials da página Visão geral do portal do Ambiente do Serviço de Aplicativo v1/v2, mas não aparecerá mais no Ambiente do Serviço de Aplicativo v3. Em vez disso, para o Ambiente do Serviço de Aplicativo v3, vá para a página Sufixo de domínio personalizado para confirmar se o sufixo de domínio personalizado está configurado corretamente. Você também pode remover a configuração se não precisar mais dela ou configurar uma se não tiver uma anteriormente.

Nota

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 quando a migração for concluída devido a um bug conhecido. Seu Ambiente do Serviço de Aplicativo ainda deve funcionar conforme o esperado. O estado degradado deve resolver-se dentro de 6-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á qualquer custo associado à migração do seu Ambiente do Serviço de Aplicações. 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 seu novo Ambiente do Serviço de Aplicativo v3 assim que ele é implantado. Para obter mais informações sobre os preços do Ambiente do Serviço de Aplicações v3, consulte os detalhes dos preços.

Quando você migra para o Ambiente do Serviço de Aplicativo v3 de versões anteriores, há cenários que você deve considerar que podem reduzir seu custo mensal. Considere reservas e planos de poupança para reduzir ainda mais os 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.

Nota

Devido à conversão dos planos do Serviço de Aplicativo de Isolado para Isolado v2, seus aplicativos podem ser provisionados em excesso após a migração, já que a camada Isolado v2 tem mais memória e CPU por tamanho de instância correspondente. Você terá a oportunidade de dimensionar seu ambiente conforme necessário assim que a migração for concluída. Para obter mais informações, consulte os detalhes do SKU.

Reduza seus planos do Serviço de Aplicativo

As SKUs do plano do Serviço de Aplicativo disponíveis para o Ambiente do Serviço de Aplicativo v3 são executadas 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. Quando você migra, seus planos do Serviço de Aplicativo são convertidos para a camada correspondente. Por exemplo, suas instâncias I2 são convertidas em I2v2. Enquanto o I2 tem dois núcleos e 7 GB de RAM, o I2v2 tem quatro núcleos e 16 GB de RAM. Se você espera que seus requisitos de capacidade permaneçam os mesmos, você está provisionado em excesso e pagando pela computação e memória que não está usando. Para esse cenário, você pode reduzir sua instância I2v2 para I1v2 e acabar com um número semelhante de núcleos e RAM que você tinha anteriormente.

Perguntas mais frequentes

• E se a migração do meu Ambiente do Serviço de Aplicativo não for suportada no momento?
  No momento, não é possível migrar usando o recurso de migração in-loco. Se você tiver um ambiente sem suporte e quiser migrar imediatamente, consulte as opções de migração manual.
• Como faço para escolher qual opção de migração é certa para mim?
  Analise a árvore de decisão do caminho de migração para decidir qual opção é melhor para seu caso de uso.
• Como sei se devo usar o recurso de migração in-loco?
  O recurso 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 em suas configurações de rede e podem suportar cerca de uma hora de tempo de inatividade do aplicativo. Se você não puder suportar o tempo de inatividade, consulte o recurso de migração lateral 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 do ambiente existente e usa a mesma infraestrutura de rede. Talvez seja necessário levar em conta as alterações de endereço IP de entrada e saída se tiver alguma dependência desses IPs específicos.
• Irei deparar-me com tempo de inatividade durante a migração?
  Sim, você deve esperar cerca de uma hora de tempo de inatividade durante a janela de serviço de três a seis horas durante a etapa de migração, portanto, planeje de acordo. Se você tiver um Ambiente do Serviço de Aplicativo diferente para o qual possa 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 suportar o tempo de inatividade, consulte o recurso de migração lado a lado ou as opções de migração manual.
• Precisarei fazer alguma coisa com meus aplicativos após a migração para executá-los no novo Ambiente do Serviço de Aplicativo?
  Não, todas as suas aplicações em execução no ambiente antigo são migradas automaticamente para o novo ambiente e executadas como antes. Não é necessária nenhuma entrada de utilizador.
• E se o meu Ambiente do Serviço de Aplicações tiver um sufixo de domínio personalizado?
  O recurso de migração in-loco oferece suporte a esse cenário de migração.
• E se meu Ambiente do Serviço de Aplicativo estiver fixo na zona?
  O Ambiente do Serviço de Aplicativo v2 fixado por 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 oferece suporte à fixação de zona. Ao migrar para o Ambiente do Serviço de Aplicativo v3, você pode optar por configurar a redundância de zona ou não.
• E se meu Ambiente do Serviço de Aplicativo tiver endereços IP SSL? O IP SSL não é suportado no Ambiente do Serviço de Aplicativo v3. Você deve remover todas as ligações 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 todas as ligações IP SSL, você passa nessa verificação de validação e pode prosseguir com a migração automatizada.
• Quais propriedades do meu Ambiente do Serviço de Aplicativo serão alteradas?
  Você está no Ambiente do Serviço de Aplicativo v3, portanto, certifique-se de revisar os recursos e as diferenças de recursos em comparação com as versões anteriores. Para o Ambiente do Serviço de Aplicações do ILB, mantém o mesmo endereço IP do ILB. Para o Ambiente do Serviço de Aplicações com acesso à Internet, o endereço IP público e o endereço IP de saída são alterados. Nota: para o Ambiente do Serviço de Aplicações do ELB, anteriormente existia um único IP para entrada e saída. Para o Ambiente do Serviço de Aplicações v3, estes estão separados. Para obter mais informações, consulte Rede do Ambiente do Serviço de Aplicações V3. Para obter uma comparação completa das versões do Ambiente do Serviço de Aplicações, consulte Comparação das versões do Ambiente do Serviço de Aplicações.
• O que acontece se a migração falhar ou se houver um problema inesperado durante a migração?
  Se houver um problema inesperado, as equipes de suporte estão à disposição. Você deve migrar ambientes de desenvolvimento antes de tocar em qualquer ambiente de produção para aprender sobre o processo de migração e ver como ele afeta suas cargas de trabalho.
• O que acontece ao meu antigo Ambiente do Serviço de Aplicação?
  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 seus aplicativos serão migrados para um novo ambiente. Seu ambiente antigo não está mais acessível. Uma reversão para o ambiente antigo não é possível.
• O que irá acontecer aos meus recursos do Ambiente do Serviço de Aplicações v1/v2 após 31 de agosto de 2024?
  Após 31 de agosto de 2024, se você não acessar 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 Aplicações v1/v2 está alojado em unidades de escala do Serviço de Aplicações em execução na arquitetura de Serviços Cloud (clássica) que serão descontinuadas em 31 de agosto de 2024. Por este motivo, o Ambiente do Serviço de Aplicações v1/v2 deixará de estar disponível após esta data. Migre para o Ambiente do Serviço de Aplicações v3 para manter as suas aplicações em execução ou guarde ou faça uma cópia de segurança de quaisquer recursos ou dados que precise de manter.

Próximos passos

Rede do Ambiente do Serviço de Aplicativo v3

Usando um Ambiente do Serviço de Aplicativo v3

Sufixo de domínio personalizado