Evitar e resolver problemas causados por uma migração automática de um Ambiente do Serviço de Aplicativo

Importante

O Ambiente do Serviço de Aplicativo v1 e v2 estão desativados e não têm mais suporte. Se você tiver um Ambiente do Serviço de Aplicativo v1 ou v2, precisará migrar para o Ambiente do Serviço de Aplicativo v3. Para obter mais informações, confira Atualizar para o Ambiente do Serviço de Aplicativo v3.

As migrações automáticas são migrações iniciadas pela Microsoft. De 1º de setembro de 2024 em diante, a plataforma tentará migrar automaticamente qualquer Ambiente do Serviço de Aplicativo v1 e v2 restantes com base no melhor esforço usando o recurso de migração in-loco. No enanto, a Microsoft não afirma ou garante a disponibilidade do aplicativo após a migração automática. Talvez seja necessário realizar a configuração manual para concluir a migração e otimizar a escolha de SKU do Plano do Serviço de Aplicativo para atender às suas necessidades. Se a migração automática não for viável, seus recursos e dados de aplicativo associados serão excluídos. Recomendamos fortemente que você tome uma atitude agora para evitar esses cenários extremos.

Se você tiver um Ambiente do Serviço de Aplicativo v1 ou v2 que foi migrado automaticamente para o Ambiente do Serviço de Aplicativo v3, poderá encontrar problemas com seus aplicativos ou serviços. Este artigo fornece diretrizes sobre como resolver esses problemas.

Visão geral

Após 1º de setembro de 2024, todos os Ambientes do Serviço de Aplicativo v1 e v2 estão qualificados para serem migrados automaticamente para o Ambiente do Serviço de Aplicativo v3 a qualquer momento, a menos que indicado de outra forma. A plataforma inicia migrações automáticas, que são necessárias para garantir que o Ambiente do Serviço de Aplicativo esteja em execução em uma plataforma com suporte.

Observação

As migrações e exclusões automáticas são feitas em lotes. Se o Ambiente do Serviço de Aplicativo ainda não estiver migrado automaticamente, ele está sujeito à migração automática ou exclusão a qualquer momento. A única maneira de garantir que o Ambiente do Serviço de Aplicativo não seja migrado ou excluído inesperadamente é solicitar um período de cortesia de 30 dias.

As migrações automáticas são feitas usando o recurso de migração in-loco. Há cerca de uma hora de tempo de inatividade durante o processo de migração. Os endereços IP de entrada e saída do Ambiente do Serviço de Aplicativo podem ser alterados durante o processo de migração. O tempo de inatividade poderá ser maior se você tiver dependências desses endereços IP. O tempo de inatividade também poderá ser maior se você usar recursos não compatíveis com o Ambiente do Serviço de Aplicativo v3.

Período de Cortesia

Se você precisar de mais tempo para concluir suas migrações, podemos oferecer um período de cortesia único de 30 dias. O Ambiente do Serviço de Aplicativo não é migrado automaticamente ou excluído durante o período de cortesia. Quando o período de cortesia terminar, tentamos migrar automaticamente o Ambiente do Serviço de Aplicativo. Se a migração automática não for viável, seus recursos e dados de aplicativo associados serão excluídos.

Para receber esse período de cortesia, acesse o portal do Azure e visite a página Migração para seu Ambiente do Serviço de Aplicativo. Se você tiver mais de um Ambiente do Serviço de Aplicativo, será necessário reconhecer e receber um período de cortesia para cada um de seus ambientes que requer mais tempo para migrar.

Depois que você receber o período de cortesia, a data de término dele será mostrada na faixa na parte superior da página Migração. Talvez você precise atualizar a página para ver a faixa atualizada. Pode levar até cinco minutos para que a faixa seja atualizada com a data.

Se você precisar de mais suporte ou tiver dúvidas, entre em contato com o Suporte do Azure usando a opção Abrir tíquete de suporte no portal do Azure na página Migração. É importante que você reconheça e receba um período de cortesia para cada um de seus ambientes que exijam mais tempo para migrar antes de abrir a solicitação de suporte. O período de cortesia e reconhecimento garante que seus ambientes não sejam migrados automaticamente enquanto a solicitação de suporte está sendo processada.

