Migrar aplicativos .NET do modelo em processo para o modelo de trabalho isolado

Este artigo orienta você pelo processo de migração segura do aplicativo de função .NET do modelo em processo para o modelo de trabalho isolado. Para saber mais sobre as diferenças de alto nível entre esses modelos, consulte a comparação do modo de execução.

Este guia pressupõe que seu aplicativo esteja sendo executado na versão 4.x do tempo de execução do Functions. Caso contrário, você deve seguir os guias para atualizar sua versão do host:

• Migrar aplicativos do Azure Functions versão 2.x e 3.x para a versão 4.x
• Migrar aplicações da versão 1.x das Funções do Azure para a versão 4.x

Esses guias de migração de versão de host também ajudam você a migrar para o modelo de trabalho isolado à medida que você trabalha neles.

Identificar aplicativos de função a serem migrados

Use o seguinte script do Azure PowerShell para gerar uma lista de aplicativos de função em sua assinatura que atualmente usam o modelo em processo.

O script usa a assinatura que o Azure PowerShell está configurado para usar no momento. Você pode alterar a assinatura executando primeiro Set-AzContext -Subscription '<YOUR SUBSCRIPTION ID>' e substituindo <YOUR SUBSCRIPTION ID> pelo ID da assinatura que deseja avaliar.

$FunctionApps = Get-AzFunctionApp

$AppInfo = @{}

foreach ($App in $FunctionApps)
{
     if ($App.Runtime -eq 'dotnet')
     {
          $AppInfo.Add($App.Name, $App.Runtime)
     }
}

$AppInfo

Escolha sua versão .NET de destino

Na versão 4.x do tempo de execução do Functions, seu aplicativo de função .NET tem como alvo o .NET 6 ao usar o modelo em processo.

Ao migrar seu aplicativo de função, você tem a oportunidade de escolher a versão de destino do .NET. Você pode atualizar seu projeto C# para uma das seguintes versões do .NET que são suportadas pelo Functions versão 4.x:

1 O modelo de trabalho isolado suporta as versões LTS (Long Term Support) e STS (Standard Term Support) do .NET, bem como do .NET Framework. O modelo em processo suporta apenas versões LTS do .NET, terminando com .NET 8. Para obter uma comparação completa de recursos e funcionalidades entre os dois modelos, consulte Diferenças entre o processo de trabalho em processo e o processo de trabalho isolado .NET Azure Functions.

2 O suporte para o modelo em processo termina em 10 de novembro de 2026. Para obter mais informações, consulte este anúncio de suporte. Para obter suporte total contínuo, você deve migrar seus aplicativos para o modelo de trabalho isolado.

3 Consulte Visualizar versões do .NET no modelo de trabalho isolado para obter detalhes sobre suporte, restrições atuais e instruções para usar a versão de visualização.

Este guia não apresenta exemplos específicos para .NET 9 (Preview) ou .NET 6. Se você precisar direcionar essas versões, poderá adaptar os exemplos do .NET 8.

Prepare para a migração

Se ainda não o fez, identifique a lista de aplicativos que precisam ser migrados em sua Assinatura do Azure atual usando o Azure PowerShell.

Antes de migrar um aplicativo para o modelo de trabalho isolado, você deve revisar cuidadosamente o conteúdo deste guia. Você também deve se familiarizar com as características do modelo de trabalhador isolado e as diferenças entre os dois modelos.

Para migrar o aplicativo, você irá:

1. Migre seu projeto local para o modelo de trabalho isolado seguindo as etapas em Migrar seu projeto local.
2. Depois de migrar seu projeto, teste totalmente o aplicativo localmente usando a versão 4.x das Ferramentas Principais do Azure Functions.
3. Atualize seu aplicativo de função no Azure para o modelo isolado.

Migre seu projeto local

A seção descreve as várias alterações que você precisa fazer em seu projeto local para movê-lo para o modelo de trabalhador isolado. Algumas das etapas mudam com base na sua versão de destino do .NET. Use as guias para selecionar as instruções que correspondem à versão desejada. Essas etapas pressupõem um projeto C# local e, se seu aplicativo estiver usando script C# (.csx arquivos), você deverá converter para o modelo de projeto antes de continuar.

Primeiro, converta o arquivo de projeto e atualize suas dependências. Ao fazê-lo, você verá erros de compilação para o projeto. Nas etapas subsequentes, você fará as alterações correspondentes para remover esses erros.

Ficheiro de projeto

