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á.
# Análise de portfólio e planejamento de migração
Esse estágio de avaliação se concentra em concluir a descoberta e a análise em nível de portfólio iniciadas na seção [Descoberta de portfólio e planejamento inicial](portfolio-discovery-initial-planning.md). O objetivo é iterar e estabelecer uma linha de base para o portfólio inicial de aplicativos e infraestrutura. Essa linha de base inclui identificar todas as dependências, iterar modelos de racionalização para migração, criar um caso de negócios detalhado e delinear um plano de onda de migração. Como resultado, a fidelidade de dados necessária é maior. Esse estágio exigirá investimento de tempo. Para acelerar os resultados da avaliação, recomendamos usar o maior número possível de fontes de dados programáticas, como ferramentas de descoberta.
Os resultados primários desse estágio incluem o seguinte:
+ Um inventário de aplicativos e infraestrutura de alta fidelidade
+ Uma estratégia de migração de alto nível para cada aplicativo
+ Um plano de onda de migração de alta confiança
+ Um caso de negócios detalhado
# Entendendo os requisitos completos de dados de avaliação
A tabela a seguir descreve as informações necessárias para obter uma visão completa do portfólio dos aplicativos na migração e da infraestrutura associada.
As tabelas usam as seguintes abreviações:
+ R, se necessário
+ O, para opcional
+ N/A, se não aplicável
**Aplicativos**
| **Nome do atributo** | **Descrição** | **Inventário e priorização** | **Caso de negócios detalhado** | **Nível de fidelidade recomendado (mínimo)** |
| --- | --- | --- | --- | --- |
| Identificador exclusivo | Por exemplo, ID do aplicativo. Normalmente disponível em inventários e sistemas de controle internos existentes CMDBs ou outros. Considere criar itens exclusivos IDs sempre que eles não estiverem definidos em sua organização. | R | R | Alto |
| Nome da aplicação | Nome pelo qual esse aplicativo é conhecido pela sua organização. Inclua o nome comercial off-the-shelf (COTS) do fornecedor e do produto quando aplicável. | R | R | Alto |
| É COTS? | Sim ou não. Seja um aplicativo comercial ou um desenvolvimento interno | R | R | Alto |
| Produto e versão COTS | Nome e versão do produto de software comercial | R | R | Alto |
| Description | Função e contexto primários do aplicativo | R | R | Alto |
| Criticidade | Por exemplo, aplicativo estratégico ou gerador de receita ou suporte a uma função crítica | R | R | Alto |
| Tipo | Por exemplo, banco de dados, gerenciamento de relacionamento com o cliente (CRM), aplicativo web, multimídia, serviço compartilhado de TI | R | R | Alto |
| Environment | Por exemplo, produção, pré-produção, desenvolvimento, teste, sandbox | R | R | Alto |
| Conformidade e regulamentação | Estruturas aplicáveis à carga de trabalho (por exemplo, HIPAA, SOX, PCI-DSS, ISO, SOC, FedRAMP) e requisitos normativos | R | R | Alto |
| Dependências | Dependências ascendentes e posteriores de aplicativos ou serviços internos e externos. Dependências não técnicas, como elementos operacionais (por exemplo, ciclos de manutenção). | R | O | Alto |
| Mapeamento de infraestrutura | Mapeamento para ativos and/or virtuais físicos que compõem o aplicativo | R | R | Alto |
| Licença | Tipo de licença de software comum (por exemplo, Microsoft SQL Server Enterprise) | R | R | Médio-alto |
| Custo | Custos de licença de software, operações e manutenção de software | N/D | R | Médio-alto |
| Unidade de negócios | Por exemplo, marketing, finanças, vendas | R | R | Alto |
| Detalhes do proprietário | Informações de contato do proprietário do aplicativo | R | R | Alto |
| Informações sobre DR | componentes de recuperação de desastres | R | R | Alto |
| Estratégia de migração | Por exemplo, um dos 6 Rs para migração para AWS | R | R | Alto |
| Tickets de suporte | 12 a 24 meses de dados para ajudar a avaliar a produtividade e o impacto financeiro de interrupções, lentidão, limitação de transações e excedentes na janela de lotes | O | R | Médio |
**Infraestrutura**
| **Nome do atributo** | **Descrição** | **Inventário e priorização** | **Caso de negócios** | **Nível de fidelidade recomendado (mínimo)** |
| --- | --- | --- | --- | --- |
| Identificador exclusivo | Por exemplo, ID do servidor. Normalmente disponível em inventários e sistemas de controle internos existentes CMDBs ou outros. Considere criar itens exclusivos IDs sempre que eles não estiverem definidos em sua organização. | R | R | Alto |
| Nome da rede | Nome do ativo na rede (por exemplo, nome do host) | R | R | Alto |
| Nome DNS (nome de domínio totalmente qualificado ou FQDN) | Nome DNS | R | O | Alto |
| Endereço IP e máscara de rede | Endereços IP and/or públicos internos | R | R | Alto |
| Asset type (Tipo de ativo) | Por exemplo, servidor físico ou virtual, hipervisor, contêiner, dispositivo, instância de banco de dados | R | R | Alto |
| Nome do produto | Fornecedor comercial e nome do produto (por exemplo, IBM Power Systems VMware ESXi, Exadata) | R | R | Alto |
| Sistema operacional | Por exemplo, REHL 8, Windows Server 2019, AIX 6.1 | R | R | Alto |
| Configuração | CPU alocada, número de núcleos, threads por núcleo, memória total, armazenamento, placas de rede | R | R | Alto |
| Utilização | Pico e média de CPU, memória e armazenamento. Taxa de transferência da instância de banco de dados. | R | R | Alto |
| Licença | Tipo de licença de mercadoria (por exemplo, RHEL Standard) | R | R | Alto |
| A infraestrutura é compartilhada? | Sim ou Não para indicar serviços de infraestrutura que fornecem serviços compartilhados, como provedor de autenticação, sistemas de monitoramento, serviços de backup e serviços similares | R | R | Alto |
| Mapeamento de aplicativos | Aplicativos ou componentes de aplicativos que são executados nessa infraestrutura | R | R | Alto |
| Custo | Custos totalmente elevados de servidores bare-metal, incluindo hardware, manutenção, operações, armazenamento (SAN, NAS, objeto), licença do sistema operacional, compartilhamento de espaço em rack e despesas gerais do data center | N/D | R | Médio-alto |
| Volume estimado de transferência de dados (entrada/saída) | Por exemplo, por ativo de infraestrutura por dia durante um período de 30 dias | O | R | Médio |
**Redes**
| **Nome do atributo** | **Descrição** | **Inventário e priorização** | **Caso de negócios** | **Nível de fidelidade recomendado (mínimo)** |
| --- | --- | --- | --- | --- |
| Tamanho do tubo (Mb/s), redundancy (Y/N) | Especificações atuais do link WAN (por exemplo, redundante de 1000 MB/s) | R | R | Médio-alto |
| Utilização do link | Utilização máxima e média, transferência de dados de saída (GB/mês) | R | R | Médio-alto |
| Latência (ms) | Latência atual entre locais conectados. | R | O | Alto |
| Custo | Custo atual por mês | N/D | R | Médio-alto |
**Migração**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/application-portfolio-assessment-guide/understanding-complete-assessment-data-requirements.html)
# Estabelecendo uma linha de base para o portfólio de aplicativos
Para criar planos de onda de migração de alta confiança, você deve estabelecer uma linha de base para o portfólio de aplicativos e sua infraestrutura associada. Uma linha de base do portfólio fornece uma visão abrangente do escopo da migração, incluindo dependências técnicas e estratégia de migração. A linha de base do portfólio fornece clareza sobre quais aplicativos estão no escopo da migração e se os pontos de dados descritos na seção [Compreendendo os requisitos completos de dados de avaliação são coletados](understanding-complete-assessment-data-requirements.md). Da mesma forma, toda a infraestrutura associada (computação, redes de armazenamento) é compreendida e mapeada para os aplicativos.
As dependências técnicas podem ser descritas em quatro categorias:
+ **pplication-to-infrastructureAs dependências estabelecem o vínculo entre o software e o hardware físico ou virtual.** Por exemplo, há uma dependência entre um aplicativo de CRM e as máquinas virtuais em que ele está instalado.
+ As dependências dos **componentes do aplicativo** descrevem como os componentes executados em diferentes ativos de infraestrutura interagem. Um exemplo de dependência de componente de aplicativo é um front-end web executado em máquinas virtuais, com uma camada de aplicativo em execução em uma máquina virtual diferente e um banco de dados em execução em um cluster de banco de dados.
+ **pplication-to-applicationAs dependências estão relacionadas à interação entre aplicativos ou componentes do aplicativo com outros aplicativos ou seus componentes.** Um exemplo de application-to-application dependência é um aplicativo de processamento de pagamentos e um aplicativo de gerenciamento de estoque. Esses aplicativos são independentes, mas interagem constantemente usando operações de API definidas.
+ Application-to-infrastructure dependências de **serviços** são tecnicamente application-to-application dependências, uma vez que o serviço de infraestrutura é em si uma aplicação. No entanto, recomendamos categorizá-los separadamente. O principal motivo é que os serviços de infraestrutura geralmente são compartilhados por muitos aplicativos, portanto, eles têm uma longa trilha de dependências. Eles também costumam seguir uma estratégia e um padrão de migração diferentes. Por exemplo, um balanceador de carga pode conter pools de balanceamento para vários aplicativos. O que importa é a dependência do pool, que provavelmente será migrada individualmente, junto com o aplicativo dependente, enquanto o próprio balanceador de carga é retido ou retirado. Além disso, a individualização das dependências do application-to-infrastructure serviço ajuda a evitar falsos grupos de dependências. Um falso grupo de dependências ocorre quando vários aplicativos de negócios são agrupados, o que implica que uma dependência comum de um serviço de infraestrutura deve ser migrada ao mesmo tempo. Por exemplo, é provável que serviços de autenticação, como o Active Directory, estejam associados a grandes grupos de aplicativos. A chave é abordar esses aplicativos individualmente e lidar com a dependência habilitando o serviço, por exemplo AWS Directory Service for Microsoft Active Directory, no ambiente de nuvem.
Ao estabelecer uma linha de base para o portfólio, recomendamos que você confirme uma estratégia de migração para cada componente do aplicativo. A estratégia de migração será um dos 6 Rs para migração (consulte a seção [Iterando a estratégia de migração de 6 Rs](iterating-6-rs-migration-strategy-selection.md)). Na linha de base do portfólio, um dos 6 Rs deve ser associado a cada aplicativo. Uma estratégia de 6 R também deve ser associada a cada um dos componentes da infraestrutura do aplicativo.
Para estabelecer uma versão básica do portfólio, incluindo dependências e estratégias de migração, use ferramentas de descoberta automatizadas (consulte [Avaliação da necessidade](understanding-initial-assessment-data-requirements.md#discovery-tooling) de ferramentas de descoberta). Complemente os dados com informações coletadas das principais partes interessadas, como proprietários de aplicativos e equipes de infraestrutura. Continue coletando dados até obter um inventário completo do portfólio que corresponda aos atributos e ao nível de fidelidade descritos na [seção de requisitos de dados](understanding-complete-assessment-data-requirements.md) desta etapa. O conjunto de dados resultante será fundamental para impulsionar a migração.
Considere que, dependendo da extensão do escopo da migração e das ferramentas disponíveis, essa atividade pode levar várias semanas para ser concluída.
# Iterando os critérios de priorização
Antes de criar planos de ondas de migração, recomendamos que você repita os critérios de priorização de aplicativos para passar da seleção de aplicativos piloto para o planejamento de ondas de longo prazo.
[Nas seções anteriores, introduzimos um critério de priorização padrão que priorizaria aplicativos simples prontos para a nuvem (consulte Priorização de aplicativos).](prioritization-and-migration-strategy.md#prioritizing-applications) Isso porque, nos estágios iniciais, recomendamos começar com aplicativos não essenciais para refinar os processos de migração e incorporar as lições aprendidas. No entanto, nesse estágio, e para criar planos de longo prazo, a ordem na qual os aplicativos são migrados deve estar alinhada aos fatores de negócios. A aplicação dos novos critérios gerará uma nova classificação de aplicações que será uma entrada fundamental para o planejamento de ondas.
Analise os pontos de dados disponíveis no portfólio de aplicativos e selecione os atributos que determinarão a priorização de aplicativos com base nos fatores de negócios.
Primeiro, valide seus impulsionadores de negócios (consulte [Diretrizes de negócios e princípios de orientação técnica](business-drivers-technical-guiding-principles.md)). Em seguida, com base em seus fatores de negócios, selecione os atributos que ajudarão a priorizar os aplicativos para migração.
A tabela a seguir mostra exemplos de critérios de priorização alinhados aos fatores de negócios para inovação.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/application-portfolio-assessment-guide/iterating-prioritization-criteria.html)
A tabela a seguir mostra exemplos de critérios de priorização alinhados aos fatores de negócios para uma rápida redução de custos.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/application-portfolio-assessment-guide/iterating-prioritization-criteria.html)
Teste os critérios de priorização e repita até que você geralmente concorde com o resultado. São necessárias pelo menos três ou quatro iterações para obter uma versão básica.
# Iterando a seleção da estratégia de migração de 6 Rs
Nesse estágio, recomendamos que você itere e desenvolva a árvore decisória de 6 Rs. A seção [Determinando o tipo R para migração](prioritization-and-migration-strategy.md#migration-r-type) introduziu uma árvore de decisão padrão. Recomendamos revisar a árvore, considerando os aprendizados durante a migração dos aplicativos piloto iniciais e garantindo que ela ainda esteja alinhada aos fatores de negócios, aos critérios de priorização e às suas circunstâncias específicas. Valide a árvore de decisão com aplicativos de amostra e verifique se ela ainda produz a estratégia esperada. Caso contrário, atualize a lógica adequadamente. A árvore resultante será fundamental para estabelecer linhas de base para o portfólio de aplicativos e para alocar estratégias de migração para cada componente do aplicativo.
Conforme descrito na [seção 6 Rs](prioritization-and-migration-strategy.md#migration-r-type) anterior, os 6 Rs também se aplicam à infraestrutura, e é igualmente importante atribuí-los adequadamente. Embora um determinado componente do aplicativo tenha uma estratégia de migração, no nível da infraestrutura, cada ativo de infraestrutura seguirá uma determinada estratégia de migração que pode ser diferente da estratégia estabelecida para o componente do aplicativo ao qual ele suporta.
Lembre-se de que a árvore decisória de 6 Rs se aplica somente aos componentes do aplicativo. A estratégia de migração da infraestrutura é derivada da estratégia escolhida para o aplicativo. Por exemplo, para um componente de aplicativo que será reformulado, a infraestrutura atual que o hospeda pode ser descontinuada.
Garanta que as estratégias de migração sejam alocadas para cada componente do aplicativo e sua infraestrutura associada. Essas informações serão um fator-chave ao estimar o esforço, a capacidade e as habilidades necessárias e ao criar planos de ondas migratórias.
Para obter mais informações sobre como determinar seus 6 Rs, consulte as [recomendações de AWS Migration Hub estratégia](https://aws.amazon.com/blogs/aws/new-strategy-recommendations-service-helps-streamline-aws-cloud-migration-and-modernization/).
# Planejamento de ondas
No planejamento de ondas, um grupo de dependências é uma coleção de aplicativos e infraestrutura que têm dependências técnicas e não técnicas que não podem ser resolvidas. Por causa dessas dependências, os aplicativos e a infraestrutura em um grupo de dependências devem ser migrados ao mesmo tempo ou em uma data específica. Por exemplo, um aplicativo executado em uma máquina virtual e um banco de dados em execução em uma máquina virtual separada, onde há requisitos de baixa latência ou volumes de alto tráfego e consultas complexas, provavelmente serão migrados juntos em vez de operar um componente na nuvem e o outro no local. Da mesma forma, aplicativos independentes que interagem por meio de uma API com requisitos similares de baixa latência também serão migrados ao mesmo tempo.
As ondas de migração geralmente duram de 4 a 8 semanas e podem conter um ou mais eventos de migração. Os grupos de dependência são combinados em ondas para que uma onda possa conter um ou mais grupos de dependência. A onda também contém outras atividades necessárias para a migração. Isso inclui configuração de AWS infraestrutura (como landing zone, segurança e operações), ferramentas de migração e atividades de migração, como replicação de dados, planejamento de transição, testes e suporte pós-migração.
Para medir o sucesso e acompanhar o progresso, as ondas devem estar alinhadas aos resultados e aos fatores de negócios. Isso também influenciará a duração da onda e os grupos de dependência que uma onda contém. A conclusão de uma onda deve refletir uma conquista mensurável. O planejamento de uma onda também pode combinar outros fatores, como princípios técnicos orientadores. Por exemplo, as ondas podem ser definidas por ambiente (por exemplo, desenvolvimento, teste, produção) ou por estratégia de migração (por exemplo, onda de rehospedagem, onda de replataforma).
Para criar planos de onda de migração eficazes e de alta confiança, você deve obter uma visão completa do portfólio de aplicativos, da infraestrutura associada (computação, armazenamento, redes), do mapeamento de dependências e da estratégia de migração.
A seção sobre como [estabelecer uma linha de base para o portfólio de aplicativos](baseline-application-portfolio.md) descreveu quatro categorias de dependências técnicas. Essas dependências contribuem para a criação de ondas de migração e a definição de grupos de dependência. Os grupos de dependência serão determinados pela criticidade da dependência. Além disso, dependências não técnicas devem ser consideradas. Por exemplo, cronogramas de lançamento de aplicativos, janelas de manutenção e datas comerciais importantes, como o final do mês ou o processamento do final do trimestre, influenciarão o plano Wave.
Determine se a dependência é *leve* ou *difícil*. Uma dependência suave é uma relação entre dois ou mais ativos, ou entre um ativo e uma restrição, que não depende da localização dos componentes. Por exemplo, dois sistemas que operam na mesma rede local (ou na mesma infraestrutura) podem ser separados movendo um desses sistemas para a nuvem enquanto o outro permanece no local. Outro exemplo é um sistema que pode ser migrado durante uma janela de manutenção sem afetar as atividades de manutenção.
Uma dependência rígida é uma relação entre dois ou mais ativos, ou entre um ativo e uma restrição, que depende da localização. Por exemplo, dois sistemas que operam na mesma rede local e que são altamente dependentes da baixa latência para comunicação entre o servidor de aplicativos e o servidor de banco de dados têm uma forte dependência. Mover apenas um desses sistemas para a nuvem causaria problemas de funcionalidade ou desempenho que não podem ser resolvidos. Da mesma forma, motivos não técnicos, como disponibilidade de recursos (por exemplo, a equipe que está realizando a migração) ou restrições operacionais, como janelas de manutenção em que dois sistemas só podem ser migrados em uma determinada janela de tempo, podem criar uma forte dependência desses ativos.
Para criar um plano de onda de migração, determine seus grupos de dependências analisando dependências, de preferência de uma fonte de dados altamente confiável, como ferramentas de descoberta especializadas, e combine essas informações com seus critérios de priorização de aplicativos e circunstâncias operacionais. Os aplicativos no topo da classificação de priorização devem ser direcionados para suas ondas iniciais de migração. Determine a capacidade da onda (o número de aplicativos que uma onda pode conter) com base na disponibilidade de recursos, tolerância ao risco, restrições comerciais e técnicas, experiência e habilidades. Considere trabalhar com serviços AWS profissionais ou parceiros de competência em AWS migração, que podem fornecer especialistas para ajudá-lo durante todo o processo.
Os critérios de priorização são uma indicação inicial da ordem na qual você moverá seus aplicativos para a nuvem. No entanto, os grupos de dependências serão o determinante real dos aplicativos que serão movidos em um determinado momento. Isso ocorre porque os aplicativos classificados como de alta prioridade podem ter dependências rígidas dos aplicativos que estão no meio ou na parte inferior da classificação.
A estratégia de migração também influenciará a composição de uma onda. Por exemplo, uma aplicação de alta prioridade que requer uma estratégia de refatoração que pode exigir várias semanas ou meses de análise, projeto, testes e preparações provavelmente será colocada em uma onda posterior.
## Criando um plano de ondas
Um pré-requisito para migrar uma onda de aplicativos são os dados do portfólio de aplicativos e a avaliação detalhada do grupo de aplicativos que serão migrados na onda. A avaliação detalhada deve incluir a lista de aplicativos na onda, os detalhes da infraestrutura associada, um projeto de destino e uma estratégia de migração para cada aplicativo.
Estabelecer a propriedade e a governança da onda é fundamental para gerenciar e monitorar o trabalho da onda, as dependências do programa, o gerenciamento de mudanças, os problemas e os riscos. Garanta que exista uma estrutura de governança para gerenciar o plano.
Para delinear o plano de onda, comece com uma construção de onda padrão. O que acontece dentro de uma onda? Depois que a entrada inicial for definida, a onda pode começar. Normalmente, as atividades serão:
1. Refine o plano de transição. Essa atividade deve descrever os runbooks e as etapas que devem ser tomadas no momento da migração, incluindo a coordenação com outras equipes internas e externas.
1. Refine o plano de reversão. O que deve ser feito para reverter os aplicativos se as coisas derem errado?
1. Prepare a infraestrutura de destino. Por exemplo, você pode criar ou ampliar a AWS landing zone (segurança Conta da AWS, rede, serviços de infraestrutura, outras infraestruturas de suporte).
1. Teste a infraestrutura de destino.
1. Opere as ferramentas de migração. Por exemplo, instale agentes de replicação e inicie a transferência de dados.
1. Conduza um plano de transição e execute tiragens secas. Agrupe todos os membros da equipe participantes e analise todas as etapas com antecedência.
1. Monitore a replicação de dados e as implantações de infraestrutura.
1. Confirme a prontidão para operação da infraestrutura e dos aplicativos em AWS.
1. Confirme a prontidão de segurança.
1. Confirme os requisitos regulatórios e de conformidade (por exemplo, validação da carga de trabalho antes e depois da migração), se aplicável.
1. Migre os aplicativos AWS e realize testes antes da ativação.
1. Forneça suporte pós-migração por um período de tempo, como 3 dias, quando as equipes de operações e as equipes de migração estiverem totalmente disponíveis para resolver problemas e aplicar otimizações.
1. Conduza uma revisão pós-migração. Documente as lições aprendidas e incorpore-as às futuras ondas.
1. Realize o encerramento da onda confirmando a transferência operacional e a obtenção de métricas para relatórios.
A duração de cada uma dessas atividades será ditada pela complexidade do escopo, pela capacidade das ondas, pelas pessoas envolvidas e por suas circunstâncias únicas. Sempre que possível, ondas menores são preferíveis, pois isso reduzirá o impacto de quaisquer atrasos ou bloqueios de migração. Determine, com suas equipes, qual será a duração padrão de uma onda.
Em seguida, continue analisando as datas para criar uma estrutura inicial de alto nível de ondas vazias (sem nenhum aplicativo atribuído ainda). Considere as seguintes perguntas:
+ Qual é a duração total do programa de migração?
+ Quais são os prazos?
+ Há datas fixas de saída do data center?
+ Existem datas de término do contrato de colocação?
+ Quais são os ciclos de atualização de aplicativos e infraestrutura?
+ Quais são os ciclos de manutenção e lançamento de aplicativos?
+ Há alguma data em que as migrações devem ser evitadas (por exemplo, ciclos de lançamento e manutenção, final de ano, feriados, processamento no final do mês)?
Com essas considerações, trace as ondas em um plano. Para acelerar o processo de migração, recomendamos a sobreposição de ondas sempre que possível. A chave para ondas sobrepostas é definir e considerar o que acontece dentro de uma onda. Normalmente, as atividades de implantação, a validação da infraestrutura de destino e a sincronização de dados ocorrerão durante a primeira metade de uma onda. A segunda metade se concentrará na migração real, nos testes e na transferência operacional. Isso significa que equipes diferentes estão envolvidas em cada metade do processo e que você pode obter alguma eficiência. Por exemplo, assim que a equipe envolvida na preparação da infraestrutura alvo concluir seu trabalho, ela poderá começar a trabalhar nos requisitos da próxima onda. Em geral, é preferível que a maioria das ondas tenha comprimento e estrutura semelhantes para facilitar uma abordagem de migração semelhante à de uma fábrica. No entanto, durante o processo de planejamento de ondas, o tamanho de uma determinada onda pode ser estendido para atender às dependências ou aos requisitos operacionais.
Em seguida, com base nos grupos de dependência identificados, determine o tamanho máximo de uma onda em termos do número de grupos de dependência que ela pode conter. O tamanho da onda geralmente é determinado pelo apetite pelo risco (por exemplo, quanta mudança paralela pode ser tolerada) e pela disponibilidade de recursos (por exemplo, quanta mudança paralela pode ser realizada com os recursos, habilidades e orçamento disponíveis). No entanto, durante o planejamento inicial, não se limite aos requisitos e à disponibilidade de recursos. Ondas que contêm mais de um grupo de dependências podem ser decompostas em ondas menores em iterações futuras.
Depois que os grupos de dependência de uma determinada onda forem confirmados, revise os requisitos de recursos para migrar a onda. Considere ajustar o tamanho da onda (o número de grupos de dependência que ela contém) com base nos requisitos de recursos. Isso pode levar a ondas menores ou maiores. Repita o plano de ondas conforme necessário até que todas as ondas tenham sido definidas.
## Gerenciando mudanças
O portfólio de aplicativos e a infraestrutura associada mudarão durante o ciclo de vida dos programas de migração. Os programas de migração de longa duração coexistem com a evolução e a mudança normais dos negócios. Os aplicativos continuam evoluindo enquanto aguardam a migração. Os servidores são adicionados ou removidos, uma nova infraestrutura é implantada no local. Espera-se que o escopo de uma onda ou grupo de dependência exija mudanças. Mudanças são necessárias especialmente quando, mais perto da data de migração, uma dependência até então desconhecida é identificada ou um novo servidor é incluído no inventário. Às vezes, isso pode acontecer durante a migração em si.
As mudanças no escopo afetam grupos e ondas de dependência. Para lidar com as mudanças e minimizar o impacto, é importante estabelecer um mecanismo de controle de escopo. Um mecanismo de controle de mudança de escopo requer a definição de uma única fonte confiável para o escopo. Isso pode ser uma ferramenta para gerenciar o escopo ou um arquivo.csv, planilha ou banco de dados, conforme definido pela governança do programa de migração. Você deve identificar mudanças, analisar o impacto e comunicar as mudanças às partes interessadas relevantes para que elas possam agir. Como resultado, o plano de ondas será iterado.
# Caso de negócios detalhado
Nesse estágio, recomendamos validar e expandir o escopo do caso de negócios para fornecer um nível maior de detalhes para apoiar o programa de transformação. O caso de negócios direcional inicial, montado rapidamente, foi projetado para fornecer confiança suficiente para investir nas etapas fundamentais e no próximo nível de planejamento detalhado.
O desenvolvimento de um caso de negócios detalhado apóia esse processo de planejamento das seguintes maneiras:
+ Fornecendo análises financeiras que informam as decisões sobre o que deve ser migrado e modernizado, quais opções selecionar e como fasear e priorizar o trabalho
+ Validando, refinando e desenvolvendo o caso financeiro direcional original, reexaminando detalhadamente:
+ O potencial de redução de custos de infraestrutura
+ A produtividade interna de TI e qualquer eficiência de operações terceirizadas
+ As estimativas dos investimentos necessários para configuração, migração e modernização do programa
+ Identificar, estimar a escala e configurar o processo para rastrear os outros fatores de valor que a migração traz
No caso comercial detalhado, você estabelece o seguinte:
+ A base objetiva sobre a qual garantir o mandato e o investimento para implementar pelo menos a primeira fase da migração
+ A expectativa básica de desempenho financeiro mínimo para o programa
+ Clareza sobre a base financeira na qual várias decisões de design e priorização da migração são tomadas, para que, quando as circunstâncias e as pessoas mudarem ao longo do programa, a nova liderança possa fazer escolhas informadas.
+ Visão das áreas incrementais de otimização de custos a serem exploradas após a disponibilização dos dados de uso inicial à medida que as cargas de trabalho são migradas e iniciam a operação
+ Estimativas do valor que a transformação da nuvem traz para os negócios com o aumento da resiliência e agilidade
+ As métricas e suposições associadas KPIs usadas para estimar o retorno financeiro da melhoria da resiliência e agilidade, que então formam a linha de base para impulsionar a realização dos benefícios primários do programa
## Determine os cenários necessários para o caso
Ao criar o caso de negócios detalhado, geralmente é necessário desenvolver vários cenários para dar suporte aos vários propósitos para os quais o caso de negócios é usado.
**Cenário de mudança mínima** — Para avaliar a expectativa mínima de desempenho financeiro, prepare um cenário que pressupõe a alteração mínima esperada no status quo. Esse cenário, na pior das hipóteses, é um suporte útil para obter o mandato de investir na migração. Esse cenário modela o grau mínimo esperado de crescimento da capacidade e as mudanças mínimas para outras quality-of-service necessidades, como disponibilidade e resiliência. A menor alteração cria o menor custo e a menor ineficiência de recursos para o modelo operacional atual.
**Cenário mais provável** — Para informar a estratégia do programa e as decisões de priorização, prepare o cenário que reflita o que a empresa espera que aconteça. Esse cenário deve incluir o provável pico de crescimento ou redução da utilização e os custos de atualização para atender à demanda por altos níveis de qualidade de serviço (especialmente disponibilidade e resiliência) da empresa.
**Outros cenários específicos** — Onde ainda é necessário fazer uma suposição que possa ter um grande impacto no caso de negócios, desenvolva cenários em que a suposição seja verdadeira ou não. No entanto, recomendamos manter o número desses cenários alternativos no mínimo absoluto. Criar mais de três a quatro cenários no total retarda o progresso e se torna caro, confuso e difícil de manter. Sempre que possível, realize experimentos e trabalhe para remover suposições maiores.
## Valide e refine a infraestrutura e o modelo de custo de migração
Depois de concluir a análise do portfólio e preparar o design e o dimensionamento da meta Serviços da AWS, refine as estimativas de custo operacional para o modelo operacional atual (COM) e o modelo operacional futuro (FOM) AWS para cada cenário. Geralmente, é necessário refinar as estimativas para o seguinte:
+ **Custos da infraestrutura COM** de servidor host hipervisor, servidor bare-metal, armazenamento, dispositivo de rede, atualizações de hardware, instalação e manutenção de dispositivos de segurança. Calcule-os com preços reais e níveis de desconto para a capacidade necessária para o cenário.
+ **Custos do data center COM e das instalações alocadas**, incluindo espaço, resfriamento, energia, racks, fonte de alimentação ininterrupta (UPS), cabeamento, sistemas de segurança física, dimensionados para o crescimento e especificados para atender à capacidade, além dos níveis de alta disponibilidade e recuperação de desastres (DR) do cenário.
+ **Custos de serviços de rede COM**, incluindo custos de links de WAN, redes de entrega de conteúdo e redes privadas virtuais (VPNs), calculados usando preços contratados para as necessidades de conectividade, largura de banda, taxa de transferência e latência do cenário.
+ **Custos de software de aplicativos e infraestrutura** COM com base nos contratos existentes para proporcionar o crescimento ou a redução do uso do cenário.
+ **Custos de serviços AWS públicos do FOM**, incluindo suporte técnico e serviços gerenciados conforme necessário, com base na arquitetura de serviços refinada, nos tamanhos das instâncias, no modelo de preços preferencial, no uso esperado e na volatilidade do uso.
+ **Licenciamento de aplicativos FOM** com base no design final do aplicativo, na configuração da infraestrutura que executa os aplicativos, no crescimento ao longo do tempo e nas regras de transferibilidade de licenças.
+ **Estimativas de custo de migração e modernização do FOM**, refinadas para refletir o plano básico da onda de migração do cenário e detalhadas para fornecer custos para cada carga de trabalho, especialmente para aquelas que serão reformuladas, recompradas ou refatoradas.
+ **Os custos de descomissionamento do FOM**, incluindo estimativas de baixa de ativos e custos de rescisão antecipada de contratos, revisados para refletir o tempo de descomissionamento no plano básico da onda de migração, verificação de quais ativos podem ser reaproveitados e quais ativos podem ser trocados para minimizar as baixas e o custo de descarte dos ativos físicos e da mídia.
+ **Custos de execução paralela de migração** refinados para refletir o tempo de cada transição de migração e cada descomissionamento de serviço existente.
## Refine a produtividade de TI e as operações de TI e suporte o modelo de valor da eficiência
Assim como no caso de negócios direcional, há duas abordagens principais para refinar e desenvolver o modelo de valor em torno das operações e do suporte de TI. A abordagem escolhida depende de o COM ser gerenciado internamente ou com prestadores de serviços ou terceirizados:
*Melhoria da produtividade da equipe interna*
Onde as operações e o suporte de TI são gerenciados internamente, o foco do caso de negócios está no seguinte:
+ Identificar e quantificar os ganhos de produtividade da migração e de qualquer automação operacional incluída no escopo
+ Validar que o tempo liberado para a equipe interna pode ser aplicado de forma rápida e produtiva a outras atividades normalmente de maior valor, oferecendo oportunidades de progressão e maior recompensa para a equipe e mais valor para a organização
Avalie quanto tempo cada membro em cada função da equipe gasta em suas várias atividades regulares e oriente sobre a redução esperada na carga de trabalho para diferentes atividades.
A tabela a seguir fornece orientação inicial para os níveis típicos de redução da carga de trabalho por atividade para as tarefas que consomem a maior parte das operações de TI e do esforço de suporte nas diferentes funções da equipe. A tabela inclui uma descrição de como a produtividade é alcançada.
**nota**
As atividades listadas geralmente são realizadas por membros da equipe em várias funções diferentes, portanto, a economia de produtividade em cada tarefa deve ser avaliada em todo o conjunto de funções da equipe. Por exemplo, em equipes de operações de TI organizadas por torre de infraestrutura (como computação, armazenamento e rede), o planejamento e o orçamento de despesas de capital podem ser comuns aos líderes de torre de cada torre.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/application-portfolio-assessment-guide/detailed-business-case.html)
A tabela a seguir mostra a economia esperada para cada nível de redução da carga de trabalho.
| **Nível** | **Esperado** |
| --- | --- |
| Muito alto | 85% - 100% |
| Alto | 60% - 90% |
| Médio | 30% - 70% |
| Baixo | 10% - 35% |
| Mínimo | 0% - 10% |
Essas métricas fornecem um ponto de partida para avaliar os ganhos de produtividade e incluí-los no caso comercial detalhado. Os ganhos reais de produtividade variam de acordo com a situação específica. Pode ser útil calcular a economia de produtividade no ponto médio e inferior das faixas para estimar cenários típicos e conservadores.
À medida que o programa avança, é importante capturar dados reais do tempo gasto em cada atividade por função. Esses dados criam uma base aprimorada para estimar as operações e apoiam os custos de novos projetos e expansões de serviços.
*Operações terceirizadas de TI e redução de custos de suporte*
[Onde as operações e o suporte de TI são principalmente terceirizados ou gerenciados por prestadores de serviços, a alocação de custos para o modelo operacional futuro (FOM) pode ser preparada solicitando cotações de AWS parceiros que oferecem soluções de serviços gerenciados, inclusive lideradas por parceiros (AMS). AWSAWS Managed Services](https://aws.amazon.com/managed-services/partners/) Você também pode entrar em contato com seu gerente de AWS conta e solicitar um preço diretamente para o AMS, conforme descrito na subseção Incorporando a [otimização de custos operacionais na](directional-business-case.md#building-operational-cost-optimization) seção [Criação de um caso de negócios direcional](directional-business-case.md).
Para o caso comercial detalhado, substitua qualquer valor de referência por uma cotação com base na lista de materiais de AWS serviços revisada e no consumo esperado do serviço, no pacote AMS e nas opções necessárias e no nível de serviço necessário. O custo terá um componente de implementação único e uma taxa de execução baseada no consumo.
Inclua todas as operações de TI restantes, o suporte que deve ser mantido para qualquer serviço para AWS o qual não será migrado e um custo único se houver alguma penalidade contratual (por exemplo, por rescisão antecipada).
## Desenvolva o modelo de valor de resiliência
Ativado AWS, você pode criar uma ampla variedade de arquiteturas de alta disponibilidade, recuperação de desastres e tolerantes a falhas. Os preços baseados no consumo significam que os serviços são cobrados somente quando usados. Juntos, esses dois fatores fornecem um desempenho de custo excepcional para resiliência.
Além disso, AWS os clientes têm usado isso para melhorar a resiliência de suas cargas de trabalho. A [pesquisa de 2018 da IDC](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-BV%20IDC%202018.pdf?aliId=1614258770) dá exemplos de clientes participantes que obtiveram 73% menos interrupções por ano, uma redução de 58% no tempo médio de recuperação (MTTR) e uma redução de 94% na perda de produtividade. A mesma pesquisa mostrou que os benefícios financeiros derivados do aumento da resiliência foram 50% maiores do que o benefício de redução de custos da infraestrutura de TI.
Além disso, maior resiliência é alcançada por meio da modernização do ciclo de vida de desenvolvimento de software para aplicativos. Quando CI/CD pipelines com automação de testes são introduzidos para oferecer maior agilidade nos negócios, os defeitos de software são detectados no início do ciclo de desenvolvimento, reduzindo consideravelmente os custos de manutenção do software.
**Para avaliar e incluir esse valor no caso de negócios, primeiro trabalhe com proprietários de empresas de aplicativos para criar uma imagem da *oportunidade total de benefícios* para cada carga de trabalho a ser migrada.**Isso pode incluir os seguintes itens:
+ O número, a duração média e a natureza das interrupções no serviço:
+ Exemplos de interrupções de serviço incluem interrupções, lentidão no desempenho, sobrecarga planejada de lotes e janelas de manutenção, bugs nas principais funções e limitação de acesso durante os períodos de pico.
+ Impacto na receita por interrupções de serviços geradores de receita, como sistemas de comércio eletrônico:
+ O número provável de transações que não puderam ser concluídas por meio de interrupções no serviço, com base no tempo de interrupção e nas taxas de transação
+ Valor médio de cada transação afetada
+ O custo adicional do tempo dos engenheiros de suporte para resolver defeitos nos sistemas de produção em comparação com o custo de descobri-los no início do processo de desenvolvimento
+ Impacto na produtividade dos usuários internos e no custo do tempo perdido
Em seguida, faça uma avaliação de uma redução esperada e mais conservadora no tempo perdido em interrupções de serviço**** que o aumento da resiliência deve gerar. Por exemplo, considere incluir os seguintes itens:
+ Número reduzido de paralisações e MTTR usando arquiteturas de alta disponibilidade e melhores objetivos de tempo de recuperação (RTO) e objetivos de ponto de recuperação (RPO)
+ Redução da lentidão, eliminação da limitação da capacidade e prevenção de excessos no processamento em lote, usando recursos como escalabilidade automática
+ Número reduzido de bugs de aplicativos que são descobertos somente na produção, por meio da implementação de CI/CD pipelines e testes de regressão automatizados na infraestrutura ativada e desativada para minimizar os custos
Junte-os para que o portfólio de aplicativos seja migrado e modernizado e calcule os valores de valor comercial esperados e mais conservadores para cada ano do caso. Os benefícios devem aumentar de acordo com o cronograma de migração e, em seguida, aumentar o volume de acordo com as expectativas de crescimento do uso dos aplicativos contribuintes.
## Desenvolva o modelo de valor da agilidade comercial
A agilidade nos negócios é o principal motivo pelo qual AWS os clientes migram para o. AWS A [pesquisa de 2018 da IDC](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-BV%20IDC%202018.pdf?aliId=1614258770) com AWS clientes indicou que, para eles, os benefícios de agilidade nos negócios representaram 47% do total de benefícios medidos e mais de cinco vezes os benefícios decorrentes da redução de custos de infraestrutura.
Prever com precisão todos os benefícios de agilidade comercial decorrentes de qualquer transformação é um desafio. No entanto, ao se concentrar em aplicativos que oferecem suporte a um grande número de usuários ou são fontes de diferenciação comercial, você pode modelar e incluir uma parte material desse benefício no caso comercial detalhado da linha de base.
À medida que a migração prossegue, refine e expanda incrementalmente o modelo de valor da agilidade comercial à medida que mais benefícios se tornam quantificáveis. Isso mantém o caso de negócios relevante, para que ele possa ser usado como a principal ferramenta de apoio à decisão com a qual conduzir o programa.
Para criar o modelo de valor da agilidade comercial, use a seguinte orientação:
+ Selecione as cargas de trabalho que têm a oportunidade de promover a maior melhoria no desempenho dos negócios, como:
+ Cargas de trabalho geradoras de receita
+ Cargas de trabalho de operações comerciais com escopo para gerar ganhos de eficiência e remover custos dos negócios
+ Ferramentas de produtividade empresarial que dão suporte a grandes bases de usuários
+ Para cargas de trabalho geradoras de receita e eficiência, faça o seguinte:
+ Faça uma avaliação realista e mais conservadora do crescimento da receita ou da eficiência operacional que se espera que grandes e pequenas atualizações de aplicativos gerem.
+ Estime o aumento do número de lançamentos principais e secundários por ano que o AWS aumento da velocidade de desenvolvimento de aplicativos e a redução do tempo de implantação da infraestrutura permitem. Algumas métricas básicas para isso são fornecidas no relatório da IDC.
+ Calcule as expectativas de benefícios realistas e mais conservadoras. Mapeie-os durante o período do business case, fazendo concessões para aumentar a eficiência total algum tempo após a migração das respectivas cargas de trabalho.
+ Para ferramentas de produtividade empresarial, faça o seguinte:
+ Faça uma avaliação realista e mais conservadora da economia de tempo que se espera que grandes e pequenas atualizações de aplicativos gerem.
+ Estime o custo médio do tempo e do esforço das pessoas em toda a base de usuários afetada.
+ Use os números para aumentar a frequência de lançamentos principais e secundários e calcule os benefícios ao longo do prazo do business case.
Como o aumento da produtividade do desenvolvedor e a redução do tempo de lançamento não exigem recursos adicionais, adicione as linhas de benefícios líquidos para cada carga de trabalho ao modelo de fluxo de caixa do business case para inclusão nos cálculos de fluxo de caixa com desconto, NPV, ROI, MIRR e retorno financeiro.