Limitações da migração automática

As migrações automáticas são feitas usando o recurso de migração in-loco. As seguintes limitações se aplicam às migrações automáticas, semelhantes às limitações das migrações in-loco:

• O novo Ambiente do Serviço de Aplicativo v3 fica na sub-rede existente que foi usada para o ambiente antigo.
• O novo Ambiente do Serviço de Aplicativo v3 está na mesma região do seu ambiente antigo.
• O novo Ambiente do Serviço de Aplicativo v3 está no mesmo grupo de recursos do seu ambiente antigo.
• Todos os recursos mantêm os mesmos nomes e IDs de recurso.
• Não há suporte para associações TLS/SSL baseadas em IP no Ambiente do Serviço de Aplicativo v3. Se você tiver associações TLS/SSL baseadas em IP, será necessário removê-las depois que a migração for concluída. Seus aplicativos não funcionarão até que você remova as associações.
• Não há suporte para o Ambiente do Serviço de Aplicativo v1 em uma rede virtual Clássica para migração. Se você tiver um Ambiente do Serviço de Aplicativo v1 em uma rede virtual clássica, precisará migrar manualmente. O Ambiente do Serviço de Aplicativo estará qualificado para exclusão a qualquer momento se você não solicitar um período de cortesia de 30 dias.
• O recurso de migração in-loco não está disponível no Leste da China 2 e no Norte da China 2. Não há suporte para o recurso lá porque o Ambiente do Serviço de Aplicativo v3 não está disponível nessas regiões. Portanto, a migração automática não é possível para ambientes do Serviço de Aplicativo nessas regiões. Se você tiver um Ambiente do Serviço de Aplicativo nessas regiões, precisará migrar manualmente para uma das regiões com suporte, como o Leste da China 3 ou o Norte da China 3. O Ambiente do Serviço de Aplicativo estará qualificado para exclusão a qualquer momento se você não solicitar um período de cortesia de 30 dias.

Para obter mais informações sobre migrações in-loco e ver qual processo é seguido durante uma migração automática, consulte a Migração para o Ambiente do Serviço de Aplicativo v3 usando o recurso de migração in-loco.

Inelegível para migração automática

Há dois cenários em que você pode estar inelegível para migração automática. O primeiro cenário é se o ambiente atual está em uma região que não dá suporte ao Ambiente do Serviço de Aplicativo v3. O outro cenário é se você tiver um Ambiente do Serviço de Aplicativo v1 em uma rede virtual Clássica. Se você estiver inelegível para migração automática e nunca puder migrar automaticamente, o portal exibirá uma mensagem com o motivo pelo qual você está inelegível. Você precisa migrar manualmente. O Ambiente do Serviço de Aplicativo estará qualificado para exclusão a qualquer momento se você não solicitar um período de cortesia de 30 dias.

Em alguns casos, você pode ser temporariamente bloqueado da migração automática, mas pode resolver o problema de bloqueio e habilitar a migração automática. Por exemplo, se você tiver um bloqueio de recurso no Ambiente do Serviço de Aplicativo, poderá remover o bloqueio de recurso para habilitar a migração automática. Uma migração automática bloqueada por um bloqueio de recurso, pelo Azure Policy ou pela configuração de rede é suspensa automaticamente. Se você precisar cancelar a suspensão do Ambiente do Serviço de Aplicativo, abra um tíquete de suporte.

Os seguintes erros poderão ser exibidos no portal se você estiver inelegível para migração automática:

Erro	Recomendação
O Ambiente do Serviço de Aplicativo v1 está em uma Rede virtual clássica. As redes virtuais clássicas não dão suporte ao Ambiente do Serviço de Aplicativo v3.	Você precisa migrar manualmente.
Há um bloqueio de recurso no Ambiente do Serviço de Aplicativo/rede virtual/grupo de recursos/assinatura que está impedindo a migração.	Para habilitar a migração automática, remova o bloqueio de recurso.
Há um Azure Policy que está impedindo a migração.	Para habilitar a migração automática, remova qualquer Azure Policy que bloqueie modificações ou exclusões de recursos para o Ambiente do Serviço de Aplicativo ou a rede virtual em que o ambiente está.
O Ambiente do Serviço de Aplicativo está em uma região que não dá suporte à migração automática.	Você precisa migrar manualmente.