O exemplo a seguir é um arquivo de projeto que usa o .csproj .NET 6 na versão 4.x:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
    <RootNamespace>My.Namespace</RootNamespace>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="4.1.1" />
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
</Project>

Use um dos procedimentos a seguir para atualizar esse arquivo XML para ser executado no modelo de trabalho isolado:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
    <RootNamespace>My.Namespace</RootNamespace>
    <OutputType>Exe</OutputType>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>
  <ItemGroup>
    <FrameworkReference Include="Microsoft.AspNetCore.App" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.21.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.17.2" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore" Version="1.2.1" />
    <PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.22.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.ApplicationInsights" Version="1.2.0" />
    <!-- Other packages may also be in this list -->
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
  <ItemGroup>
    <Using Include="System.Threading.ExecutionContext" Alias="ExecutionContext"/>
  </ItemGroup>
</Project>

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net48</TargetFramework>
    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
    <RootNamespace>My.Namespace</RootNamespace>
    <OutputType>Exe</OutputType>
  </PropertyGroup>
  <ItemGroup>
      <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.21.0" />
      <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.16.4" />
      <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http" Version="3.1.0" />
      <PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.22.0" />
      <PackageReference Include="Microsoft.Azure.Functions.Worker.ApplicationInsights" Version="1.2.0" />
    <!-- Other packages may also be in this list -->
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
  <ItemGroup>
    <Folder Include="Properties\" />
  </ItemGroup>
</Project>

Alterar a estrutura de destino do seu projeto também pode exigir alterações em partes da sua cadeia de ferramentas, fora do código do projeto. Por exemplo, no VS Code, talvez seja necessário atualizar a configuração da azureFunctions.deploySubpath extensão por meio das configurações do usuário ou do .vscode/settings.json arquivo do seu projeto. Verifique se há dependências na versão da estrutura que possam existir fora do código do projeto, como parte das etapas de compilação ou de um pipeline de CI/CD.

Referências de pacotes

Ao migrar para o modelo de trabalho isolado, você precisa alterar os pacotes aos quais seu aplicativo faz referência.

Se ainda não o fez, atualize o seu projeto para fazer referência às versões estáveis mais recentes de:

• Microsoft.Azure.Functions.Worker
• Microsoft.Azure.Functions.Worker.Sdk

Dependendo dos gatilhos e associações que seu aplicativo usa, talvez seja necessário fazer referência a um conjunto diferente de pacotes. A tabela a seguir mostra as substituições para algumas das extensões mais usadas:

Consulte Ligações suportadas para obter uma lista completa de extensões a serem consideradas e consulte a documentação de cada extensão para obter instruções de instalação completas para o modelo de processo isolado. Certifique-se de instalar a versão estável mais recente de todos os pacotes que você está segmentando.

Seu aplicativo de modelo de trabalho isolado não deve fazer referência a nenhum pacote nos Microsoft.Azure.WebJobs.* namespaces ou Microsoft.Azure.Functions.Extensions. Se você tiver quaisquer referências restantes a estes, eles devem ser removidos.

Program.cs arquivo

Ao migrar para execução em um processo de trabalho isolado, você deve adicionar um Program.cs arquivo ao seu projeto com o seguinte conteúdo:

using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var host = new HostBuilder()
    .ConfigureFunctionsWebApplication()
    .ConfigureServices(services => {
        services.AddApplicationInsightsTelemetryWorkerService();
        services.ConfigureFunctionsApplicationInsights();
    })
    .Build();

host.Run();

using Microsoft.Extensions.Hosting;
using Microsoft.Azure.Functions.Worker;

namespace Company.FunctionApp
{
    internal class Program
    {
        static void Main(string[] args)
        {
            FunctionsDebugger.Enable();

            var host = new HostBuilder()
                .ConfigureFunctionsWorkerDefaults()
                .ConfigureServices(services => {
                    services.AddApplicationInsightsTelemetryWorkerService();
                    services.ConfigureFunctionsApplicationInsights();
                })
                .Build();
            host.Run();
        }
    }
}

O Program.cs arquivo substituirá qualquer arquivo que tenha o FunctionsStartup atributo, que normalmente é um Startup.cs arquivo. Em locais onde seu FunctionsStartup código faria referência IFunctionsHostBuilder.Services, você pode, em vez disso, adicionar instruções dentro do .ConfigureServices() método do HostBuilder em seu Program.cs. Para saber mais sobre como trabalhar com Program.cso , consulte Inicialização e configuração no guia de modelo de trabalhador isolado.

