Usar 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
Observação
O recurso de migração descrito neste artigo é usado para a migração automatizada in-loco (mesma sub-rede) do Ambiente do Serviço de Aplicativo v1 e v2 para o Ambiente do Serviço de Aplicativo v3. Se você estiver procurando informações sobre o recurso de migração lado a lado, consulte Migrar para o Ambiente do Serviço de Aplicativo v3 usando o recurso de migração lado a lado. Se você estiver procurando informações sobre opções de migração manual, consulte Opções de migração manual. Para obter ajuda para decidir qual opção de migração é ideal para você, confira a Árvore de decisão do caminho de migração. Para obter mais informações sobre o Ambiente do Serviço de Aplicativo v3, consulte Visão geral do Ambiente do Serviço de Aplicativo v3.
Você pode migrar automaticamente o Ambiente do Serviço de Aplicativo v1 e v2 para um 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 Ambiente do Serviço de Aplicativo dá suporte à migração no momento, confira Visão geral do recurso de migração in-loco.
Importante
Para evitar problemas inesperados, recomendamos que você use esse recurso para ambientes de desenvolvimento antes de migrar os ambientes de produção. Forneça comentários relacionados 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 um Ambiente do Serviço de Aplicativo v3 afeta seus aplicativos. Revise o processo de migração para entender a linha do tempo do processo e quando e em que ponto você precisa se envolver. Além disso, revise as perguntas frequentes, que podem responder a algumas das suas dúvidas.
Verifique se não há bloqueios em sua rede virtual, grupo de recursos, recurso ou assinatura. Os blocos bloqueiam as operações da plataforma durante a migração.
Verifique se não há políticas do Azure que bloqueiem as ações necessárias para a migração, incluindo modificações de sub-rede e criações de recursos do Serviço de Aplicativo do Azure. As políticas que bloqueiam modificações e criações de recursos podem fazer com que a migração fique paralisada ou falhe.
Como o dimensionamento é bloqueado durante a migração, você deve dimensionar seu ambiente para o tamanho desejado antes de iniciar a migração. Se você precisar dimensionar seu ambiente após a migração, poderá fazê-lo depois que a migração for concluída.
Recomendamos que você use o portal do Azure para a experiência de migração in-loco. Se você decidir utilizar a CLI do Azure para realizar a migração, siga as etapas descritas aqui na ordem e conforme escritas, pois você está fazendo chamadas à API REST do Azure. Recomendamos que você use a CLI do Azure para fazer essas chamadas à API. Para obter informações sobre outros métodos, confira referência à API REST do Azure.
Para este guia, instale a CLI do Azure ou use o Azure Cloud Shell, e use um shell Bash.
Observação
Recomendamos que você use um shell Bash para executar os comandos indicados neste guia. Os comandos podem não ser compatíveis com convenções do PowerShell e caracteres de escape.
1. Obter sua ID do Ambiente do Serviço de Aplicativo
Execute os comandos a seguir para obter sua ID do Ambiente do Serviço de Aplicativo e armazená-la como uma variável de ambiente. Substitua os espaços reservados para nome e grupos de recursos pelos valores do Ambiente do Serviço de Aplicativo que você deseja migrar. ASE_RG e VNET_RG serão os mesmos se sua rede virtual e o Ambiente do Serviço de Aplicativo estiverem no mesmo grupo de recursos.
ASE_NAME=<Your-App-Service-Environment-name>
ASE_RG=<Your-ASE-Resource-Group>
VNET_RG=<Your-VNet-Resource-Group>
ASE_ID=$(az appservice ase show --name $ASE_NAME --resource-group $ASE_RG --query id --output tsv)
2. Validar que a migração tem suporte
O comando a seguir verifica se o Ambiente do Serviço de Aplicativo é suportado para 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 no 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 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 opções de migração manual. Esse comando também valida que o Ambiente do Serviço de Aplicativo está na versão de compilação com suporte para migração. Se o Ambiente do Serviço de Aplicativo não estiver na versão de compilação com suporte, você precisará iniciar a atualização por conta própria. Para obter mais informações sobre a atualização de pré-imigração, consulte Validar se há suporte para a migração usando o recurso de migração local para o 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 terá suporte e você poderá prosseguir para a próxima etapa.
Se for necessário iniciar um upgrade do Ambiente do Serviço de Aplicativo para a versão de compilação com suporte, execute o comando a seguir. Execute esse comando somente se você falhar na etapa de validação e for instruído a atualizar o Ambiente do Serviço de Aplicativo.
az rest --method post --uri "${ASE_ID}/migrate?api-version=2021-02-01&phase=PreMigrationUpgrade"
3. Gerar endereços IP para o novo recurso de Ambiente do Serviço de Aplicativo v3
Execute o comando a seguir para criar endereços IP. Essa etapa leva cerca de 15 minutos para ser concluída. Não dimensione nem faça alterações no seu Ambiente do Serviço de Aplicativo durante esse tempo.
az rest --method post --uri "${ASE_ID}/migrate?api-version=2021-02-01&phase=premigration"
Execute o seguinte comando para verificar o status desta etapa:
az rest --method get --uri "${ASE_ID}?api-version=2021-02-01" --query properties.status
Se a etapa estiver em andamento, você receberá o status Migrating. Depois de obter o status Ready, execute o comando a seguir para visualizar seus novos IPs. Se você não vir os novos IPs imediatamente, aguarde alguns minutos e tente novamente.
az rest --method get --uri "${ASE_ID}/configurations/networking?api-version=2021-02-01"
Observação
Devido a um bug conhecido, para migrações do Ambiente do Serviço de Aplicativo de ELB, o endereço IP de entrada poderá ser alterado 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. Esse bug está sendo resolvido e será corrigido o mais rápido possível. Abra um caso de suporte caso tenha dúvidas ou preocupações sobre esse problema ou precisar de ajuda com o processo de migração.
4. Atualizar recursos dependentes com novos IPs
Usando os novos IPs, atualize qualquer um dos seus recursos ou componentes de rede para garantir que o novo ambiente funcione conforme esperado quando a migração for concluída. É sua responsabilidade fazer as atualizações necessárias.
Essa etapa também é um bom momento para examinar as alterações de dependência de rede de entrada e saída ao mudar para o Ambiente do Serviço de Aplicativo v3. 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. Delegar a sub-rede do Ambiente do Serviço de Aplicativo
O Ambiente do Serviço de Aplicativo v3 requer que a sub-rede na qual ele está tenha apenas uma delegação de Microsoft.Web/hostingEnvironments. As versões anteriores não exigiam essa delegação. É necessário confirmar se sua sub-rede está delegada corretamente e atualizar a delegação (se necessário) antes de migrar. Você pode atualizar a delegação executando o comando a seguir ou navegando até a sub-rede no portal do Azure.
az network vnet subnet update --resource-group $VNET_RG --name <subnet-name> --vnet-name <vnet-name> --delegations Microsoft.Web/hostingEnvironments
6. Confirme se não há bloqueios na rede virtual
Os bloqueios da rede virtual bloqueiam as operações da plataforma durante a migração. Se sua rede virtual tiver bloqueios, você precisará removê-los antes de migrar. Se necessário, você pode adicionar novamente os bloqueios após a conclusão da migração.
Os bloqueios podem existir em três escopos diferentes: assinatura, grupo de recursos e recurso. Quando você aplica um bloqueio a um escopo pai, todos os recursos filho herdam o mesmo bloqueio. Se você tiver bloqueios aplicados na assinatura, grupo de recursos ou escopo do recurso, eles precisarão ser removidos antes da migração. Para obter mais informações sobre bloqueios e herança de bloqueio, consulte Bloquear recursos para proteger a infraestrutura.
Use o seguinte comando para verificar se sua rede virtual tem algum bloqueio:
az lock list --resource-group $VNET_RG --resource <vnet-name> --resource-type Microsoft.Network/virtualNetworks
Exclua todos os bloqueios existentes usando o seguinte comando:
az lock delete --resource-group $VNET_RG --name <lock-name> --resource <vnet-name> --resource-type Microsoft.Network/virtualNetworks
Para obter os comandos relacionados para verificar se a assinatura ou grupo de recursos tem bloqueios, consulte a referência da CLI do Azure quanto a bloqueios.
7. Preparar suas configurações
Você pode conferir redundância de zona ao seu novo recurso de Ambiente do Serviço de Aplicativo v3 se o ambiente existente estiver em uma região que dê suporte à redundância de zona. A redundância de zona pode ser configurada definindo a propriedade zoneRedundant como true.
A redundância de zona é uma configuração opcional. Você só pode defini-lo durante a criação do novo recurso do Ambiente do Serviço de Aplicativo v3. Não é possível removê-lo posteriormente. Para obter mais informações, confira Escolher as configurações do Ambiente do Serviço de Aplicativo v3. Se você não quiser configurar a redundância de zona, não inclua o parâmetro zoneRedundant.
Se o Ambiente do Serviço de Aplicativo existente utilizar um sufixo de domínio personalizado, será necessário configurar um para o novo recurso de Ambiente do Serviço de Aplicativo v3 durante o processo de migração. A migração falhará se você não configurar um sufixo de domínio personalizado e estiver utilizando um atualmente. A migração também falhará se você tentar adicionar um sufixo de domínio personalizado durante a migração para um ambiente que não tenha um sufixo configurado. Para obter mais informações sobre os sufixos de domínio personalizado do Ambiente do Serviço de Aplicativo v3, incluindo os respectivos requisitos, instruções passo a passo e melhores práticas, confira Sufixo de domínio personalizado para Ambientes do Serviço de Aplicativo.
Observação
Se você estiver configurando um sufixo de domínio personalizado ao adicionar as permissões de rede no Azure Key Vault, verifique se o cofre de chaves permite o acesso dos novos endereços IP de saída do Ambiente do Serviço de Aplicativo gerados na etapa 3.
Se a migração não incluir um sufixo de domínio personalizado e você não quiser habilitar a redundância de zona, você poderá prosseguir para a migração.
Para definir essas configurações, crie um arquivo chamado parameters.json com os detalhes a seguir baseados no seu cenário. Não inclua as propriedades de sufixo de domínio personalizado se não estiver usando esse recurso na sua migração. Lembre-se de preencher com atenção o valor da propriedade zoneRedundant, pois essa configuração é irreversível após a migração. Defina o valor da propriedade kind com base na versão atual do seu Ambiente do Serviço de Aplicativo. Os valores aceitos para a propriedade kind são ASEV1 e ASEV2.
Se você estiver migrando sem um sufixo de domínio personalizado e estiver habilitando a redundância de zona, use este código:
{
"type": "Microsoft.Web/hostingEnvironments",
"name": "sample-ase-migration",
"kind": "ASEV2",
"location": "westcentralus",
"properties": {
"zoneRedundant": true
}
}
Se você estiver usando uma identidade gerenciada atribuída pelo usuário para sua configuração de sufixo de domínio personalizado e estiver habilitando a redundância de zona, use este código:
{
"type": "Microsoft.Web/hostingEnvironments",
"name": "sample-ase-migration",
"kind": "ASEV2",
"location": "westcentralus",
"properties": {
"zoneRedundant": true,
"customDnsSuffixConfiguration": {
"dnsSuffix": "internal.contoso.com",
"certificateUrl": "https://contoso.vault.azure.net/secrets/myCertificate",
"keyVaultReferenceIdentity": "/subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/asev3-migration/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ase-managed-identity"
}
}
}
Se você estiver usando uma identidade gerenciada atribuída pelo sistema para sua configuração de sufixo de domínio personalizado e não estiver habilitando a redundância de zona, use este código:
{
"type": "Microsoft.Web/hostingEnvironments",
"name": "sample-ase-migration",
"kind": "ASEV2",
"location": "westcentralus",
"properties": {
"customDnsSuffixConfiguration": {
"dnsSuffix": "internal.contoso.com",
"certificateUrl": "https://contoso.vault.azure.net/secrets/myCertificate",
"keyVaultReferenceIdentity": "SystemAssigned"
}
}
}
8. Migrar para o Ambiente do Serviço de Aplicativo v3 e verificar o status
Depois de concluir todas as etapas acima, você pode iniciar a migração. Verifique se você entende as implicações da migração.
Essa etapa leva de três a seis horas para migrações da v2 para a v3 e até seis horas para migrações da v1 para a v3, dependendo do tamanho do ambiente. Durante esse tempo, existe cerca de uma hora de tempo de inatividade do aplicativo. A colocação em escala, as implantações e as modificações em seu Ambiente do Serviço de Aplicativo existente são bloqueadas durante essa etapa.
Inclua o parâmetro body no comando a seguir se você estiver habilitando a redundância de zona e/ou estiver configurando um sufixo de domínio personalizado. Se nenhuma dessas configurações se aplicar à sua migração, você poderá remover o parâmetro do comando.
az rest --method post --uri "${ASE_ID}/migrate?api-version=2021-02-01&phase=fullmigration" --body @parameters.json
Execute os comandos a seguir para verificar o status detalhado da migração. Para obter informações sobre os status, consulte as descrições de status da migração.
O primeiro comando obtém a ID da operação para a migração. Copie o valor da propriedade ID.
az rest --method get --uri "${ASE_ID}/operations?api-version=2022-03-01"
Substitua o espaço reservado para a ID da operação no comando a seguir pelo valor copiado. Esse comando retorna o status detalhado da migração. Você pode executar esse comando sempre que necessário para obter o status mais recente.
az rest --method get --uri "${ASE_ID}/operations/<operation-id>/details/default?api-version=2022-09-01"
Depois de obter o status Ready, a migração será feita e você terá um recurso de Ambiente do Serviço de Aplicativo v3. Seus aplicativos agora estão em execução no novo ambiente.
Obtenha os detalhes do novo ambiente executando o comando a seguir ou navegando até o portal do Azure.
az appservice ase show --name $ASE_NAME --resource-group $ASE_RG
Observação
Devido a um bug conhecido, para migrações do Ambiente do Serviço de Aplicativo de ELB, o endereço IP de entrada pode ser alterado quando a etapa de migração for concluída. Verifique os endereços IP do 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 caso tenha dúvidas ou preocupações sobre esse problema ou precisar de ajuda com a confirmação dos novos IPs.
1. Validar que a migração tem suporte
Do portal do Microsoft Azure, navegue até a página Migração do Ambiente do Serviço de Aplicativo que você está migrando. Você pode acessar a página Migração selecionando a faixa na parte superior da página Visão geral do seu Ambiente do Serviço de Aplicativo ou selecionando o item Migração no menu esquerdo.
Na página Migração, a plataforma valida se a migração é compatível com o seu Ambiente do Serviço de Aplicativo. Selecione Validar e confirme que deseja prosseguir com a validação. O processo de validação leva alguns segundos.
Se seu ambiente não for suportado para migração, uma faixa será exibida na parte superior da página e incluirá uma mensagem de erro com um motivo. Para obter descrições das mensagens de erro que podem aparecer se você não estiver qualificado para a migração, confira Solução de problemas.
Se o seu Ambiente de Serviço de Aplicativo não for suportado para migração no momento ou se o seu ambiente estiver em um estado não íntegro ou suspenso, não será possível utilizar o recurso de migração. Se o 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 opções de migração manual.
Caso precise iniciar uma atualização para atualizar o Ambiente do Serviço de Aplicativo para a versão de compilação com suporte, será solicitado que você inicie a atualização. Selecione Atualizar para iniciar a atualização. Ao concluir a atualização, você passará pela validação e poderá usar o recurso de migração para iniciar a migração.
Se houver suporte à migração para o Ambiente do Serviço de Aplicativo, prossiga para a próxima etapa do processo. A página Migração o guiará por uma série de etapas para concluir a migração.
2. Gerar endereços IP para o novo recurso de Ambiente do Serviço de Aplicativo v3
Em Obter novos endereços IP, confirme se você entendeu as implicações e selecione o botão Iniciar. Essa etapa leva cerca de 15 minutos para ser concluída. Não é possível escalar ou fazer alterações em seu Ambiente do Serviço de Aplicativo existente durante esse tempo.
3. Atualizar recursos dependentes com novos IPs
Quando a etapa anterior for concluída, você verá os endereços IP para o novo recurso de Ambiente do Serviço de Aplicativo v3. Use os novos IPs para atualizar todos os recursos e componentes de rede, para que seu novo ambiente funcione conforme o esperado quando a migração for concluída. É sua responsabilidade fazer as atualizações necessárias.
Essa etapa também é um bom momento para examinar as alterações de dependência de rede de entrada e saída ao mudar para o Ambiente do Serviço de Aplicativo v3. 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é que você tenha confirmado que fez essas atualizações.
4. Delegar a sub-rede do Ambiente do Serviço de Aplicativo
O Ambiente do Serviço de Aplicativo v3 requer que a sub-rede na qual ele está tenha apenas uma delegação de Microsoft.Web/hostingEnvironments. As versões anteriores não exigiam essa delegação. É necessário confirmar se sua sub-rede está delegada corretamente e atualizar a delegação (se necessário) antes de migrar. Um link para sua sub-rede é fornecido para que você possa confirmar e atualizar conforme necessário.
5. Reconhecer as alterações no tamanho da instância
Seus planos do Serviço de Aplicativo são convertidos da camada Isolada para a Isolada v2 correspondente. Por exemplo, o I2 é convertido em I2v2. Seus aplicativos podem ficar superprovisionados após a migração, pois a camada Isolated v2 tem mais memória e CPU por tamanho de instância correspondente. Você tem a oportunidade de escalar seu ambiente conforme necessário após a conclusão da migração. Para obter mais informações, revise os detalhes de preços.
6. Confirme se a rede virtual não tem bloqueios
Os bloqueios da rede virtual bloqueiam as operações da plataforma durante a migração. Se sua rede virtual tiver bloqueios, você precisará removê-los antes de migrar. 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 diferentes: assinatura, grupo de recursos e recurso. Quando você aplica um bloqueio a um escopo pai, todos os recursos filho herdam o mesmo bloqueio. Se você tiver bloqueios aplicados na assinatura, grupo de recursos ou escopo do recurso, eles precisarão ser removidos antes da migração. Para obter mais informações sobre bloqueios e herança de bloqueio, consulte Bloquear recursos para proteger a infraestrutura.
Para obter detalhes sobre como verificar se sua assinatura ou grupo de recursos tem bloqueios, consulte Configurar bloqueios.
7. Escolha suas configurações
Você pode conferir redundância de zona ao seu novo recurso de Ambiente do Serviço de Aplicativo v3 se o ambiente existente estiver em uma região que dê suporte à redundância de zona. A redundância de zona é uma configuração opcional. Você só pode defini-lo durante a criação do novo recurso do Ambiente do Serviço de Aplicativo v3. Não é possível removê-lo posteriormente. Para obter mais informações, confira Escolher as configurações do Ambiente do Serviço de Aplicativo v3.
Selecione a caixa de seleção Habilitado se desejar configurar a redundância de zona.
Se o seu ambiente estiver em uma região que não der suporte à redundância de zona, a caixa de seleção ficará indisponível. Se você precisar de um recurso de Ambiente do Serviço de Aplicativo v3 com redundância de zona, use uma das opções de migração manual e crie o recurso em uma das regiões que dão suporte à redundância de zona.
Se o Ambiente do Serviço de Aplicativo existente usar um sufixo de domínio personalizado, será necessário configurar um sufixo desse tipo para o novo recurso de Ambiente do Serviço de Aplicativo v3. As opções de configuração do sufixo de domínio personalizado serão mostradas se essa situação se aplicar a você. Não é possível migrar até que você forneça as informações exigidas.
Se quiser usar um sufixo de domínio personalizado, mas não tiver um configurado no momento, você poderá configurar um sufixo desse tipo após a conclusão da migração. Para obter mais informações sobre os sufixos de domínio personalizado do Ambiente do Serviço de Aplicativo v3, incluindo os respectivos requisitos, instruções passo a passo e melhores práticas, confira Sufixo de domínio personalizado para Ambientes do Serviço de Aplicativo.
Observação
Se você estiver configurando um sufixo de domínio personalizado ao adicionar as permissões de rede no Azure Key Vault, verifique se o cofre de chaves permite o acesso dos novos endereços IP de saída do Ambiente do Serviço de Aplicativo gerados na etapa 2.
Depois de você adicionar os detalhes do seu sufixo de domínio personalizado, o botão Migrar ficará disponível.
8. Migrar para o Ambiente do Serviço de Aplicativo v3
Depois de concluir todas as etapas acima, você pode iniciar a migração. Verifique se você entende as implicações da migração, inclusive o que acontece durante esse tempo.
Essa etapa leva de três a seis horas para migrações da v2 para a v3 e até seis horas para migrações da v1 para a v3, dependendo do tamanho do ambiente. A colocação em escala e as modificações em seu Ambiente do Serviço de Aplicativo existente são bloqueadas durante essa etapa.
Observação
Em casos raros, você poderá ver uma notificação no portal informando "Falha na migração para o Ambiente do Serviço de Aplicativo v3" após iniciar a migração. Há um bug conhecido que pode disparar essa notificação mesmo se a migração estiver progredindo. Verifique o log de atividades do Ambiente do Serviço de Aplicativo para determinar a validade dessa mensagem de erro. Na maioria dos casos, a atualização da página resolve o problema e a mensagem de erro desaparece. Se a mensagem de erro persistir, entre em contato com o suporte para obter assistência.
No momento, os status de migração detalhados só estão disponíveis ao usar a CLI do Azure. Para obter mais informações, consulte as diretrizes da CLI na seção CLI do Azure para migrar para o Ambiente do Serviço de Aplicativo v3. Você pode verificar o status da migração com a CLI, mesmo se usar o portal para fazer a migração.
Quando a migração estiver concluída, você terá um recurso de Ambiente do Serviço de Aplicativo v3 e todos os seus aplicativos estarão em execução no novo ambiente. Você pode confirmar a versão do ambiente verificando a página Configuração do seu Ambiente do Serviço de Aplicativo.
Observação
Devido a um bug conhecido, para migrações do Ambiente do Serviço de Aplicativo de ELB, o endereço IP de entrada pode ser alterado quando a etapa de migração for concluída. Verifique os endereços IP do 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 caso tenha 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 foi mostrado na seção Essentials da página Visão Geral do portal para o Ambiente do Serviço de Aplicativo do Azure v1/v2, mas não é mais mostrado no Ambiente do Serviço de Aplicativo v3. Em vez disso, para o Ambiente do Serviço de Aplicativo v3, acesse a página Sufixo de domínio personalizado para confirmar que o sufixo de domínio personalizado está configurado corretamente. Você também poderá remover a configuração se não precisar mais dela ou configurá-la caso não o tenha feito anteriormente.
Observação
Se a migração incluir um sufixo de domínio personalizado, a configuração do sufixo de domínio personalizado poderá ser mostrada como degradada depois que a migração for concluída devido a um bug conhecido. O Ambiente do Serviço de Aplicativo ainda deve funcionar conforme o esperado. O status degradado deve se resolver dentro de 6 a 8 horas. Se a configuração for degradada após 8 horas ou se o sufixo de domínio personalizado não estiver funcionando, entre em contato com o suporte.