O que fazer se o Ambiente do Serviço de Aplicativo for suspenso

Se o Ambiente do Serviço de Aplicativo for suspenso, você terá duas opções.

Cancelar a suspensão e migrar por conta própria

Se você quiser migrar por conta própria, abra um tíquete de suporte usando a opção na página Migração para ver se podemos cancelar a suspensão do seu Ambiente do Serviço de Aplicativo. Não garantimos que seja possível cancelar a suspensão do seu ambiente.

Retomar/cancelar a suspensão como Ambiente do Serviço de Aplicativo v3

Se você quiser agilizar a migração, poderá retomar o seu ambiente ou cancelar a suspensão dele como um Ambiente do Serviço de Aplicativo v3. Para retomar o Ambiente do Serviço de Aplicativo como v3, acesse o portal do Azure e visite a página migração para o Ambiente do Serviço de Aplicativo. Para retomar seu ambiente como um Ambiente do Serviço de Aplicativo v3, selecione o botão "Migrar agora". Esse botão inicia o mesmo processo usado para migrações automáticas. As limitações, o tempo de inatividade e outras considerações são as mesmas para migrações automáticas. Se você tiver mais de um Ambiente do Serviço de Aplicativo, precisará retomar cada um dos ambientes suspensos.

Recursos para limitar os efeitos das migrações automáticas

Para limitar o efeito das migrações automáticas, implementamos os recursos a seguir para o recurso de migração automática.

Preservação de endereço IP de saída

Anteriormente, o endereço IP de saída do Ambiente do Serviço de Aplicativo sempre foi alterado durante o processo de migração. Agora, o endereço IP de saída do Ambiente do Serviço de Aplicativo pode ser preservado durante o processo de migração. O endereço IP público do Ambiente do Serviço de Aplicativo v1/v2 pode ser preservado e usado como o endereço IP de saída do Ambiente do Serviço de Aplicativo v3. Não garantimos que podemos preservar seu endereço IP de saída. No entanto, o Ambiente do Serviço de Aplicativo v3 tem dois endereços IP de saída. Se você tiver uma configuração de sufixo de domínio personalizado e se conectar ao Azure Key Vault pela Internet pública, talvez ainda precise considerar o outro novo endereço IP de saída.

Para migrações internas do Ambiente do Serviço de Aplicativo do ILB (Balanceador de Carga Interno), o IP de entrada é sempre preservado. Essa funcionalidade permanece a mesma durante a migração automática.

Para migrações do Ambiente do Serviço de Aplicativo do ELB (balanceador de carga externo), o IP de entrada ainda é alterado. Essa alteração poderá afetar você se você usar registros A para apontar para o endereço IP de entrada do Ambiente do Serviço de Aplicativo. Se você usar registros A, deverá atualizar os registros A para apontar para o novo endereço IP de entrada após a conclusão do processo de migração. Se você usar registros CNAME, provavelmente não precisará fazer nenhuma alteração de DNS. Se você tiver outras dependências no endereço IP de entrada, precisará atualizá-las adequadamente.

Compatibilidade de configuração de sufixo de domínio personalizado do Ambiente do Serviço de Aplicativo v2

O sufixo de domínio personalizado no Ambiente do Serviço de Aplicativo v3 é implementado de maneira diferente do que no Ambiente do Serviço de Aplicativo v2. No Ambiente do Serviço de Aplicativo v2, o certificado é carregado diretamente no Ambiente do Serviço de Aplicativo. Além disso, certificados não curinga são permitidos. No Ambiente do Serviço de Aplicativo v3, o certificado precisa ser armazenado no Azure Key Vault e o Ambiente do Serviço de Aplicativo precisa ser capaz de acessar o cofre de chaves. Além disso, certificados não curinga não são permitidos.

