Use o recurso de migração in-loco para migrar o Ambiente do Serviço de Aplicativo v1 e v2 para o Ambiente do Serviço de Aplicativo v3
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ê 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.
Você pode migrar automaticamente o Ambiente do Serviço de Aplicativo v1 e v2 para o Ambiente do Serviço de Aplicativo v3 usando o recurso de migração in-loco. Para saber mais sobre o processo de migração e ver se o seu Ambiente do Serviço de Aplicativo oferece suporte à migração no momento, consulte a visão geral do recurso de migração in-loco.
Importante
Recomendamos que você use esse recurso para ambientes de desenvolvimento antes de migrar qualquer ambiente de produção, para evitar problemas inesperados. Por favor, forneça qualquer comentário relacionado a este artigo ou ao recurso usando os botões na parte inferior da página.
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.
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 é compatível com a migração. Se você receber um erro ou se o Ambiente do Serviço de Aplicativo estiver em um estado não íntegro ou suspenso, não será possível migrar neste momento. Consulte a seção de solução de problemas para obter descrições das possíveis mensagens de erro que você pode receber. Se o seu ambiente não tiver suporte para migração usando o recurso de migração in-loco ou se você quiser migrar para o Ambiente do Serviço de Aplicativo v3 sem usar o recurso de migração in-loco, consulte as opções de migração manual. Este comando também valida se o Ambiente do Serviço de Aplicativo está na versão de compilação com suporte para migração. Se o seu Ambiente do Serviço de Aplicativo não estiver na versão de compilação suportada, você mesmo precisará iniciar a atualização. Para obter mais informações sobre a atualização pré-migração, consulte Validar se há suporte para a migração usando o recurso de migração in-loco para seu Ambiente do Serviço de Aplicativo.
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"
Nota
Devido a um bug conhecido, para migrações do Ambiente do Serviço de Aplicativo ELB, o endereço IP de entrada pode mudar novamente quando a etapa de migração for concluída. Esteja preparado para atualizar seus recursos dependentes novamente com o novo endereço IP de entrada após a conclusão da etapa de migração. Este bug está sendo resolvido e será corrigido o mais rápido possível. Abra um caso de suporte se tiver dúvidas ou preocupações sobre esse problema ou precisar de ajuda com o processo de migração.
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.
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. Essas alterações incluem a alteração de porta para o Azure Load Balancer, que agora usa a porta 80. Não migre até concluir esta etapa.
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.
Os bloqueios podem existir em três escopos: 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, grupo de recursos ou escopo de recurso, precisará removê-los antes da migração. Para obter mais informações sobre bloqueios e herança de bloqueio, consulte Bloquear seus recursos para proteger sua infraestrutura.
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.
A redundância de zona é uma configuração opcional. Você pode defini-lo somente durante a criação do seu novo recurso do Ambiente do Serviço de Aplicativo v3. Não é possível removê-lo posteriormente. Para obter mais informações, consulte Escolher suas configurações do Ambiente do Serviço de Aplicativo v3. Se não quiser configurar a redundância de zona, não inclua o zoneRedundant parâmetro.
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 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/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. 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
Nota
Devido a um bug conhecido, para migrações do Ambiente do Serviço de Aplicativo ELB, o endereço IP de entrada pode mudar quando a etapa de migração for concluída. Verifique os endereços IP do seu Ambiente do Serviço de Aplicativo v3 e faça as atualizações necessárias se houver alterações desde a etapa de geração de IP. Abra um caso de suporte se tiver dúvidas ou preocupações sobre esse problema ou precisar de ajuda com a confirmação dos novos IPs.
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.
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 o seu Ambiente do Serviço de Aplicativo não tiver suporte para migração no momento ou se o ambiente estiver em um estado não íntegro ou suspenso, você não poderá usar o recurso de migração. Se o seu ambiente não tiver suporte para migração com o recurso de migração in-loco ou se você quiser migrar para o Ambiente do Serviço de Aplicativo v3 sem usar o recurso de migração in-loco, consulte as opções de migração manual.
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. 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.
Esta etapa também é um bom momento para revisar as alterações de dependência de rede de entrada e saída na mudança para o Ambiente do Serviço de Aplicativo v3. Essas alterações incluem a alteração de porta para o Azure Load Balancer, que agora usa a porta 80. Não passe para a próxima etapa até confirmar que fez essas atualizações.
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
Seus planos do Serviço de Aplicativo são convertidos de Isolado para a camada Isolado v2 correspondente. Por exemplo, I2 é convertido para I2v2. Seus aplicativos podem ser provisionados em excesso após a migração, porque 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 após a conclusão da migração. Para obter mais informações, consulte os detalhes de preços.
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. Se necessário, você pode adicionar novamente os bloqueios após a conclusão da migração.
Os bloqueios podem existir em três escopos: 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, grupo de recursos ou escopo de recurso, precisará removê-los antes da migração. Para obter mais informações sobre bloqueios e herança de bloqueio, consulte Bloquear seus recursos para proteger sua infraestrutura.
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. A redundância de zona é uma configuração opcional. Você pode defini-lo somente durante a criação do seu novo recurso do Ambiente do Serviço de Aplicativo v3. Não é possível removê-lo posteriormente. Para obter mais informações, consulte Escolher suas configurações do Ambiente do Serviço de Aplicativo v3.
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.
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.
Nota
Devido a um bug conhecido, para migrações do Ambiente do Serviço de Aplicativo ELB, o endereço IP de entrada pode mudar quando a etapa de migração for concluída. Verifique os endereços IP do seu Ambiente do Serviço de Aplicativo v3 e faça as atualizações necessárias se houver alterações desde a etapa de geração de IP. Abra um caso de suporte se tiver dúvidas ou preocupações sobre esse problema ou precisar de ajuda com a confirmação dos novos IPs.
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.