Os exemplos padrão Program.cs acima incluem a configuração da integração do Application Insights para o modelo de trabalho isolado. No , Program.csvocê também deve configurar qualquer filtragem de log que deve ser aplicada a logs provenientes do código em seu projeto. No modelo de trabalho isolado, o arquivo controla host.json apenas os eventos emitidos pelo tempo de execução do host Functions. Se você não configurar regras de filtragem no Program.cs, poderá ver diferenças nos níveis de log presentes para várias categorias em sua telemetria.

Embora você possa registrar fontes de configuração personalizadas como parte do HostBuilder, observe que elas também se aplicam apenas ao código em seu projeto. A configuração de acionamento e vinculação também é necessária para a plataforma, e isso deve ser fornecido por meio das configurações do aplicativo, referências do Cofre da Chave ou recursos de referências de Configuração do Aplicativo.

Depois de mover tudo de qualquer existente FunctionsStartup para o Program.cs arquivo, você pode excluir o FunctionsStartup atributo e a classe à qual ele foi aplicado.

Alterações na assinatura da função

Alguns tipos de chave mudam entre o modelo em processo e o modelo de trabalhador isolado. Muitos deles estão relacionados aos atributos, parâmetros e tipos de retorno que compõem a assinatura da função. Para cada uma das suas funções, você deve fazer alterações em:

• O atributo function (que também define o nome da função)
• Como a função obtém um ILogger/ILogger<T>
• Atributos e parâmetros de acionamento e vinculação

O restante desta seção orienta você por cada uma dessas etapas.

Atributos de função

O Function atributo no modelo de trabalho isolado substitui o FunctionName atributo. O novo atributo tem a mesma assinatura, e a única diferença está no nome. Portanto, você pode apenas executar uma substituição de cadeia de caracteres em todo o projeto.

Registo

No modelo em processo, você pode incluir um parâmetro opcional ILogger para sua função ou pode usar a injeção de dependência para obter um ILogger<T>arquivo . Se seu aplicativo já usou a injeção de dependência, os mesmos mecanismos funcionam no modelo de trabalhador isolado.

No entanto, para quaisquer funções que dependiam do ILogger parâmetro de método, você precisa fazer uma alteração. Recomenda-se que utilize a injeção de dependência para obter um ILogger<T>ficheiro . Use as seguintes etapas para migrar o mecanismo de log da função:

1. Na sua classe de função, adicione uma private readonly ILogger<MyFunction> _logger; propriedade, substituindo MyFunction pelo nome da sua classe de função.

2. Crie um construtor para sua classe de função que recebe o ILogger<T> parâmetro as:

   public MyFunction(ILogger<MyFunction> logger) {
       _logger = logger;
   }
   

   Substitua ambas as instâncias do trecho de MyFunction código anterior pelo nome da sua classe de função.

3. Para registrar operações em seu código de função, substitua as ILogger referências ao parâmetro por _logger.

4. Remova o ILogger parâmetro da assinatura da função.

Para saber mais, consulte Registro em log no modelo de trabalhador isolado.

Alterações de gatilho e vinculação

Quando você alterou as referências do pacote em uma etapa anterior, introduziu erros para seus gatilhos e ligações que agora serão corrigidos:

1. Remova todas as using Microsoft.Azure.WebJobs; instruções.

2. Adicione uma using Microsoft.Azure.Functions.Worker; instrução.

3. Para cada atributo de vinculação, altere o nome do atributo conforme especificado em sua documentação de referência, que você pode encontrar no índice de ligações suportadas. Em geral, os nomes dos atributos mudam da seguinte maneira:

   • Os gatilhos normalmente permanecem nomeados da mesma maneira. Por exemplo, QueueTrigger é o nome do atributo para ambos os modelos.
   • As ligações de entrada normalmente precisam de "Entrada" adicionada ao seu nome. Por exemplo, se você usasse o CosmosDB atributo de vinculação de entrada no modelo em processo, o atributo agora seria CosmosDBInput.
   • As ligações de saída normalmente precisam de "Saída" adicionada ao seu nome. Por exemplo, se você usasse o Queue atributo de vinculação de saída no modelo em processo, esse atributo agora seria QueueOutput.