Para reduzir o efeito das migrações automáticas, implementamos um modo de compatibilidade limitado para configurações de sufixo de domínio personalizado do Ambiente do Serviço de Aplicativo v2 no Ambiente do Serviço de Aplicativo v3. Se você tiver uma configuração de sufixo de domínio personalizado no Ambiente do Serviço de Aplicativo v2, a configuração será migrada para o Ambiente do Serviço de Aplicativo v3. O certificado é carregado no Ambiente do Serviço de Aplicativo v3 e a configuração é atualizada para usar o certificado carregado. Esse processo é feito como uma medida temporária e só é válido até que o certificado atual expire. Você precisa atualizar a configuração para usar o Azure Key Vault após a conclusão do processo de migração e antes que o certificado expire. Se você não atualizar a configuração, depois que o certificado expirar, o sufixo de domínio personalizado não funcionará. Para obter mais informações, confira Sufixo de domínio personalizado no Ambiente do Serviço de Aplicativo v3.

Importante

Mesmo com o modo de compatibilidade do sufixo de domínio personalizado, a configuração do sufixo de domínio personalizado pode não funcionar conforme o esperado. Não garantimos que o sufixo de domínio personalizado funcionará após a migração automática. É altamente recomendável que você atualize a configuração para usar o Azure Key Vault assim que possível após a conclusão do processo de migração.

Suporte à migração para aplicativos com associações TLS/SSL baseadas em IP

Não há suporte para associações TLS/SSL baseadas em IP no Ambiente do Serviço de Aplicativo v3. Anteriormente, o recurso de migração só permitia que você migrasse depois de remover as associações. Para habilitar migrações automáticas, a validação automática para verificar se há associações TLS/SSL baseadas em IP é removida. Se você tiver associações TLS/SSL baseadas em IP, será necessário removê-las depois que a migração for concluída. Seus aplicativos não funcionarão até que você remova as associações.

Resolver problemas causados por uma migração automática

Veja a seguir os problemas que você pode encontrar com seus aplicativos ou serviços após uma migração automática. Se o problema não estiver listado aqui e você precisar de assistência, entre em contato com o Suporte do Azure.

Problema: o Ambiente do Serviço de Aplicativo v3 está usando a configuração antiga do sufixo de domínio personalizado

Se você tiver uma configuração de sufixo de domínio personalizado no Ambiente do Serviço de Aplicativo v2, a configuração será migrada para o Ambiente do Serviço de Aplicativo v3. O certificado é carregado no Ambiente do Serviço de Aplicativo v3 e a configuração é atualizada para usar o certificado carregado. Esse processo é feito como uma medida temporária e só é válido até que o certificado atual expire. Não garantimos que a configuração antiga do sufixo de domínio personalizado funcionará após a migração automática.

Para resolver essa incompatibilidade, você precisa atualizar a configuração para usar o Azure Key Vault após a conclusão do processo de migração e antes que o certificado expire. Se você não atualizar a configuração, depois que o certificado expirar, o sufixo de domínio personalizado não funcionará. Para atualizar a configuração de sufixo de domínio personalizado, siga as etapas em Sufixo de domínio personalizado no Ambiente do Serviço de Aplicativo v3.

Problema: aplicativos no Ambiente do Serviço de Aplicativo v3 têm associações TLS/SSL baseadas em IP

Não há suporte para associações TLS/SSL baseadas em IP no Ambiente do Serviço de Aplicativo v3. Você precisará remover as associações depois que a migração for concluída. Seus aplicativos não funcionarão até que você remova as associações.

Problema: os recursos dependentes não são atualizados para usar o novo endereço IP de entrada

As migrações do Ambiente do Serviço de Aplicativo do ILB preservam o endereço IP de entrada, portanto, nenhuma ação é necessária.

