As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Tarefa 4: Definindo o processo de aprofundamento do aplicativo
Agora que você terminou de estabelecer regras e processos para priorização de aplicativos, realize uma análise aprofundada do aplicativo que o ajudará a refinar a prioridade de cada aplicativo. Você realiza o aprofundamento do aplicativo em um aplicativo por vez, da maior para a menor prioridade. Para projetos com várias equipes de portfólio, cada equipe pode realizar uma análise aprofundada do aplicativo em um aplicativo diferente ao mesmo tempo.
Durante o aprofundamento, você pode encontrar alguns problemas inesperados, como dependências, que afetam a complexidade da migração do aplicativo. Quando isso acontece, você deve modificar os critérios de pontuação de complexidade definidos na etapa anterior e atualizar a planilha de pontuação adequadamente para obter pontuações de complexidade mais precisas para futuros aplicativos. Em seguida, você pode atualizar as prioridades do aplicativo usando as novas pontuações de complexidade.
Essa tarefa consiste nas seguintes etapas:
+ [Etapa 1: definir o processo do workshop de aplicativos](#deep-dive-1)
+ [Etapa 2: Definir o processo de mapeamento de aplicativos](#deep-dive-2)
+ [Etapa 3: (opcional) definir o estado de destino do aplicativo](#deep-dive-3)
+ [Etapa 4: finalizar o processo de aprofundamento do aplicativo](#deep-dive-4)
## Etapa 1: definir o processo do workshop de aplicativos
O processo de workshop é uma das abordagens mais eficientes para um aprofundamento da aplicação. Usando esse processo, você colabora com as partes interessadas, os proprietários do aplicativo e a equipe do portfólio para avaliar e analisar o aplicativo. O objetivo é entender claramente o estado atual do aplicativo, incluindo sua arquitetura, finalidade comercial, dependências e ambiente. Em seguida, você usa essas informações detalhadas sobre o tamanho e a complexidade do aplicativo para projetar o estado de destino do aplicativo.
Cada workshop normalmente dura de 1 a 8 horas, embora você possa descobrir que é necessário mais tempo para aplicativos de alta complexidade. Você também pode dividir o workshop em várias reuniões, dependendo da disponibilidade de recursos, de sua preferência e do tamanho e complexidade do aplicativo.
### Identifique os resultados esperados
Antes de conduzir um workshop de aplicação, você deve definir uma agenda e definir os resultados esperados do workshop ou as informações que você precisa coletar no workshop. Isso permite que os participantes do workshop se preparem para o workshop, ajuda a manter a reunião dentro do prazo e garante que, ao final do workshop, você tenha todas as informações necessárias para priorizar, planejar e migrar o aplicativo.
Recomendamos que você defina um conjunto padrão de resultados esperados e os documente em seu runbook de priorização de aplicativos. Ao preparar um workshop, você usa os resultados padrão esperados e adiciona novos para a aplicação específica.
Defina o conjunto padrão de resultados esperados para workshops de aplicação da seguinte forma:
1. Abra seu runbook de priorização de aplicativos.
1. Na seção de *resultados esperados do workshop de aplicação*, estabeleça um conjunto padrão de resultados esperados para os workshops de aplicação. Ao preparar um workshop, você pode personalizá-los de acordo com as necessidades específicas do aplicativo.
1. Salve o runbook de priorização de aplicativos.
1. Mantenha os resultados esperados no runbook de priorização de aplicativos. Ao conduzir workshops de aplicação e continuar com a avaliação do portfólio e o planejamento de ondas, você pode identificar novos resultados esperados ou refinar os resultados existentes.
A seguir estão exemplos dos resultados esperados para o workshop de aplicação.
****
| Prioridade | Resultado esperado do workshop de aplicação |
| --- | --- |
| 1 | Compreensão clara da arquitetura atual do aplicativo, incluindo servidores associados, dependências, ambiente e nível do aplicativo. |
| 2 | A equipe coletou os metadados para apoiar o design da arquitetura de destino. Os seguintes metadados são obrigatórios:[See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| 3 | O questionário do proprietário do aplicativo está completo e todas as principais perguntas foram respondidas. |
| 4 | A equipe coletou toda a documentação do aplicativo, como o guia do usuário, a documentação da arquitetura do aplicativo, a documentação de testes, a documentação do design e a documentação da interface de programação de aplicativos (API). |
### Defina as regras do workshop de aplicativos
Antes de conduzir um workshop de aplicação, você deve definir as regras que governarão seu workshop. As regras comuns incluem a duração do workshop, as ferramentas que podem ser necessárias no workshop e quaisquer considerações de agendamento ou prazos que precisem ser considerados. Isso ajuda a manter a reunião dentro do prazo e garante que as decisões tomadas no workshop estejam alinhadas com o cronograma de migração.
Recomendamos que você documente as regras do workshop de aplicativos em seu runbook de priorização de aplicativos.
Defina as regras do workshop de aplicativos da seguinte forma:
1. Abra seu runbook de priorização de aplicativos.
1. Na seção *Regras do workshop de aplicativos*, defina as regras que regem seus workshops.
1. Salve o runbook de priorização de aplicativos.
1. Mantenha as regras no runbook de priorização de aplicativos. Ao conduzir workshops de aplicação e continuar com a avaliação do portfólio e o planejamento de ondas, você pode identificar novas regras ou refinar as existentes.
Veja a seguir exemplos de regras para o workshop de aplicação.
****
| Prioridade | Regra do workshop |
| --- | --- |
| 1 | Os workshops devem ser agendados para um máximo de 2 horas por sessão às terças e quintas-feiras. |
| 2 | Há um congelamento programado da infraestrutura de 1º de dezembro a 15 de janeiro. |
| 3 | Há um workshop prático sobre ferramentas de migração. |
| 4 | O contrato do data center expirará em 31 de março. As cargas de trabalho devem ser evacuadas até 31 de março para evitar penalidades e dispendiosas extensões de contrato. |
| 5 | A aplicação biométrica e a solicitação de horário e presença serão mantidas. |
### Defina o processo do workshop de aplicativos
É importante que você defina um processo padrão para conduzir workshops de aplicação. Isso garante uma experiência consistente e define expectativas para os participantes do workshop, o que pode melhorar a eficiência do workshop.
O processo do workshop de inscrição tem três etapas:
+ **Prepare-se para o workshop** — A preparação para o workshop ajuda a garantir que a sessão ocorra sem problemas e que os participantes saibam o que é esperado. Para se preparar para o workshop, você estabelece uma agenda e define os resultados esperados, identifica os participantes, as ferramentas e as informações necessárias no workshop e agenda o workshop. Agendar o workshop com pelo menos uma semana de antecedência dá à equipe tempo para bloquear seu calendário, se preparar para o workshop e coletar qualquer informação útil.
+ **Conduza o workshop** — Ao conduzir o workshop, você limita a discussão aos itens da agenda e garante que atenda aos resultados esperados. Anote os tópicos que você considera úteis, mas que não estão incluídos na sua agenda. Pode ser útil gravar o workshop.
+ **Finalize os resultados do workshop** — Depois do workshop, sua equipe deve ter uma compreensão clara do estado atual do aplicativo e dos possíveis pontos problemáticos, riscos, desafios e obstáculos que podem afetar a priorização e a migração. As tarefas comuns após o workshop incluem: repriorizar o aplicativo, elaborar o estado futuro do aplicativo e atualizar o runbook com quaisquer resultados esperados, regras ou mudanças no processo que possam ser úteis no próximo workshop.
O *modelo do Runbook para priorização de aplicativos* inclui um step-by-step processo padrão para preparar, conduzir e finalizar um workshop de aplicativos. Defina seu processo de workshop de inscrição da seguinte forma:
1. Abra seu runbook de priorização de aplicativos.
1. Na seção *Processo do workshop de aplicativos*, modifique o processo padrão para atender às necessidades do seu caso de uso.
1. Salve o runbook de priorização de aplicativos.
1. Mantenha o processo no runbook de priorização de aplicativos. Ao conduzir workshops de aplicação, você pode identificar as alterações que deseja fazer nesse processo.
### Critérios de saída da etapa
+ Você definiu a agenda do workshop e os recursos e artefatos necessários para apoiar o workshop.
+ Você definiu o resultado esperado do workshop e identificou as informações que precisa coletar no workshop.
+ Você conduziu um teste do processo do workshop e tem as informações necessárias para apoiar o mapeamento de aplicativos e projetar o estado de destino.
+ Você documentou o seguinte em seu runbook de priorização de aplicativos:
+ Resultados esperados do workshop de aplicação
+ Regras do workshop de aplicação
+ Processo de workshop de inscrição
## Etapa 2: Definir o processo de mapeamento de aplicativos
O *mapeamento de aplicativos* é o processo de atribuir cada aplicativo a um padrão de migração, que você identificou e validou. [Etapa 4: validar os padrões de migração](discovery.md#discovery-4) Nesta etapa, você define as regras que serão usadas para avaliar o aplicativo. Em seguida, você define o processo que usará para avaliar cada aplicativo. O mapeamento de cada aplicativo para o caso de uso do padrão de migração ajuda a identificar a ferramenta de migração, todas as habilidades necessárias para concluir a migração e a complexidade do padrão de migração.
Nem sempre você migra um aplicativo para um único padrão. Para obter mais informações sobre quando você pode precisar de vários padrões para o mesmo aplicativo, consulte [Defina o processo de mapeamento de aplicativos](#deep-dive-2-process) mais adiante nesta seção.
### Regras de mapeamento de aplicativos
As regras de mapeamento do aplicativo ajudam você a avaliar o aplicativo e identificar o padrão de migração apropriado. Cada regra consiste em qualquer informação que você deve usar para avaliar a aplicação e combinar os critérios do padrão.
Nos [modelos de manual do portfólio](samples/portfolio-playbook-templates.zip), o *modelo Runbook para priorização de aplicativos* inclui uma seção para documentar suas regras de mapeamento de aplicativos. Defina seu processo da seguinte forma:
1. Abra seu runbook de priorização de aplicativos.
1. Na seção *Regras de mapeamento de aplicativos*, defina suas regras de mapeamento de aplicativos.
1. Salve o runbook de priorização de aplicativos.
1. Mantenha as regras no runbook de priorização de aplicativos.
A tabela a seguir fornece exemplos de regras de mapeamento de aplicativos.
**nota**
O padrão IDs e os nomes nesta tabela correspondem aos padrões de amostra em[Etapa 4: validar os padrões de migração](discovery.md#discovery-4). Use o padrão IDs e os nomes que você definiu no seu runbook de priorização de aplicativos.
****
| Prioridade | Regra de mapeamento |
| --- | --- |
| 1 | Usando dados de utilização ou ferramentas de monitoramento, identifique se o aplicativo é um aplicativo zumbi ou ocioso. Se o aplicativo for um aplicativo zumbi ou ocioso, escolha o *Padrão 8: Retire o aplicativo* e, em seguida, desligue os servidores na pilha de aplicativos. |
| 2 | Identifique se a migração desse aplicativo para a nuvem fornece valor comercial. Aplicativos que são usados somente localmente e não são compartilhados entre filiais ou localizações geográficas, como aplicativos de horário e presença, normalmente não precisam ser migrados para a nuvem. Se a migração desse aplicativo não fornecer valor comercial, escolha o *Padrão 9: Reter no local*. |
| 3 | Identifique se o sistema operacional (SO) do aplicativo é suportado por serviços de AWS migração AWS, um fornecedor ou sua ferramenta de migração de rehospedagem e, em seguida, faça o seguinte:[See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| 4 | Identifique se o aplicativo tem uma versão de software como serviço (SaaS) ou equivalente e, em seguida, avalie os benefícios e os custos da mudança para essa nova plataforma. Se esses critérios forem atendidos, escolha o *Padrão 10: Recompra e atualização para SaaS*. |
| 5 | Identifique se os bancos de dados locais do aplicativo podem ser migrados para um serviço homogêneo na nuvem, como migrar um banco de dados Oracle local para o Amazon RDS for Oracle ou migrar um banco de dados MySQL local para o banco de dados Amazon Aurora MySQL Compatible Edition. Se esses critérios forem atendidos, use o *Padrão 2: Replataforma para o Amazon RDS usando e. AWS DMS AWS SCT* |
| 6 | Identifique se o aplicativo usa Microsoft.NET Core (.NET 5 ou .NET 6), Java, PHP ou outra linguagem de programação de código aberto e se o aplicativo está hospedado no Microsoft Windows Server. Avalie se o custo da replataforma é justificável. Se esses critérios forem atendidos, escolha *Padrão 7: Replataforma do Windows para o Linux no Amazon* EC2. |
| 7 | Identifique o armazenamento local local e compartilhado de arquivos do qual seu aplicativo depende e, em seguida, determine se ele deve ser incluído na migração. Se o armazenamento de arquivos local e compartilhado precisar ser migrado, escolha o *Padrão 4: Replataforma para o Amazon EFS usando AWS DataSync * ou. AWS Transfer Family |
| 8 | Identifique se os servidores do aplicativo são de mainframe ou midrange, como IBM AS/400 ou Apache Spark, e confirme se os aplicativos são compatíveis com emuladores. Se esses critérios forem atendidos, use o *Padrão 6: Replataforma de servidores mainframe ou midrange para o Amazon EC2* usando um emulador. |
| 9 | Identifique se esse é um aplicativo legado, monolítico ou baseado em mainframe que não pode mais atender à demanda dos negócios devido às suas limitações. Por exemplo, identifique se o aplicativo pode ser escalado, integrado a aplicativos relacionados ou se é caro e difícil de manter. Se o aplicativo atender a qualquer um desses critérios, escolha *Padrão 11: rearquitetar o aplicativo*. |
### Defina o processo de mapeamento de aplicativos
Ao mapear aplicativos de acordo com os padrões de migração, é útil solicitar dados de descoberta para o aplicativo à equipe de descoberta. Esses dados geralmente incluem informações como um padrão de migração recomendado (às vezes chamado de *padrão R* ou *pontuação R*), informações de utilização, dependências de aplicativos e outras informações que você pode usar na avaliação. Ao explorar esse aplicativo em detalhes, você pode decidir alterar o padrão de migração que foi identificado anteriormente.
Quando você tiver os dados, poderá comparar o aplicativo com os critérios comerciais e técnicos identificados em[Etapa 2: Identificar os impulsionadores comerciais e técnicos](discovery.md#discovery-2). Você registrou seus drivers em seu caderno de priorização de aplicativos. Avaliar o aplicativo em relação aos critérios pode levar você a selecionar vários padrões de migração para o aplicativo ou pode levar você a eliminar padrões com base no custo, no cronograma ou em outras limitações.
Veja a seguir um exemplo de um impulsionador de negócios que exige que você use vários padrões de migração em um único aplicativo. Você quer migrar um banco de dados SQL Server local para o Amazon DynamoDB, mas como o contrato do data center está expirando, a empresa gostaria de migrá-lo antes do cronograma proposto para reformulá-lo. Para abordar esse fator de negócios, você revisa o plano de migração do aplicativo para uma abordagem de dois padrões. Primeiro, você rehospeda o aplicativo na nuvem para removê-lo do data center. Posteriormente, depois que o aplicativo estiver na nuvem, você poderá reformatá-lo de acordo com o cronograma proposto.
Você também deve considerar se o aplicativo é um aplicativo de n camadas, que é um aplicativo composto por vários níveis. Uma *camada de aplicativo* é um grupo de servidores físicos que hospedam camadas horizontais do seu aplicativo. Os aplicativos de n camadas são mais complexos porque cada nível pode exigir uma estratégia diferente, e você pode optar por migrar os níveis do aplicativo em ondas diferentes. Por exemplo, se você tiver um aplicativo composto por camadas de apresentação, serviço comercial e banco de dados, existe a possibilidade de mapear um padrão diferente para cada camada.
Em seguida, você avalia o aplicativo em relação às regras de mapeamento de aplicativos, que você definiu no seu runbook de priorização de aplicativos. Para acessar mais informações, consulte [Regras de mapeamento de aplicativos](#deep-dive-2-rules) anteriormente nesta seção.
Depois de mapear seu aplicativo para um ou mais padrões, revise e verifique essa decisão com o proprietário do aplicativo. O proprietário do aplicativo deve confirmar o padrão selecionado e ajudá-lo a planejar e realizar a migração. No momento, os proprietários de aplicativos também podem fornecer informações com base em sua experiência ou compartilhar quaisquer problemas que prevejam com a migração.
Depois de mapear o aplicativo para um ou mais padrões de migração e confirmar os padrões com o proprietário do aplicativo, você registra o aplicativo, a ID do padrão, o nome do padrão e os drivers relevantes em uma tabela de mapeamento de aplicativos no seu runbook de priorização de aplicativos.
Nos [modelos de manual do portfólio](samples/portfolio-playbook-templates.zip), o *modelo Runbook para priorização de aplicativos inclui um step-by-step processo padrão para mapeamento* de aplicativos. Defina seu processo da seguinte forma:
1. Abra seu runbook de priorização de aplicativos.
1. Na seção *Processo do workshop de aplicativos*, modifique o processo padrão para atender às necessidades do seu caso de uso.
1. Salve o runbook de priorização de aplicativos.
1. Mantenha o processo no runbook de priorização de aplicativos.
A tabela a seguir é um exemplo de tabela de mapeamento de aplicativos. O *modelo de Runbook fornecido para priorização de aplicativos* inclui uma tabela vazia na qual você pode registrar seus resultados do processo de mapeamento de aplicativos.
**nota**
O padrão IDs e os nomes nesta tabela correspondem aos padrões de amostra em[Etapa 4: validar os padrões de migração](discovery.md#discovery-4). Use o padrão IDs e os nomes que você definiu no seu runbook de priorização de aplicativos.
****
| Nome da aplicação | ID do padrão | Nome do padrão | Impulsionadores comerciais e técnicos abordados |
| --- | --- | --- | --- |
| Site corporativo | 1 | Hospede novamente no Amazon EC2 usando o Application Migration Service ou o Cloud Migration Factory | [See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| Sistema de RH | 8 | Retire o aplicativo | [See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| Solicitação de horário e presença | 9 | Mantenha-se no local | [See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| Sistema PO | 3 | Reorganize a plataforma para o Amazon EC2 usando CloudFormation | [See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| Sistema CRM | 10 | Recompra e atualização para SaaS | [See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| Sistema de ativos fixos | 7 | Replataforma do Windows para o Linux no Amazon EC2 | [See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| Armazenamento de arquivos ERP | 4 | Replataforma para o Amazon EFS usando AWS DataSync ou AWS Transfer Family | [See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| Sistema de contabilidade | 6 | Hospede novamente servidores de mainframe ou midrange no Amazon EC2 usando um emulador | [See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| Livro contábil geral | 11 | Rearquitetar o aplicativo | [See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
### Critérios de saída da etapa
+ Você documentou o seguinte em seu runbook de priorização de aplicativos:
+ Regras de mapeamento de aplicativos
+ Processo de mapeamento de aplicativos
+ Você validou as regras e os processos de mapeamento usando um ou mais aplicativos proof-of-concept (POC).
## Etapa 3: (opcional) definir o estado de destino do aplicativo
Nesta etapa, você define os atributos e o processo que você usa para documentar o estado de destino, ou *futuro estado*, do aplicativo. O estado de destino é como o aplicativo opera no ambiente de nuvem de destino após a migração. O ambiente de destino varia de acordo com sua plataforma ou serviço de destino e requisitos de negócios. O ambiente de destino pode ser o Nuvem AWS ou AWS Managed Services (AMS).
A definição do estado alvo ajuda gerentes de projeto, consultores de migração, arquitetos, proprietários de aplicativos e partes interessadas a colaborarem de forma eficaz. Ao usar esse processo, a equipe pode identificar e resolver problemas com antecedência e implementar com mais eficiência o ambiente de estado alvo.
Para alguns aplicativos, essa etapa é opcional. Você pode pular essa etapa se o aplicativo que você está migrando for independente ou de baixa complexidade. Estratégias de migração que não modificam o aplicativo, como rehospedar, podem não exigir essa etapa. No entanto, para estratégias de migração mais complexas, como replataforma e rearquitetura, você deve definir o estado de destino antes de iniciar a migração.
O workshop fornece uma compreensão profunda do estado atual do aplicativo, portanto, é uma boa ideia redigir o estado-alvo após concluir o workshop. Além disso, mapear o aplicativo de acordo com seu padrão de migração fornece informações adicionais e ajuda a identificar se é necessário definir o estado de destino. Por exemplo, se você mapear o aplicativo para o padrão *Rehost no Amazon EC2 usando o Application Migration Service ou o Cloud Migration* Factory, você identificou que a estratégia é rehospedada e provavelmente não precisa definir o estado de destino desse aplicativo.
### Atributos do estado de destino
Ao definir o estado de destino e tomar decisões sobre o aplicativo, recomendamos que você considere os seguintes atributos do estado de destino:
+ **AWS Well-Architected Tool**— Analise o estado alvo do aplicativo em relação ao AWS Well-Architected Framework para ajudar a melhorar a segurança, o desempenho e a resiliência do aplicativo na nuvem.
+ **Zona de pouso alvo** — Normalmente, ao final da [fase de mobilização](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-migration/mobilize-phase.html), você deve ter construído uma zona de pouso completa que esteja pronta para executar aplicativos piloto. A landing zone já deve estar configurada com uma arquitetura de várias contas, gerenciamento de identidade e acesso, governança, segurança de dados, design de rede e registro. Você usa um aplicativo piloto para verificar se o landing zone está completo. Verifique se você pode iniciar e executar seu aplicativo piloto na zona de pouso de destino existente. Se você precisar modificar a zona de pouso para o aplicativo, informe a equipe da zona de pouso sobre seus requisitos. Por exemplo, seu aplicativo pode exigir acesso a um serviço hospedado em uma conta separada, ou seu aplicativo pode exigir roteamento especial para uma nuvem privada virtual (VPC).
+ **Dependências** — identifique todos os aplicativos dos quais seu aplicativo depende para funcionar adequadamente. Por exemplo, seu aplicativo pode depender de bancos de dados, armazenamento ou serviços de terceiros, como um gateway de pagamento ou serviço web externo, ou seu aplicativo pode depender de outros aplicativos em seu ambiente. Para acessar essas dependências, talvez você precise de roteamento ou configuração especial, como conectar-se a um serviço de diretório para autenticação.
+ **Aplicativos dependentes** — identifique todos os aplicativos que dependem do seu aplicativo para funcionar adequadamente. Talvez seja necessário reconfigurar e atualizar esses aplicativos para evitar o tempo de inatividade durante a migração.
+ **Segurança e conformidade** — analise o ambiente de destino com a equipe de segurança e conformidade e identifique quaisquer lacunas. O aplicativo pode ser composto por vários componentes, camadas lógicas ou várias camadas. Dependendo dos requisitos de conformidade, talvez você não consiga migrar alguns desses componentes para o ambiente de destino ou talvez precise de medidas de segurança adicionais ao migrar a carga de trabalho. Os requisitos comuns de segurança e conformidade são residência de dados, criptografia em trânsito e criptografia em repouso. Eles exigem configuração adicional em seu ambiente de destino. Por exemplo, talvez você precise configurar certificados para proteger as comunicações ou talvez precise de chaves de criptografia para proteger os dados em repouso. Talvez você também precise selecionar vários padrões de migração para o aplicativo para que alguns níveis do aplicativo permaneçam no local e outros sejam migrados para a nuvem.
+ **Dependências de armazenamento** — analise as dependências de armazenamento do aplicativo e determine como a migração do aplicativo para o ambiente de destino afetaria essas dependências. Por exemplo, se o aplicativo depender de armazenamento em rede, como armazenamento conectado à rede (NAS) ou rede de área de armazenamento (SAN), você precisará planejar um serviço de armazenamento na nuvem, como Amazon Simple Storage Service (Amazon S3) ou Amazon. FSx Você também precisa planejar como migrará seus dados para o ambiente de nuvem de destino para manter seu aplicativo em execução.
+ **Banco de dados** — revise a estratégia de migração de qualquer banco de dados usado pelo aplicativo. Você vai mudar a plataforma para um novo serviço de banco de dados, como Amazon Relational Database Service (Amazon RDS), Amazon Aurora ou Amazon DynamoDB? Você vai rehospedar seu banco de dados no ambiente de destino? Em alguns casos, especialmente para um banco de dados monolítico, você precisa refatorar o banco de dados para atender aos requisitos técnicos, como latência de menos de um segundo, ou para aproveitar os recursos de um tipo específico de banco de dados. AWS Assim como acontece com os requisitos de conformidade de residência de dados, você precisa identificar quais dados devem ser retidos no local e quais devem ser migrados para a nuvem. Por exemplo, talvez seja necessário manter uma tabela de banco de dados local para informações do cliente e migrar o restante do banco de dados para a nuvem.
+ **Componentes do aplicativo** — revise os componentes dos quais seu aplicativo depende. Determine se seu aplicativo depende de um componente que não é compatível com o ambiente de destino. Se o ambiente de destino não oferecer suporte a todos os componentes do aplicativo, você precisará refatorar o aplicativo para mitigar o problema. Por exemplo, se você tiver um aplicativo.NET Framework que depende de componentes somente para Windows, como Component Object Model (COM) Interop, COM\+ ou o registro do Windows, para reformular a plataforma do aplicativo em um sistema operacional Linux, você deve refatorar o aplicativo para o.NET Core.
+ **Níveis de aplicativos** — identifique o número de níveis em seu aplicativo. O aplicativo é de n, dois níveis ou autônomo? Confirme se você entende o padrão de migração de cada nível. Por exemplo, seu aplicativo pode ter uma camada de apresentação (ou *web*) que hospeda a interface do usuário, uma camada de aplicativo que hospeda serviços comerciais e uma camada de banco de dados que hospeda bancos de dados, e cada camada pode exigir um padrão de migração diferente.
+ **Recuperação de desastres** — identifique o plano atual e futuro de recuperação de desastres (DR) do aplicativo, incluindo o objetivo de ponto de recuperação (RPO) e o objetivo de tempo de recuperação (RTO). Decida se quer usar o plano de DR local existente ou explorar uma nova estratégia de DR na nuvem. Para obter mais informações, consulte as seções [Opções de recuperação de desastres na nuvem](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html) e [Objetivos de recuperação (RTO e RPO) no whitepaper](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html#recovery-objectives-rto-and-rpo) *Recuperação de Desastres de Cargas de Trabalho em AWS: Recuperação na nuvem*.
### Defina o processo do estado de destino
Para definir o estado de destino do aplicativo, recomendamos que você use o modelo fornecido, *Planilha do estado de destino do aplicativo* (formato Excel), que está disponível nos modelos de [manual do portfólio](samples/portfolio-playbook-templates.zip). O modelo inclui atributos padrão que você pode usar ou modificar. Defina o processo para documentar o estado de destino do aplicativo da seguinte forma:
1. Abra a *planilha do estado de destino do aplicativo*.
1. Revise os atributos padrão e faça as alterações em seu caso de uso.
1. Salve a planilha.
1. Abra seu runbook de priorização de aplicativos.
1. Na seção *Estado do aplicativo de destino*, faça o seguinte:
1. Na seção *Quando concluir esse processo*, estabeleça critérios que permitam à equipe do portfólio determinar se precisa definir o estado de destino do aplicativo.
1. Atualize a seção de atributos conforme necessário.
1. Atualize a seção do processo conforme necessário para seu caso de uso.
1. Salve o runbook de priorização de aplicativos.
#### Amostras do estado de destino do aplicativo
A tabela a seguir mostra um exemplo de como você usa a planilha de *estado de destino do aplicativo* para documentar o estado de destino do aplicativo.
****
| Aplicação | Exemplo |
| --- | --- |
| **Plataforma de destino** | Nuvem AWS |
| **Zona de pouso** | Requer acesso a um serviço de diretório local
AWS Control Tower Requer centralizar o gerenciamento de várias contas e serviços em toda a organização |
| **Dependências** | Active Directory, gateway de pagamento, sistema de inventário |
| **Aplicativos dependentes** | Nenhum |
| **Segurança** | Criptografia de dados em repouso e em trânsito |
| **Conformidade** | FOTO, SOC |
| **Dependências de armazenamento** | Unidade de inicialização conectada, NAS, compartilhamento de rede |
| **Banco de dados** | Atual: Oracle DB
Nuvem: Amazon RDS for Oracle |
| **Componente do aplicativo** | .NET Framework 4.5 |
| **Níveis de aplicativos** | Nível N
Front-end, serviços comerciais, serviços e agentes de dados, banco de dados |
| **Recuperação de desastres** | RPO: 1 min, RTO: 5 min
A estratégia atual de DR é uma espera calorosa
DR em qualquer região dos EUA |
### Critérios de saída da etapa
+ Na *planilha do estado de destino do aplicativo*, você definiu os atributos que deseja incluir no processo do estado de destino.
+ No seu runbook de priorização de aplicativos, você fez o seguinte:
+ Você estabeleceu critérios para quando se espera que a equipe do portfólio defina o estado alvo do aplicativo.
+ Você atualizou o processo para definir o estado de destino com base no seu caso de uso.
## Etapa 4: finalizar o processo de aprofundamento do aplicativo
Agora, você define como o fluxo de trabalho do portfólio usa o workshop, as regras e os processos que você estabeleceu nessa tarefa para realizar uma análise aprofundada do aplicativo. Esse é o processo ao qual o fluxo de trabalho do portfólio faz referência no estágio de implementação da migração.
Personalize esse processo no runbook de priorização de aplicativos da seguinte forma:
1. Abra seu runbook de priorização de aplicativos.
1. Na seção *Etapa 2: realizar uma análise aprofundada do aplicativo*, modifique o processo conforme apropriado para seu caso de uso e ambiente.
1. Salve o runbook de priorização de aplicativos.
1. Compartilhe seu runbook de priorização de aplicativos com a equipe para análise.