4. Atualize os parâmetros de atributo para refletir a versão do modelo de trabalho isolado, conforme especificado na documentação de referência da associação.

   Por exemplo, no modelo em processo, uma ligação de saída de blob é representada por um [Blob(...)] atributo que inclui uma Access propriedade. No modelo de trabalhador isolado, o atributo de saída de blob seria [BlobOutput(...)]. A associação não requer mais a propriedade, para que o Access parâmetro possa ser removido. Assim [Blob("sample-images-sm/{fileName}", FileAccess.Write, Connection = "MyStorageConnection")] se tornaria [BlobOutput("sample-images-sm/{fileName}", Connection = "MyStorageConnection")].

5. Mova as ligações de saída para fora da lista de parâmetros da função. Se você tiver apenas uma ligação de saída, poderá aplicá-la ao tipo de retorno da função. Se você tiver várias saídas, crie uma nova classe com propriedades para cada saída e aplique os atributos a essas propriedades. Para saber mais, consulte Várias ligações de saída.

6. Consulte a documentação de referência de cada ligação para saber os tipos aos quais ela permite vincular. Em alguns casos, pode ser necessário alterar o tipo. Para ligações de saída, se a versão do modelo em processo usou um IAsyncCollector<T>, você pode substituí-lo por ligação a uma matriz do tipo de destino: T[]. Você também pode considerar substituir a ligação de saída por um objeto cliente para o serviço que ela representa, seja como o tipo de associação para uma ligação de entrada, se disponível, ou injetando um cliente você mesmo.

7. Se a sua função incluir um IBinder parâmetro, remova-o. Substitua a funcionalidade por um objeto cliente para o serviço que ele representa, seja como o tipo de ligação para uma associação de entrada, se disponível, ou injetando um cliente por conta própria.

8. Atualize o código da função para trabalhar com quaisquer novos tipos.

local.settings.json arquivo

O arquivo local.settings.json só é usado quando executado localmente. Para obter informações, consulte Arquivo de configurações locais.

Ao migrar da execução em processo para a execução em um processo de trabalho isolado, você precisa alterar o FUNCTIONS_WORKER_RUNTIME valor para "dotnet-isolated". Certifique-se de que o ficheiro local.settings.json tem pelo menos os seguintes elementos:

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "UseDevelopmentStorage=true",
        "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated"
    }
}

O valor que você tem para 'AzureWebJobsStorage'' pode ser diferente. Não é necessário alterar seu valor como parte da migração.

host.json arquivo

Não são necessárias alterações ao seu host.json ficheiro. No entanto, se a configuração do Application Insights neste arquivo for do seu projeto de modelo em processo, convém fazer alterações adicionais no arquivo Program.cs . O host.json arquivo controla apenas o log do tempo de execução do host do Functions e, no modelo de trabalho isolado, alguns desses logs vêm diretamente do seu aplicativo, oferecendo mais controle. Consulte Gerenciando níveis de log no modelo de trabalho isolado para obter detalhes sobre como filtrar esses logs.

Outras alterações de código

Esta seção destaca outras alterações de código a serem consideradas ao trabalhar na migração. Essas alterações não são necessárias para todos os aplicativos, mas você deve avaliar se alguma é relevante para seus cenários.

Serialização JSON

Por padrão, o modelo de trabalho isolado usa System.Text.Json para serialização JSON. Para personalizar as opções do serializador ou alternar para JSON.NET (Newtonsoft.Json), consulte estas instruções.

Níveis de log e filtragem do Application Insights

Os logs podem ser enviados para o Application Insights a partir do tempo de execução do host do Functions e do código em seu projeto. O host.json permite que você configure regras para registro em log do host, mas para controlar logs provenientes do seu código, você precisará configurar regras de filtragem como parte do seu Program.cs. Consulte Gerenciando níveis de log no modelo de trabalho isolado para obter detalhes sobre como filtrar esses logs.

Exemplo de migrações de função

Exemplo de gatilho HTTP

Um gatilho HTTP para o modelo em processo pode se parecer com o exemplo a seguir:

using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.Extensions.Logging;

namespace Company.Function
{
    public static class HttpTriggerCSharp
    {
        [FunctionName("HttpTriggerCSharp")]
        public static IActionResult Run(
            [HttpTrigger(AuthorizationLevel.Function, "get", Route = null)] HttpRequest req,
            ILogger log)
        {
            log.LogInformation("C# HTTP trigger function processed a request.");

            return new OkObjectResult($"Welcome to Azure Functions, {req.Query["name"]}!");
        }
    }
}

Um gatilho HTTP para a versão migrada pode se parecer com o exemplo a seguir:

using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Logging;

namespace Company.Function
{
    public class HttpTriggerCSharp
    {
        private readonly ILogger<HttpTriggerCSharp> _logger;