As migrações do Ambiente do Serviço de Aplicativo do ELB alteram o endereço IP de entrada. Se você usar registros A para apontar para o endereço IP de entrada do Ambiente do Serviço de Aplicativo, precisará atualizar os registros A para apontar para o novo endereço IP de entrada após a conclusão do processo de migração. Se você usar registros CNAME, provavelmente não precisará fazer nenhuma alteração de DNS. Se você tiver outras dependências no endereço IP de entrada, precisará atualizá-las adequadamente. O endereço IP de entrada antigo não é mais válido após a conclusão do processo de migração.

Problema: os recursos dependentes não são atualizados para usar o novo endereço IP de saída

O Ambiente do Serviço de Aplicativo v3 tem dois endereços IP de saída. Após o processo de migração, o endereço IP de saída existente pode ser preservado, mas outro IP de saída é criado. Talvez seja necessário considerar esse outro novo endereço IP de saída se você tiver uma configuração de sufixo de domínio personalizado e se conectar ao Azure Key Vault pela Internet pública. Se o endereço IP de saída original não for preservado, você também precisará considerar essa alteração.

Problema: Alteração ou incompatibilidade de recursos com o Ambiente do Serviço de Aplicativo v3

Em geral, o Ambiente do Serviço de Aplicativo v3 é compatível com o Ambiente do Serviço de Aplicativo v1 e v2. No entanto, há algumas diferenças. Para ver as diferenças entre as versões, examine a comparação de versões do Ambiente do Serviço de Aplicativo. Se estiver usando um recurso que não tenha suporte ou se comporte de maneira diferente no Ambiente do Serviço de Aplicativo v3, você precisará atualizar seus aplicativos de acordo.

As seguintes alterações são notáveis no Ambiente do Serviço de Aplicativo v3:

• Não há suporte para associações TLS/SSL baseadas em IP.
• A configuração de sufixo de domínio personalizado está diferente.
• O domínio padrão será sempre mantido, mesmo se você tiver um sufixo de domínio personalizado.
• Certificados não curinga para sufixo de domínio personalizado não são permitidos.
• O Ambiente do Serviço de Aplicativo v3 tem dois endereços IP de saída.
• Os SKUs disponíveis são de tamanhos diferentes.
• O modelo de preços é diferente.
• O modelo de rede é diferente.
• A estrutura do ponto de extremidade FTPS é diferente. Não há suporte para o acesso ao ponto de extremidade FTPS usando o sufixo de domínio personalizado.
• 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.

Preços

Não há nenhum custo associado à migração automática do Ambiente do Serviço de Aplicativo. 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.

Política de suporte após a desativação do Ambiente do Serviço de Aplicativo v1 e v2

A instrução a seguir representa a política de suporte do Ambiente do Serviço de Aplicativo do Azure v1 e v2 a partir de 1º de setembro de 2024. Isso não afeta suas cargas de trabalho em execução no Ambiente do Serviço de Aplicativo v3.

Essa política de suporte expira no final de qualquer extensão ou período de cortesia pelo qual você recebeu aprovação por escrito da Microsoft para executar os serviços após a data de desativação agendada. A falha na migração até essa data resultará na desativação de todos os Ambientes de Serviço de Aplicativo do Azure v1 e v2 restantes, que podem incluir, mas não se limitar à exclusão dos aplicativos e dados, migração in-loco automatizada e outros procedimentos de desativação.

A política de suporte estendido inclui os seguintes itens:

• A partir de 1º de setembro de 2024, o SLA (Contrato de Nível de Serviço) não é mais aplicável ao Ambiente do Serviço de Aplicativo v1 e v2. Por meio do uso contínuo do produto além da data de desativação, você reconhece que o Azure não se compromete com o SLA de 99,95% para o ambiente desativado.
• Estamos comprometidos em manter a plataforma e permitir que você conclua suas migrações. Portanto, os canais de suporte dos CSS (Serviços de Apoio ao Cliente) e PG (Grupo de Produtos) continuarão a lidar com casos de suporte e CRIs (Incidentes de Resposta Crítica) de maneira comercialmente razoável. Nenhum novo investimento em segurança e conformidade será feito no Ambiente do Serviço de Aplicativo v1 e v2.
• O Serviço de Aplicativo continuará a corrigir o sistema operacional e os runtimes de linguagem de programação de acordo com os processos de atualização da plataforma documentados aqui.
• O Serviço de Aplicativo continuará a testar e validar as atualizações do Serviço de Aplicativo do Azure antes da implantação e continuará a seguir procedimentos de implantação seguros para atualizações de plataforma.
• O Serviço de Aplicativo continuará monitorando ativamente o volume de produção do Ambiente do Serviço de Aplicativo do Azure v1/v2 e continuará respondendo a problemas detectados por meio desse monitoramento com a mesma urgência que atualmente.
• A Microsoft continuará aceitando casos de suporte do Serviço de Aplicativo do Azure e a resolução de problemas do Serviço de Aplicativo do Azure em tempo hábil.
• O Serviço de Aplicativo continuará aplicando patches e hotfixes para bugs críticos da plataforma do Serviço de Aplicativo do Azure que possam surgir.
• No entanto, a capacidade de atenuar efetivamente problemas que podem surgir de dependências do Azure de nível inferior pode ser prejudicada devido à desativação que afeta todos os serviços de nuvem e os componentes do ASM (Gerenciamento de Serviços do Azure)/RDFE (Front-End RedDog).

Recomendamos que você conclua a migração para o Ambiente do Serviço de Aplicativo do Azure v3 o mais rápido possível para evitar interrupções em seus serviços. Nossa equipe está disponível para ajudar você com o processo de migração e responder a todas as perguntas que você possa ter. Para obter mais informações sobre as etapas de desativação e migração, recursos disponíveis e benefícios da migração, consulte a documentação do produto.

Perguntas frequentes

• Por que estou enfrentando interrupções temporárias de aplicativo no meu Ambiente do Serviço de Aplicativo v1/v2?
  A plataforma do Azure está se preparando para a desativação dos Serviços de Nuvem (Clássico), que é a infraestrutura em que o Ambiente do Serviço de Aplicativo v1 e v2 são executados. Como parte dessa preparação, você deve esperar interrupções temporárias e interrupções de serviço. Para minimizar o efeito dessas interrupções, recomendamos que você migre para o Ambiente do Serviço de Aplicativo v3 o mais rápido possível.
• Por que meu Ambiente do Serviço de Aplicativo foi migrado automaticamente?
  O Ambiente do Serviço de Aplicativo v1 e v2 estão desativados e não têm mais suporte. A infraestrutura de suporte para o Ambiente do Serviço de Aplicativo v1 e v2 está sendo desativada. Para garantir que o Ambiente do Serviço de Aplicativo esteja em execução em uma plataforma com suporte, a Microsoft inicia migrações automáticas para o Ambiente do Serviço de Aplicativo v3.
• Por que meus aplicativos não estão funcionando após a migração automática?
  Após uma migração automática, você pode encontrar problemas com seus aplicativos ou serviços devido a atualizações de recursos ou incompatibilidades. Para resolver esses problemas, confira Solucionar problemas causados por uma migração automática.
• Qual é o tempo de inatividade durante o processo de migração automática?
  Há cerca de uma hora de tempo de inatividade durante o processo de migração automática. Os endereços IP de entrada e saída do Ambiente do Serviço de Aplicativo podem ser alterados durante o processo de migração. O tempo de inatividade poderá ser maior se você tiver dependências desses endereços IP. O tempo de inatividade também poderá ser maior se você usar recursos não compatíveis com o Ambiente do Serviço de Aplicativo v3.
• Serei cobrado por migrações automáticas?
  Não há nenhum custo associado à migração automática do Ambiente do Serviço de Aplicativo. 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.
• Por que meu Ambiente do Serviço de Aplicativo foi excluído?
  Se a migração automática não for viável, seus recursos e dados de aplicativo associados serão excluídos. Pedimos fortemente que você aja agora para evitar este cenário. Se você precisar de mais tempo para concluir suas migrações, podemos oferecer um período de cortesia único de 30 dias. O Ambiente do Serviço de Aplicativo não é excluído durante o período de cortesia. Quando o período de cortesia terminar, poderemos excluir o Ambiente do Serviço de Aplicativo e todos os dados associados.