        public HttpTriggerCSharp(ILogger<HttpTriggerCSharp> logger)
        {
            _logger = logger;
        }

        [Function("HttpTriggerCSharp")]
        public IActionResult Run(
            [HttpTrigger(AuthorizationLevel.Function, "get")] HttpRequest req)
        {
            _logger.LogInformation("C# HTTP trigger function processed a request.");

            return new OkObjectResult($"Welcome to Azure Functions, {req.Query["name"]}!");
        }
    }
}

using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Http;
using Microsoft.Extensions.Logging;
using System.Net;

namespace Company.Function
{
    public class HttpTriggerCSharp
    {
        private readonly ILogger<HttpTriggerCSharp> _logger;

        public HttpTriggerCSharp(ILogger<HttpTriggerCSharp> logger)
        {
            _logger = logger;
        }

        [Function("HttpTriggerCSharp")]
        public HttpResponseData Run([HttpTrigger(AuthorizationLevel.Function, "get")] HttpRequestData req)
        {
            _logger.LogInformation("C# HTTP trigger function processed a request.");

            var response = req.CreateResponse(HttpStatusCode.OK);
            response.Headers.Add("Content-Type", "text/plain; charset=utf-8");

            response.WriteString($"Welcome to Azure Functions, {req.Query["name"]}!");

            return response;
        }
    }
}

Atualizar seu aplicativo de função no Azure

Atualizar seu aplicativo de função para o modelo isolado envolve duas alterações que devem ser concluídas juntas, porque se você concluir apenas uma, o aplicativo estará em um estado de erro. Ambas as alterações também fazem com que o processo do aplicativo seja reiniciado. Por esses motivos, você deve executar a atualização usando um slot de preparo. Os slots de preparo ajudam a minimizar o tempo de inatividade do seu aplicativo e permitem que você teste e verifique seu código migrado com sua configuração atualizada no Azure. Em seguida, você pode implantar seu aplicativo totalmente migrado para o slot de produção por meio de uma operação de troca.

Use as seguintes etapas para usar slots de implantação para atualizar seu aplicativo de função para o modelo de trabalho isolado:

1. Crie um slot de implantação, se ainda não o fez. Você também pode querer se familiarizar com o processo de troca de slot e garantir que você possa fazer atualizações para o aplicativo existente com o mínimo de interrupção.

2. Altere a configuração do slot de preparo (não produção) para usar o modelo de trabalho isolado definindo a configuração do FUNCTIONS_WORKER_RUNTIME aplicativo como dotnet-isolated. FUNCTIONS_WORKER_RUNTIMEnão deve ser marcado como uma "definição de ranhura".

   Se você também estiver direcionando uma versão diferente do .NET como parte de sua atualização, você também deve alterar a configuração da pilha. Para fazer isso, consulte as instruções para atualizar a configuração da pilha para o modelo de trabalho isolado. Você usará as mesmas instruções para quaisquer futuras atualizações de versão do .NET que fizer.

   Se você tiver algum provisionamento de infraestrutura automatizado, como um pipeline de CI/CD, certifique-se de que as automações também sejam atualizadas para dotnet-isolated manter FUNCTIONS_WORKER_RUNTIME definido e direcionar a versão correta do .NET.

3. Publique seu projeto migrado no slot de preparo (não produção) do seu aplicativo de função.

   Se você usar o Visual Studio para publicar um projeto de modelo de trabalho isolado em um aplicativo ou slot existente que usa o modelo em processo, ele também poderá concluir a etapa anterior para você ao mesmo tempo. Se você não concluiu a etapa anterior, o Visual Studio solicitará que você atualize o aplicativo de função durante a implantação. Visual Studio apresenta isso como uma única operação, mas essas ainda são duas operações separadas. Você ainda pode ver erros em seus logs do slot de preparo (não produção) durante o estado provisório.

4. Confirme se seu aplicativo está funcionando conforme o esperado dentro do slot de preparo (não produção).

5. Execute uma operação de troca de slot. Isso aplica as alterações feitas no slot de preparo (não produção) ao slot de produção. Uma troca de slot acontece como uma única atualização, o que evita a introdução do estado de erro provisório em seu ambiente de produção.

6. Confirme se seu aplicativo está funcionando conforme o esperado dentro do slot de produção.

Depois de concluir essas etapas, a migração será concluída e seu aplicativo será executado no modelo isolado. Parabéns! Repita as etapas deste guia conforme necessário para quaisquer outros aplicativos que precisem de migração.

Próximos passos