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á. # Aceleração da descoberta e planejamento inicial Essa primeira etapa da avaliação do portfólio se concentra nas etapas iniciais de obtenção e análise de dados no nível do portfólio. O objetivo principal é identificar fatores de negócios e coletar dados gerais de aplicativos e infraestrutura para obter uma visão inicial do portfólio. Esses dados incluem atributos técnicos e comerciais de alto nível, como nomes de aplicativos, ambiente, versões de produtos, criticidade, valores de desempenho e outros, conforme descrito na seção de [requisitos de dados](understanding-initial-assessment-data-requirements.md). Concluir essa etapa é fundamental para entender o escopo do projeto, identificar os candidatos à migração inicial e informar o caso comercial. ## Resultados primários desta fase + Diretrizes comerciais, resultados, metas e princípios orientadores técnicos documentados. + Um inventário inicial de aplicativos e infraestrutura e identificou lacunas de dados. Essa é uma visão inicial do portfólio que será iterada e refinada em etapas posteriores. + Um caso de negócios direcional e custo estimado para migrar. + Uma lista dos candidatos à migração inicial (por exemplo, três a cinco inscrições). + Próximas etapas definidas. # Entendendo os requisitos de dados de avaliação inicial A coleta de dados pode levar um tempo significativo e facilmente se tornar um bloqueador quando não há clareza sobre quais dados são necessários e quando são necessários. A chave é entender o equilíbrio entre o que é pouco e o que é muita informação para os resultados dessa etapa. Para se concentrar nos dados e no nível de fidelidade necessários para esse estágio inicial da avaliação do portfólio, adote uma abordagem iterativa para a coleta de dados. ## Fontes de dados e requisitos de dados A primeira etapa é identificar suas fontes de dados. Comece identificando as principais partes interessadas em sua organização que podem atender aos requisitos de dados. Normalmente, são membros das equipes de gerenciamento de serviços, operações, planejamento de capacidade, monitoramento e suporte, além dos proprietários dos aplicativos. Estabeleça sessões de trabalho com membros desses grupos. Comunique os requisitos de dados e obtenha uma lista de ferramentas e documentação existente que podem fornecer os dados. Para orientar essas conversas, use o seguinte conjunto de perguntas: + Quão preciso e atualizado é o inventário atual de infraestrutura e aplicativos? Por exemplo, para o banco de dados de gerenciamento de configuração da empresa (CMDB), já sabemos onde estão as lacunas? + Temos ferramentas e processos ativos que mantêm o CMDB (ou equivalente) atualizado? Em caso afirmativo, com que frequência ele é atualizado? Qual é a data de atualização mais recente? + O inventário atual, como o CMDB, contém application-to-infrastructure mapeamento? Cada ativo de infraestrutura está associado a um aplicativo? Cada aplicativo está mapeado para a infraestrutura? + O inventário contém um catálogo de licenças e contratos de licenciamento para cada produto? + O inventário contém dados de dependência? Observe a existência de dados de comunicação, como servidor para servidor, aplicativo para aplicativo, aplicativo ou servidor para banco de dados. + Quais outras ferramentas que podem fornecer informações sobre aplicativos e infraestrutura estão disponíveis no ambiente? Observe a existência de ferramentas de desempenho, monitoramento e gerenciamento que podem ser usadas como fonte de dados. + Quais são os diferentes locais, como data centers, que hospedam nossos aplicativos e infraestrutura? Depois que essas perguntas forem respondidas, liste suas fontes de dados identificadas. Em seguida, atribua um nível de fidelidade, ou nível de confiança, a cada um deles. Os dados validados recentemente (dentro de 30 dias) a partir de fontes programáticas ativas, como ferramentas, têm o mais alto nível de fidelidade. Os dados estáticos são considerados de menor fidelidade e menos confiáveis. Exemplos de dados estáticos são documentos, pastas de trabalho CMDBs, atualizados manualmente ou qualquer outro conjunto de dados não mantido programaticamente, ou cuja data da última atualização seja anterior a 60 dias. Os níveis de fidelidade de dados na tabela a seguir são fornecidos como exemplos. Recomendamos que você avalie os requisitos de sua organização em termos de tolerância máxima às suposições e ao risco associado para determinar qual é o nível adequado de fidelidade. Na tabela, o conhecimento institucional se refere a qualquer informação sobre aplicativos e infraestrutura que não esteja documentada. | **Fontes de dados** | **Nível de fidelidade** | **Cobertura do portfólio** | **Comentários** | | --- |--- |--- |--- | | Conhecimento institucional | Baixo - Até 25% dos dados precisos, 75% dos valores assumidos ou os dados têm mais de 150 dias. | Baixo | Escasso, focado em aplicações críticas | | Base de conhecimento | Médio-baixo - 35-40% dos dados precisos, 65-60% dos valores assumidos ou os dados têm 120-150 dias. | Médio | Níveis de detalhes inconsistentes e mantidos manualmente | | CMDB | Médio - \$1 50% de dados precisos, \$1 50% de valores assumidos ou dados com 90 a 120 dias. | Médio | Contém dados de fontes mistas, várias lacunas de dados | | VMware Exportações do vCenter | Médio-alto - 75-80% de dados precisos, 25-20% de valores assumidos ou dados com 60 a 90 dias. | Alto | Cobre 90% da propriedade virtualizada | | Monitoramento da performance de aplicativos | Alto - Dados geralmente precisos, \$1 5% dos valores ou dados presumidos têm de 0 a 60 dias. | Baixo | Limitado a sistemas de produção críticos (cobre 15% do portfólio de aplicativos) | As tabelas a seguir especificam os atributos de dados obrigatórios e opcionais para cada classe de ativo (aplicativos, infraestrutura, redes e migração), a atividade específica (inventário ou caso de negócios) e a fidelidade de dados recomendada para esse estágio de avaliação. As tabelas usam as seguintes abreviações: + R, se necessário + (D), para casos de negócios direcionais, necessários para comparações de custo total de propriedade (TCO) e casos de negócios direcionais + (F), para um caso de negócios direcional completo, necessário para comparação de TCO e casos de negócios direcionais que incluem custos de migração e modernização + 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** | **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 (D) | 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 (D) | Médio-alto | | É COTS? | Sim ou não. Seja um aplicativo comercial ou um desenvolvimento interno | R | R (D) | Médio-alto | | Produto e versão COTS | Nome e versão do produto de software comercial | R | R (D) | Médio | | Description | Função e contexto primários do aplicativo | R | O | Médio | | Criticidade | Por exemplo, aplicativo estratégico ou gerador de receita ou suporte a uma função crítica | R | O | Médio-alto | | Tipo | Por exemplo, banco de dados, gerenciamento de relacionamento com o cliente (CRM), aplicativo web, multimídia, serviço compartilhado de TI | R | O | Médio | | Environment | Por exemplo, produção, pré-produção, desenvolvimento, teste, sandbox | R | R (D) | Médio-alto | | Conformidade e regulamentação | Estruturas aplicáveis à carga de trabalho (por exemplo, HIPAA, SOX, PCI-DSS, ISO, SOC, FedRAMP) e aos requisitos normativos | R | R (D) | Médio-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) | O | O | Médio-baixo | | Mapeamento de infraestrutura | Mapeamento para ativos and/or virtuais físicos que compõem o aplicativo | O | O | Médio | | Licença | Tipo de licença de software comum (por exemplo, Microsoft SQL Server Enterprise) | O | R | Médio-alto | | Custo | Custos de licença de software, operações e manutenção de software | N/D | O | 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 | O | Médio-alto | | Nome DNS (nome de domínio totalmente qualificado ou FQDN) | Nome DNS | O | O | Médio | | Endereço IP e máscara de rede | Endereços IP and/or públicos internos | R | O | Médio-alto | | Asset type (Tipo de ativo) | Servidor físico ou virtual, hipervisor, contêiner, dispositivo, instância de banco de dados etc. | R | R | Médio-alto | | Nome do produto | Fornecedor comercial e nome do produto (por exemplo, IBM Power Systems VMware ESXi, Exadata) | R | R | Médio | | Sistema operacional | Por exemplo, REHL 8, Windows Server 2019, AIX 6.1 | R | R | Médio-alto | | Configuração | CPU alocada, número de núcleos, threads por núcleo, memória total, armazenamento, placas de rede | R | R | Médio-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 | O | Médio-alto | | Licença | Tipo de licença de mercadoria (por exemplo, RHEL Standard) | R | R | Médio | | 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 (D) | Médio | | Mapeamento de aplicativos | Aplicativos ou componentes de aplicativos que são executados nessa infraestrutura | O | O | Médio | | Custo | Custos totalmente elevados de servidores bare-metal, incluindo hardware, manutenção, operações, armazenamento (SAN, NAS, objeto), licença do sistema operacional, participação no espaço em rack e despesas gerais do data center | N/D | O | Médio-alto | **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) | O | R | Médio | | Utilização do link | Utilização máxima e média, transferência de dados de saída (GB/mês) | O | R | Médio | | Latência (ms) | Latência atual entre locais conectados. | O | O | Médio | | Custo | Custo atual por mês | N/D | O | Médio | **Migração** | | | | | | | --- |--- |--- |--- |--- | | **Nome do atributo** | **Descrição** | **Inventário e priorização** | **Caso de negócios** | **Nível de fidelidade recomendado (mínimo)** | | Redefinir a hospedagem | Esforço do cliente e do parceiro para cada carga de trabalho (pessoa-dia), taxas de custo do cliente e do parceiro por dia, custo da ferramenta, número de cargas de trabalho | N/D | R (F) | Médio-alto | | Redefinir a plataforma | Esforço do cliente e do parceiro para cada carga de trabalho (pessoa-dia), taxas de custo de clientes e parceiros por dia, número de cargas de trabalho | N/D | R (F) | Médio-alto | | Refatorar | Esforço do cliente e do parceiro para cada carga de trabalho (pessoa-dia), taxas de custo de clientes e parceiros por dia, número de cargas de trabalho | N/D | O | Médio-alto | | Retirada | Número de servidores, custo médio de desativação | N/D | O | Médio-alto | | Zona de pouso | Reutilização existente (S/N), lista de AWS regiões necessárias, custo | N/D | R (F) | Médio-alto | | Pessoas e mudança | Número de funcionários a serem treinados em operações e desenvolvimento em nuvem, custo do treinamento por pessoa, custo do tempo de treinamento por pessoa | N/D | R (F) | Médio-alto | | Duração | Duração da migração da carga de trabalho dentro do escopo (meses) | O | R (F) | Médio-alto | | Custo paralelo | Prazo e taxa em que os custos atuais podem ser removidos durante a migração | N/D | O | Médio-alto | | Prazo e taxa em que AWS produtos e serviços e outros custos de infraestrutura são introduzidos durante a migração | N/D | O | Médio-alto | ## Avaliando a necessidade de ferramentas de descoberta Sua organização precisa de ferramentas de descoberta? A avaliação do portfólio exige up-to-date dados de alta confiança sobre aplicativos e infraestrutura. Os estágios iniciais da avaliação do portfólio podem usar suposições para preencher lacunas de dados. No entanto, à medida que o progresso é feito, os dados de alta fidelidade permitem a criação de planos de migração bem-sucedidos e a estimativa correta da infraestrutura de destino para reduzir custos e maximizar os benefícios. Também reduz o risco ao permitir implementações que consideram dependências e evitam armadilhas de migração. O principal caso de uso das ferramentas de descoberta em programas de migração para a nuvem é reduzir o risco e aumentar os níveis de confiança nos dados por meio do seguinte: + Coleta de dados automatizada ou programática, resultando em dados validados e altamente confiáveis + Aceleração da taxa na qual os dados são obtidos, melhorando a velocidade do projeto e reduzindo os custos + Níveis aumentados de integridade dos dados, incluindo dados de comunicação e dependências que normalmente não estão disponíveis no CMDBs + Obter insights como identificação automatizada de aplicativos, análise de TCO, taxas de execução projetadas e recomendações de otimização + Planejamento de ondas de migração de alta confiança Quando há incerteza sobre a existência de sistemas em um determinado local, a maioria das ferramentas de descoberta pode escanear sub-redes de rede e descobrir os sistemas que respondem a solicitações de ping ou SNMP (Simple Network Management Protocol). Observe que nem todas as configurações de rede ou sistemas permitirão tráfego de ping ou SNMP. Discuta essas opções com sua rede e equipes técnicas. Outros estágios de avaliação e migração do portfólio de aplicativos dependem muito de informações precisas de mapeamento de dependências. O mapeamento de dependências fornece uma compreensão da infraestrutura e da configuração que serão necessárias AWS (como grupos de segurança, tipos de instância, posicionamento da conta e roteamento de rede). Também ajuda a agrupar aplicativos que devem ser movidos ao mesmo tempo (como aplicativos que precisam se comunicar em redes de baixa latência). Além disso, o mapeamento de dependências fornece informações para a evolução do caso de negócios. Ao decidir sobre uma ferramenta de descoberta, é importante considerar todas as etapas do processo de avaliação e antecipar os requisitos de dados. As lacunas de dados têm o potencial de se tornarem bloqueadoras, por isso é fundamental antecipá-las analisando os requisitos e fontes de dados futuros. A experiência na área determina que a maioria dos projetos de migração paralisados tem um conjunto de dados limitado no qual os aplicativos no escopo, na infraestrutura associada e suas dependências não são claramente identificados. Essa falta de identificação pode levar a métricas, decisões e atrasos incorretos. A obtenção up-to-date de dados é a primeira etapa para projetos de migração bem-sucedidos. *Como selecionar uma ferramenta de descoberta?* Várias ferramentas de descoberta no mercado oferecem recursos e capacidades diferentes. Considere seus requisitos. E escolha a opção mais adequada para sua organização. Os fatores mais comuns ao decidir sobre uma ferramenta de descoberta para migrações são os seguintes: *Segurança* + Qual é o método de autenticação para acessar o repositório de dados da ferramenta ou os mecanismos de análise? + Quem pode acessar os dados e quais são os controles de segurança para acessar a ferramenta? + Como a ferramenta coleta dados? Ele precisa de credenciais dedicadas? + Quais credenciais e nível de acesso a ferramenta precisa para acessar meus sistemas e obter dados? + Como os dados são transferidos entre os componentes da ferramenta? + A ferramenta oferece suporte à criptografia de dados em repouso e em trânsito? + Os dados estão centralizados em um único componente dentro ou fora do meu ambiente? + Quais são os requisitos de rede e firewall? Garanta que as equipes de segurança estejam envolvidas nas primeiras conversas sobre ferramentas de descoberta. *Soberania de dados* + Onde os dados são armazenados e processados? + A ferramenta usa um modelo de software como serviço (SaaS)? + Ele tem a possibilidade de reter todos os dados dentro dos limites do meu ambiente? + Os dados podem ser examinados antes de deixarem os limites da minha organização? Considere as necessidades da sua organização em termos de requisitos de residência de dados. *Arquitetura* + Qual infraestrutura é necessária e quais são os diferentes componentes? + Há mais de uma arquitetura disponível? + A ferramenta suporta a instalação de componentes em zonas de segurança bloqueadas? *Desempenho* + Qual é o impacto da coleta de dados em meus sistemas? *Compatibilidade e escopo* + A ferramenta é compatível com todos ou a maioria dos meus produtos e versões? Revise a documentação da ferramenta para verificar as plataformas suportadas em relação às informações atuais sobre seu escopo. + A maioria dos meus sistemas operacionais é compatível com a coleta de dados? Se você não conhece as versões do seu sistema operacional, tente restringir a lista de ferramentas de descoberta para aquelas com a maior variedade de sistemas compatíveis. *Métodos de coleta* + A ferramenta exige a instalação de um agente em cada sistema de destino? + Ele oferece suporte a implantações sem agentes? + O agente e o sem agente fornecem os mesmos recursos? + Qual é o processo de coleta? *Recursos* + Quais são os recursos disponíveis? + Ele pode calcular o custo total de propriedade (TCO) e a taxa de Nuvem AWS execução estimada? + Ele oferece suporte ao planejamento da migração? + Ele mede o desempenho? + Ele pode recomendar a AWS infraestrutura alvo? + Ele executa o mapeamento de dependências? + Que nível de mapeamento de dependências ele fornece? + Ele fornece acesso à API? (por exemplo, ele pode ser acessado programaticamente para obter dados?) Considere ferramentas com funções robustas de mapeamento de dependências de aplicativos e infraestrutura e aquelas que possam inferir aplicativos a partir de padrões de comunicação. *Custos* + Qual é o modelo de licenciamento? + Quanto custa o licenciamento? + O preço é para cada servidor? É um preço diferenciado? + Há alguma opção com recursos limitados que pode ser licenciada sob demanda? Normalmente, as ferramentas de descoberta são usadas em todo o ciclo de vida dos projetos de migração. Se seu orçamento for limitado, considere pelo menos 6 meses. No entanto, a ausência de ferramentas de descoberta normalmente leva a um maior esforço manual e custos internos. *Modelo de suporte* + Quais níveis de suporte são fornecidos por padrão? + Há algum plano de suporte disponível? + Quais são os tempos de resposta a incidentes? *Serviços profissionais* + O fornecedor oferece serviços profissionais para analisar os resultados da descoberta? + Eles podem abordar os elementos deste guia? + Existem descontos ou pacotes para ferramentas e serviços? **dica** Para encontrar e avaliar ferramentas de descoberta, use o site [Descoberta, Planejamento e Recomendação](https://aws.amazon.com/prescriptive-guidance/migration-tools/migration-discovery-tools/). *Recursos recomendados para a ferramenta de descoberta* Para evitar o provisionamento e a combinação de dados de várias ferramentas ao longo do tempo, uma ferramenta de descoberta deve abranger os seguintes recursos mínimos: + **Software** — a ferramenta de descoberta deve ser capaz de identificar os processos em execução e o software instalado. + **Mapeamento de dependências** — Ele deve ser capaz de coletar informações de conexão de rede e criar mapas de dependência de entrada e saída dos servidores e aplicativos em execução. Além disso, a ferramenta de descoberta deve ser capaz de inferir aplicativos de grupos de infraestrutura com base em padrões de comunicação. + **Descoberta de perfil e configuração** — Ele deve ser capaz de relatar o perfil da infraestrutura, como família de CPU (por exemplo, x86, PowerPC), número de núcleos de CPU, tamanho da memória, número de discos e tamanho e interfaces de rede. + **Descoberta de armazenamento em rede** — Ele deve ser capaz de detectar e traçar o perfil de compartilhamentos de rede a partir do armazenamento conectado à rede (NAS). + **Desempenho** — Ele deve ser capaz de relatar o pico e a média de utilização da CPU, memória, disco e rede. + **Análise de lacunas** — Deve ser capaz de fornecer informações sobre a quantidade e a fidelidade dos dados. + **Escaneamento de rede** — Ele deve ser capaz de escanear sub-redes de rede e descobrir ativos de infraestrutura desconhecidos. + **Relatórios** — Ele deve ser capaz de fornecer o status de coleta e análise. + **Acesso à API** — Deve ser capaz de fornecer meios programáticos para acessar os dados coletados. *Recursos adicionais a serem considerados* + **Análise de TCO** para fornecer uma comparação de custos entre o custo local atual e o custo projetado AWS . + **Recomendações de análise e otimização de licenciamento** para sistemas Microsoft SQL Server e Oracle em cenários de rehospedagem e replataforma. + **Recomendação da estratégia de migração** (a ferramenta de descoberta pode fazer recomendações padrão do tipo R de migração com base na tecnologia atual?) + **Exportação de inventário** (para CSV ou formato similar) + **Recomendação de dimensionamento correto** (por exemplo, ela pode mapear uma AWS infraestrutura alvo recomendada?) + **Visualização de dependências** (por exemplo, o mapeamento de dependências pode ser visualizado em modo gráfico?) + **Visualização arquitetônica** (por exemplo, diagramas arquitetônicos podem ser produzidos automaticamente?) + **Priorização de aplicativos** (é possível atribuir peso ou relevância aos atributos do aplicativo e da infraestrutura para criar critérios de priorização para a migração?) + **Planejamento de ondas** (por exemplo, grupos recomendados de aplicativos e a capacidade de criar planos de ondas de migração) + Estimativa do **custo de migração (estimativa** do esforço para migrar) *Considerações de implantação* Depois de selecionar e adquirir uma ferramenta de descoberta, considere as seguintes perguntas para conduzir conversas com as equipes responsáveis pela implantação da ferramenta em sua organização: + Os servidores ou aplicativos são operados por terceiros? Isso pode determinar as equipes a serem envolvidas e os processos a serem seguidos. + Qual é o processo de alto nível para obter aprovação para implantar ferramentas de descoberta? + Qual é o principal processo de autenticação para acessar sistemas como servidores, contêineres, armazenamento e bancos de dados? As credenciais do servidor são locais ou centralizadas? Qual é o processo para obter credenciais? Serão necessárias credenciais para coletar dados de seus sistemas (por exemplo, contêineres, servidores virtuais ou físicos, hipervisores e bancos de dados). Obter credenciais para que a ferramenta de descoberta se conecte a cada ativo pode ser um desafio, especialmente quando esses ativos não estão centralizados. + Qual é o esboço das zonas de segurança da rede? Os diagramas de rede estão disponíveis? + Qual é o processo para solicitar regras de firewall nos data centers? + Quais são os contratos atuais de nível de serviço de suporte (SLAs) em relação às operações do data center (instalação de ferramentas de descoberta, solicitações de firewall)? # Diretrizes de negócios e princípios orientadores técnicos ## Condutores de negócios Se sua organização já decidiu migrar para a nuvem ou está próxima dessa decisão, definir e documentar os fatores de negócios para a migração para a nuvem esclarecerá os motivos da migração. Depois que os motivos forem documentados, você poderá definir o que será migrado e como será migrado. Essa atividade é importante. Recomendamos que isso ocorra o mais cedo possível no processo para informar e orientar as próximas etapas. Identifique as partes interessadas que devem fazer parte da discussão para documentar os motivadores. Normalmente CxOs, gerentes seniores e principais líderes de tecnologia da organização e seus próprios clientes. Embora não seja provável que seus clientes participem dessa discussão, recomendamos que uma ou mais pessoas em sua organização sejam designadas para representar as visões e metas de seus clientes. Os impulsionadores de negócios devem estar vinculados a uma métrica que possa ser medida em toda a jornada de migração para validar se os resultados foram alcançados. As metas estratégicas e os relatórios anuais da empresa podem servir como ponto de partida. Concentre a conversa em onde a empresa quer estar, com base nas métricas existentes e projetadas, como resultado da mudança para a nuvem. Considere as metas e os resultados comerciais. Além disso, considere como é o sucesso à medida que a adoção da nuvem aumenta. Em seguida, estabeleça o nível de importância para cada motorista. Quais são as prioridades? Quais são os benefícios esperados? Como os benefícios apoiam as metas e os resultados da empresa? No contexto da avaliação do portfólio de aplicativos, as respostas ajudarão a priorizar as cargas de trabalho para migração e a estabelecer princípios orientadores técnicos. No entanto, os fatores de negócios definirão e afetarão o programa de migração como um todo. ## Princípios orientadores técnicos Os princípios orientadores técnicos informam a seleção da estratégia de migração em estágios posteriores da avaliação do portfólio. No estágio atual, o foco é identificá-los. Os princípios orientadores podem ser estabelecidos como decisões gerais relacionadas à tecnologia e à abordagem derivadas de metas e resultados de negócios. Por exemplo, uma empresa tem como meta principal reduzir custos, e o resultado desejado é fechar um data center local até uma determinada data em 6 a 12 meses. Um princípio orientador resultante é elevar e transferir todos os aplicativos para a nuvem usando uma estratégia de migração de rehospedagem ou realocação sempre que possível. Nesse caso, a lift-and-shift abordagem acelera os resultados da migração de curto prazo. Depois que os aplicativos saírem do data center local, a empresa pode se concentrar nos principais fatores de negócios para otimizar ou modernizar as cargas de trabalho migradas. Para estabelecer os princípios orientadores técnicos, comece analisando os fatores de negócios. Identifique uma lista de tecnologias e técnicas que alcançarão as metas e os resultados comerciais. Em seguida, refine a lista e atribua uma ordem de relevância com base na adequação ou preferência para alcançar o resultado desejado. Documente e comunique os princípios orientadores às pessoas envolvidas no planejamento e execução da migração. Destaque preocupações e possíveis conflitos entre os princípios e a implementação real. A tabela a seguir fornece um exemplo de motivadores de negócios e princípios orientadores técnicos. | **Condutor de negócios** | **Resultado** | **Métricas** | **Princípio orientador técnico** | | --- |--- |--- |--- | | Acelere a inovação. | Competitividade aprimorada, maior agilidade nos negócios | Número de implantações por dia ou mês, novos recursos lançados por trimestre, índices de satisfação do cliente, número de experimentos | Refatore aplicativos diferenciadores usando microsserviços e o modelo DevOps operacional para aumentar a agilidade e a velocidade de comercialização de novos recursos. | | Reduza os custos operacionais e de infraestrutura. | Base de custo elástica compatível com oferta e demanda (pague pelo que você usa) | Variação do gasto ao longo do tempo | 1. Hospede novamente os aplicativos com o tamanho certo da infraestrutura. 2. Desative os aplicativos com baixa ou nenhuma utilização. | | Aumente a resiliência operacional. | Tempo de atividade aprimorado, tempo médio de recuperação reduzido | SLAs, número de incidentes | 1. Reorganize os aplicativos para as versões mais recentes e com melhor suporte do sistema operacional. 2. Implemente arquiteturas de alta disponibilidade para aplicativos críticos. | | Saia do data center. | Fechamento do data center em uma data dentro de 6 a 12 meses | Velocidade das migrações de servidores | Hospede novamente os aplicativos usando a Cloud Migration Factory Solution. | | Permaneça no local, mas aumente a agilidade e a resiliência. | Maior competitividade e tempo de atividade, permanecendo no local | Número de implantações por dia ou mês, lançamentos de novos recursos por trimestre SLAs, número de incidentes | 1. Modernize os sistemas estendendo suas funcionalidades para a nuvem.2. Avalie para rehospedar ou reformular a plataforma para. AWS Outposts | # Iniciando a coleta de dados A coleta de dados é o processo de coleta de metadados de aplicativos e infraestrutura. O processo é iterativo em todas as etapas da avaliação. Em cada estágio, a quantidade e a fidelidade dos dados aumentarão. Nesse estágio, o foco está na coleta de dados gerais que possam ajudar a estabelecer um inventário inicial. O inventário será usado para criar um caso de negócios direcional e a identificação dos candidatos à migração inicial. Depois que as fontes de dados atuais forem identificadas, recomendamos coletar informações do maior número possível de sistemas. Para obter mais informações, consulte os [requisitos de dados](understanding-initial-assessment-data-requirements.md) para esse estágio. Essa abordagem tem a vantagem de ajudar a atualizar a visão atual do portfólio e o conhecimento da organização sobre seus aplicativos e serviços. Também ajuda a determinar o que deve ser movido. A abordagem recomendada é revisar os dados existentes, como saídas do banco de dados de gerenciamento de configuração (CMDB) e sistemas de gerenciamento de serviços de tecnologia da informação (ITSM). Em seguida, crie uma lista de ativos destinados à coleta de dados. Se sua organização tiver clareza total do que está dentro e fora do escopo da migração, você pode restringir a coleta de dados aos sistemas que estão no escopo. Ao criar seu portfólio, considere os aplicativos e seus ambientes ou ciclos de vida de lançamento de software. Por exemplo, em vez de identificar um aplicativo de gerenciamento de relacionamento com o cliente (CRM) e especificar que ele tem ambientes de teste, desenvolvimento e produção, liste três aplicativos (por exemplo, CRM-test, CRM-dev, CRM-prod). Como alternativa, use o nome do CRM, mas atribua uma ID exclusiva a cada ambiente e apresente-os como registros separados em seu repositório de dados. Isso ajudará a planejar e acompanhar a migração desses ambientes individualmente. Por exemplo, talvez você queira migrar primeiro ambientes que não sejam de produção. Ao listar as instâncias do seu aplicativo de acordo com o ambiente, você pode gerenciar e controlar claramente sua transição. Durante a coleta de dados, pode haver incerteza sobre quais aplicativos ou servidores estão em um determinado data center ou local de origem. Nesses casos, é útil obter listas bare-metal e de hipervisores das ferramentas de gerenciamento existentes. Por exemplo, você pode se conectar a um hipervisor para obter listas de máquinas virtuais a serem destinadas à coleta de dados. Observe que a saída inicial, ao combinar fontes de dados existentes, pode estar incompleta. A chave é realizar uma análise de lacunas em termos dos [requisitos de dados](understanding-initial-assessment-data-requirements.md) para esse estágio e do que pode ser obtido das fontes existentes. É importante comparar a porcentagem de integridade com o nível de fidelidade dos dados. Níveis mais altos de completude de fontes de baixa fidelidade conterão várias suposições que podem levar a análises errôneas. Embora esse estágio de avaliação não exija a máxima fidelidade dos dados, recomendamos que as fontes de dados tenham pelo menos uma fidelidade média a média-alta. Compare esses números com a tolerância de sua organização ao risco, incluindo o uso de suposições para preencher lacunas de dados. A análise de lacunas ajuda você a entender a quantidade e a qualidade dos dados com os quais você está trabalhando. A análise também ajuda você a estabelecer o nível de suposições que devem ser feitas para criar um caso de negócios direcional e priorizar os aplicativos para migração. As ferramentas de descoberta podem ajudar a preencher as lacunas e coletar dados de alta fidelidade. Para aumentar os níveis de confiança nos dados e acelerar os resultados da migração, recomendamos a implantação de ferramentas de descoberta o mais cedo possível. A ação antecipada também é importante porque os processos internos de aquisição, segurança e implementação de novas ferramentas podem exigir várias semanas ou meses para serem concluídos. Recomendamos estabelecer um plano ou cadência de comunicação e um mecanismo de controle de mudança de escopo neste estágio. Isso ajuda você a manter as partes interessadas informadas para que possam planejar com antecedência e mitigar os riscos. Um elemento-chave para comunicações claras é definir uma única fonte confiável para o portfólio de aplicativos e a infraestrutura associada. Evite manter vários sistemas de registro e listas de aplicativos e infraestrutura. Mantenha os dados em um só lugar (por exemplo, um banco de dados, uma ferramenta ou uma planilha) que ofereça suporte ao controle de versão e à colaboração on-line e atribua um proprietário a eles. # Estratégia de priorização e migração Um elemento-chave do planejamento da migração é estabelecer critérios de priorização. O objetivo desse exercício é entender a ordem na qual os aplicativos serão migrados. A estratégia é adotar uma abordagem iterativa e progressiva para desenvolver o modelo de priorização. ## Priorizando aplicativos Essa etapa da avaliação se concentra em estabelecer critérios iniciais para priorizar cargas de trabalho de baixo risco e baixa complexidade. Essas cargas de trabalho são boas candidatas para aplicativos piloto. Usar cargas de trabalho de baixo risco e baixa complexidade nas migrações iniciais reduz o risco e dá às equipes a oportunidade de ganhar experiência. Esses critérios serão desenvolvidos em outros estágios de avaliação para alinhar a priorização aos fatores de negócios ao criar o plano da onda de migração. Os critérios iniciais devem priorizar aplicativos com um pequeno número de dependências, executados em infraestrutura suportada pela nuvem e em ambientes que não sejam de produção. Um exemplo seriam aplicativos com 0 a 3 dependências prontos para serem rehospedados no estado em que se encontram em um ambiente de desenvolvimento ou teste. Esses critérios são válidos para definir os aplicativos piloto e, potencialmente, a primeira e a segunda ondas de migração, dependendo do nível de maturidade e dos níveis de confiança na adoção da nuvem. *Decidindo quais critérios iniciais usar* Selecione de 2 a 10 pontos de dados a serem usados para priorizar suas primeiras cargas de trabalho. Esses pontos de dados vêm do seu inventário inicial de aplicativos e infraestrutura (consulte a seção de [coleta de dados](initiating-data-collection.md)). Em seguida, defina uma pontuação ou peso para cada valor possível de cada ponto de dados. Por exemplo, se o atributo de ambiente for selecionado e os valores possíveis forem produção, desenvolvimento e teste, cada valor receberá uma pontuação, um número maior representando maior prioridade. Embora seja opcional, recomendamos atribuir um fator multiplicador de importância ou relevância a cada ponto de dados. Essa etapa opcional fornece um diferencial de alto nível para enfatizar o que é mais importante, o que ajuda a manter os critérios alinhados à medida que você itera a atribuição de pontuações aos valores. Com base na estratégia de priorizar aplicativos simples e de baixo risco para as primeiras ondas de migração, a tabela a seguir mostra exemplos de seleção de atributos e suas atribuições de valor. | **Atributo (ponto de dados)** | **Possíveis valores** | **Pontuação (0-99)** | **Fator multiplicador de importância ou relevância** | | --- |--- |--- |--- | | Environment | Testar | 60 | Alto (1x) | | Desenvolvimento | 40 | | Produção | 20 | | Criticidade dos negócios | Baixo | 60 | Alto (1x) | | Médio | 40 | | Alto | 20 | | Estrutura regulatória ou de conformidade | Nenhum | 60 | Alto (1x) | | FedRAMP | 10 | | Compatibilidade com sistema operacional | Pronto para a nuvem | 60 | Médio-alto (0,8x) | | Não suportado na nuvem | 10 | | Número de instâncias computacionais | 1 a 3 | 60 | Médio-alto (0,8x) | | 4-10 | 40 | | 11 ou mais | 20 | | Estratégia de migração | Redefinir a hospedagem | 70 | Médio (0,6x) | | Redefinir a plataforma | 30 | | Refatore ou reestruture | 10 | Certifique-se de selecionar atributos que possam atuar como principais diferenciais entre os aplicativos. Caso contrário, os critérios resultarão em muitas cargas de trabalho compartilhando a mesma prioridade. Depois de aplicar o modelo, recomendamos examinar a parte superior e inferior da classificação resultante para ver se você concorda. Se você geralmente não concorda, pode rever os critérios usados para pontuar as cargas de trabalho. Depois de obter uma classificação, veja a distribuição das pontuações em todo o portfólio. As pontuações em si não importam. É a diferença entre as pontuações que importa. Por exemplo, você pode descobrir que a pontuação total máxima é 8.000 e a pontuação inferior é 800. Considere traçar as pontuações resultantes como um histograma, para que você possa verificar se tem uma boa distribuição. A distribuição ideal parece uma curva de sino padrão, com algumas cargas de trabalho de prioridade muito alta e algumas cargas de trabalho de prioridade muito baixa. A maioria dos aplicativos estará em algum lugar intermediário. Outro aspecto importante da priorização inicial é incluir equipes internas ou unidades de negócios que demonstrem interesse em serem pioneiras na adoção da nuvem. Isso pode ser uma alavanca considerável na obtenção de suporte comercial para migrar um determinado aplicativo, especialmente nos primeiros dias. Se esse for o caso em sua organização, inclua o atributo da unidade de negócios na tabela anterior. Atribua uma pontuação alta às unidades de negócios que estão dispostas a apresentar seus aplicativos. Usar o atributo de unidade de negócios ajudará a colocar esses aplicativos no topo da lista. Depois de concordar com a classificação resultante, selecione os 5 a 10 melhores aplicativos. Esses serão seus candidatos iniciais à migração de aplicativos. Refine a lista para confirmar de 3 a 5 inscrições. Isso ajuda você a adotar uma abordagem direcionada ao realizar uma avaliação detalhada do aplicativo. Para obter mais informações, consulte [Avaliação de aplicativos priorizados](prioritized-applications-assessment.md). ## Determinando o tipo R para migração A decisão sobre uma estratégia de migração para cada aplicativo e infraestrutura associada terá implicações na velocidade, no custo e no nível de benefícios da migração. É fundamental determinar a estratégia com base em uma combinação equilibrada de fatores, incluindo motivadores de negócios, princípios orientadores técnicos, critérios de priorização e estratégia de negócios. Às vezes, esses fatores criam visões conflitantes. Por exemplo, o principal fator para a migração pode ser a inovação e a agilidade. Ao mesmo tempo, talvez seja necessário reduzir custos rapidamente. A modernização de todos os aplicativos dentro do escopo reduzirá os custos a longo prazo, mas exigirá um maior investimento inicial. Nesse caso, uma abordagem é migrar aplicativos usando estratégias que exijam menos esforço, como rehospedar ou reformular a plataforma. Isso pode proporcionar eficiência rápida e redução de custos no curto prazo. Em seguida, reinvista a economia na modernização do aplicativo em um estágio posterior e obtenha uma maior redução de custos. No entanto, começar com uma nova hospedagem completa de todos os aplicativos atrasa os maiores benefícios da modernização. A chave é encontrar o equilíbrio entre as estratégias de migração para que os aplicativos estratégicos de negócios sejam priorizados para modernização, enquanto outros aplicativos possam ser rehospedados ou reformulados primeiro e depois modernizados. *Como determinar uma estratégia de migração para seus aplicativos?* Nesse estágio de avaliação, o foco é incorporar um modelo inicial para orientar a seleção da estratégia de migração. Para validar a estratégia de migração para os aplicativos iniciais, use o modelo em conjunto com os impulsionadores de negócios e os critérios de priorização. A lógica padrão da árvore decisória ajudará você a determinar o tratamento inicial para o escopo. Na árvore, as abordagens mais complexas, como refatorar ou rearquitetar, são reservadas para suas cargas de trabalho estratégicas. ![\[O processo de decisão de 6 R discutido neste guia.\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/application-portfolio-assessment-guide/images/6Rs-DecisionTree-baseModel.png) *[Uma versão [draw.io](https://github.com/jgraph/drawio-desktop/releases) personalizável desse diagrama está disponível na seção Anexos.](#attachments)* A primeira etapa para um modelo inicial é atualizar os drivers de negócios no topo da árvore com aqueles definidos pela sua organização. Em seguida, aplique a árvore aos componentes do aplicativo, e não aos aplicativos como um todo. Por exemplo, no caso de um aplicativo de três camadas com três componentes (front-end, camada de aplicativo e banco de dados), cada componente deve transitar pela árvore de forma independente e receber uma estratégia e um padrão específicos. Isso ocorre porque, em alguns casos, talvez você queira rehospedar ou reformular uma determinada camada e refatorar (rearquitetar) outras camadas. A atribuição independente de componentes levará você a definir uma estratégia de migração para a infraestrutura associada. A estratégia de infraestrutura pode ser a mesma do componente do aplicativo ao qual ela oferece suporte, ou pode ser diferente. Por exemplo, um componente do aplicativo que será reformulado em uma nova máquina virtual com um sistema operacional mais novo seguirá a estratégia de replataforma, enquanto a máquina virtual atual que o hospeda será desativada. A estratégia de migração da infraestrutura é calculada com base na estratégia escolhida para os componentes do aplicativo. Antes de usar a árvore decisória para estabelecer estratégias de migração, teste a lógica com alguns aplicativos e veja se você geralmente concorda com o resultado. A árvore de decisão de 6 Rs é um guia que não substitui a análise necessária para determinar sua exatidão. A lógica da árvore pode não se aplicar a casos específicos. Trate esses casos como exceções e anule a decisão orientada pela árvore documentando a justificativa para a substituição em vez de alterar a lógica da árvore. Isso evita várias versões da árvore de decisão, que podem se tornar difíceis de gerenciar. A orientação geral é que a árvore seja válida para pelo menos 70 a 80 por cento das cargas de trabalho. Quanto ao resto, haverá exceções. Quaisquer ajustes na lógica da árvore, nesse estágio de avaliação, devem ser focados no estabelecimento de um modelo inicial. Outras iterações e refinamentos ocorrerão em estágios posteriores, como [análise de portfólio e planejamento de migração](portfolio-analysis-migration-planning.md). ## Anexos [attachment.zip](samples/attachment.zip) # Criando um caso de negócios direcional As partes interessadas de toda a empresa devem entender e aceitar o caso de negócios para a transformação em cada etapa do processo. Nos estágios iniciais, é importante mostrar rapidamente o valor potencial suficiente de um programa de migração, para que você possa garantir os recursos necessários para planejar e estabelecer o programa. O caso de negócios direcional foi projetado para fornecer confiança razoável na obtenção de um valor comercial convincente com os dados limitados que podem ser coletados antecipadamente. Depois que o programa é estabelecido, o caso de negócios é desenvolvido ainda mais. O caso detalhado fornece maior precisão, uma visão mais completa do valor do programa e uma visão das prioridades de planejamento. Ele define e quantifica os resultados comerciais planejados que a organização adota e define a linha de base com a qual seu escritório de governança do programa pode então orientar o programa e medir suas realizações. ## Corrigindo o escopo do caso comercial direcional Normalmente, um business case direcional é montado rapidamente, em 2 a 4 semanas. Ele precisa gerar confiança suficiente para que você possa garantir os recursos necessários para estabelecer a equipe principal, engajar os AWS parceiros, se necessário, e, no mínimo, concluir as etapas [priorizadas de avaliação de aplicativos](prioritized-applications-assessment.md), [análise de portfólio e planejamento de migração](portfolio-analysis-migration-planning.md). Normalmente, os casos de negócios direcionais que suportam migrações de portfólio são criados como um dos seguintes: + Uma**** comparação simples *do custo total de propriedade (TCO)* entre o cenário da infraestrutura no estado em que se encontra e a arquitetura AWS service (Serviço da AWS) pós-migração. A comparação mostra a diferença nas taxas de execução esperadas para determinados volumes de carga de trabalho. + Um caso de negócios**** que mostra o valor presente líquido (VPL), o retorno sobre o investimento (ROI), o período de retorno, a taxa interna de retorno modificada (MIRR) e análises de fluxo de caixa de 3 a 5 anos para migrar para incluir os custos de migração versus permanecer como está. AWS O escopo direcional do caso de negócios geralmente é limitado a um dos seguintes: + Uma comparação dos custos de tecnologia de infraestrutura + Uma comparação da tecnologia de infraestrutura e dos custos operacionais Em geral, quanto maior o portfólio, menos desenvolvido o caso precisa ser. Isso ocorre porque suposições mais amplas podem ser feitas sem afetar significativamente o resultado. Para um portfólio menor, qualquer alteração terá um impacto maior, portanto, são necessários mais detalhes. Comece criando a comparação de custos da infraestrutura básica. Em seguida, decida se a comparação é suficientemente convincente antes de continuar. Normalmente, portfólios de mais de 400 servidores mostrarão um caso de negócios positivo apenas na redução dos custos de infraestrutura em 3 anos de operação AWS, ou 250 servidores em 5 anos, embora isso possa variar. Para portfólios menores, talvez sejam necessários mais detalhes. Por outro lado, raramente é útil examinar outros componentes de valor comercial nesse estágio, como o valor derivado da resiliência aprimorada ou da agilidade comercial, a menos que o escopo total da migração seja inferior a cerca de 5 cargas de trabalho ou 50 servidores. ## Focalize os fatores de valor A comparação do TCO da tecnologia de infraestrutura compara um modelo dos custos de infraestrutura no estado em que se encontram com um modelo básico da AWS service (Serviço da AWS) lista de materiais necessária para executar suas cargas de trabalho com desempenho e disponibilidade equivalentes. Muitas otimizações podem ser feitas. Nesse estágio, no entanto, o foco está na lista a seguir, porque elas são mais fáceis de avaliar e normalmente geram uma economia de cerca de 30% no TCO, o que é suficiente para avançar: + **Elasticidade computacional** — Mapeie servidores cujo uso não é 100%, como servidores de desenvolvimento ou UAT executando 8x5 (24% de uso), 10x5 (30%) ou 10x6 (36%), e servidores de recuperação de desastres (DR) em execução a 2%, para serviços sob demanda que são cobrados somente quando usados. + **Adquira com um plano de economia** — Planeje adquirir servidores de produção e outros servidores com alto uso (mais de 36%) com um plano de economia adequado para reduzir os custos em até 75%. As opções incluem compromissos de 1 e 3 anos, com diferentes níveis de pagamentos antecipados para garantir maiores descontos. + **Remova zumbis** — identifique servidores com utilização de CPU inferior a 2%, que você possa confirmar que não são mais necessários, e remova-os da análise de custos. + **Dimensionamento correto da computação** — use dados de séries temporais de utilização da CPU e da memória para avaliar, para cada servidor, a potência computacional e a memória necessárias. Em seguida, selecione a instância do Amazon Elastic Compute Cloud (Amazon EC2) adequada. + **Dimensionamento correto da licença do sistema de gerenciamento de banco de dados relacional (RDBMS)** — Reavalie suas necessidades de licenciamento de RDBMS após calcular o dimensionamento correto em seus servidores de banco de dados, compare Bring Your Own License (BYOL) e Adquirindo a licença e explore o AWS potencial do Amazon Relational Database Service (Amazon RDS) para aumentar a economia. + **Armazenamento** — dimensione corretamente o volume total de armazenamento necessário e identifique as necessidades de input/output operações por segundo (IOPS) em todo o portfólio. Determine quanto pode ser transferido para o armazenamento de objetos com custos diferentes SLAs . ## necessidades de dados A tabela em [Entendendo os requisitos de dados de avaliação inicial](understanding-initial-assessment-data-requirements.md) mostra os dados necessários para criar cada parte de um caso comercial direcional e se eles são obrigatórios ou opcionais. Para criar o caso, você precisa do subconjunto de infraestrutura dos dados de planejamento inicial mais os dados de custo. Determinar como identificar a infraestrutura a ser incluída depende de sua meta comercial: + Se o objetivo do programa for migrar e modernizar aplicativos específicos, crie o portfólio de infraestrutura com base no que os aplicativos precisam, levando em consideração a infraestrutura compartilhada. + Se o objetivo do programa for centrado na infraestrutura, como migrar de um data center cujo contrato está prestes a expirar, o mapeamento de aplicativos não é necessário para comparações de TCO de infraestrutura. Os dados marcados como opcionais (como a utilização máxima da CPU e da memória para servidores) geralmente podem ser substituídos por valores de referência padrão. Você pode discutir isso com um AWS parceiro ou com um serviço AWS profissional. Ou você pode extrapolar os valores dos pontos de dados que estão disponíveis em parte do seu portfólio (como dados coletados por um hipervisor). Quanto maior o portfólio, mais preciso ele é. ## Comparações de TCO da infraestrutura de construção As ferramentas são vitais para criar comparações de TCO de infraestrutura. [AWS Os serviços profissionais](https://aws.amazon.com/professional-services/) ou um [AWS parceiro](https://aws.amazon.com/migration/partner-solutions/) podem fornecer ajuda com todos os tipos de casos direcionais, especialmente se você planeja contratá-los para ajudar no processo mais amplo de migração. Há ferramentas disponíveis para fazer o seguinte: + Colete dados de inventário. + Colete dados de utilização. + Forneça dados precisos de benchmarking de custos de infraestrutura no estado em que se encontram. + Identifique e remova zumbis. + Faça avaliações de dimensionamento correto. + Recomende opções de compra. + Compare as opções de licenciamento de software. + Produza análises gráficas simples de fluxo de caixa. O [Migration Evaluator](https://aws.amazon.com/migration-evaluator/) from AWS é uma opção. Ele fornece todos esses recursos como um **serviço gerenciado gratuito. Você** pode solicitar o Migration Evaluator por meio de seu gerente de AWS conta ou parceiro de competência em AWS migração ou enviando [uma](https://pages.awscloud.com/Migration-Evaluator-request.html) solicitação on-line. O Migration Evaluator foi projetado especificamente como uma solução pontual para produzir comparações de TCO de tecnologia de infraestrutura e rapidamente. Principais vantagens: + Gratuito + Detecção sem agente ou configuração manual de dados de inventário onde a descoberta baseada em ferramentas é restrita + Suporte dedicado para auxiliar na implantação, configuração, coleta de dados e construção do caso base ou caso de negócios direcional + Conveniência da operação de SaaS, mas pode executar a coleta de dados inteiramente na rede do cliente para apoiar a depuração antes do carregamento no mecanismo de análise + Forte suporte para o dimensionamento correto de licenças da Microsoft + Recursos completos de exportação de dados Principais limitações: + Avalia somente servidores de arquitetura x86 (Windows e Linux) + Opções limitadas para configurar ou calibrar dados de custo de benchmark no estado em que se encontram + Sem suporte para otimização de custos de operações de modelagem + Não há suporte para modelagem de custos de migração + Não há suporte direto para criar casos de negócios além das comparações de TCO Se você decidir usar uma ferramenta comercial de descoberta para recursos de descoberta e análise de portfólio, como pilha de aplicativos e descoberta de interdependências, ela geralmente também fornecerá uma comparação de TCO da infraestrutura. Para obter orientação sobre o uso de ferramentas para descoberta e avaliação de portfólio, consulte [Avaliação da necessidade de ferramentas de descoberta](understanding-initial-assessment-data-requirements.md#discovery-tooling). Para analisar e comparar os principais recursos das ferramentas líderes de mercado, consulte Ferramentas de [migração de descoberta, planejamento e recomendação](https://aws.amazon.com/prescriptive-guidance/migration-tools/migration-discovery-tools/). ## Otimização de custos operacionais integrada A melhoria da produtividade das operações de TI geralmente contribui significativamente para as migrações. Em média, após a migração para AWS, a produtividade da equipe operacional de TI aumenta em 62% por meio da migração, de acordo com o whitepaper da International Data Corporation (IDC) [Fostering Business and Organizational Transformation to Generate Business Value with Amazon Web Services](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-BV%20IDC%202018.pdf?aliId=1614258770). No entanto, existem dois desafios com o dimensionamento e a inclusão desses benefícios no caso direcional. Primeiro, avaliar toda a gama de ganhos de produtividade requer uma ampla coleta de dados e é mais apropriada para o [caso comercial detalhado](detailed-business-case.md). Esse desafio pode ser resolvido concentrando-se em alguns elementos que são mais facilmente avaliados e dimensionados com dados de referência simples, mas que ainda mostram uma vantagem significativa. Em segundo lugar, focar na produtividade como fonte de redução de custos pode gerar preocupação e negatividade entre as principais partes interessadas do cliente e os membros do programa. Certifique-se de fornecer clareza sobre como o benefício será obtido e o que isso significa para as pessoas afetadas. Esses problemas podem ser evitados esclarecendo que isso só melhorará as funções da equipe: + O programa de migração inclui um caminho para desenvolver e transferir a equipe de operações internas para novas funções, como unir DevSecOps equipes, criar infraestrutura como automações de código e automações de teste que impulsionarão o crescimento da equipe. + O benefício pode ser obtido redefinindo o escopo e redimensionando contratos de terceirização de operações, para que a equipe interna possa aumentar seu foco em atividades de maior valor. Abordagem da construção desse elemento de caso de negócios com base nas transformações operacionais que você deseja considerar: + Se você já tiver uma equipe de operações interna, aprimore as habilidades dos membros da equipe e mostre a melhoria de produtividade esperada. + Como alternativa, migre de sua solução de operações atual para AWS Managed Services (AMS) ou para uma oferta alternativa de serviços gerenciados de um AWS parceiro. Para a primeira transformação, para obter uma estimativa financeira conservadora da melhoria da produtividade que pode ser incluída no caso, recomendamos o seguinte: 1. Concentre-se especificamente na produtividade das operações de gerenciamento de servidores. Ela tende a ser uma proporção significativa do esforço operacional, pode ser avaliada com mais facilidade e é mais facilmente verificada posteriormente. 1. Calcule a equipe necessária com base nos benchmarks do número de servidores que podem ser gerenciados por cada funcionário equivalente em tempo integral (FTE). No local, esse número é de cerca de 150 servidores. AWS Ativado, são cerca de 400 servidores. 1. Aplique essas métricas ao número de servidores locais em comparação com o número de instâncias do EC2. 1. Multiplique o tempo economizado com uma taxa de custo combinada para toda a equipe de operações. Em seguida, você pode verificar seus resultados com qualquer uma das abordagens, verificando se o resultado não excede em muito os ganhos médios de produtividade por função fornecidos na tabela a seguir (dados provenientes do whitepaper da IDC [Fostering Business and Organizational Transformation to Generate Business Value with](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-BV%20IDC%202018.pdf?aliId=1614258770) Amazon Web Services). | **Perfil** | **Ganho de eficiência** | | --- |--- | | Gerenciamento da infraestrutura de TI | 62% | | Suporte de TI | 59% | | Gerenciamento de aplicações | 43% | | Gerenciamento de banco de dados | 19% | | Desenvolvimento de aplicações | 25% | Para a segunda transformação, você pode adicionar a economia de custos operacionais comparando diretamente o custo total atual de operações e suporte do portfólio dentro do escopo com o custo do serviço gerenciado que está sendo considerado. Para obter o custo do serviço gerenciado, forneça a seu gerente de AWS conta ou a qualquer [AWS Managed Services parceiro](https://aws.amazon.com/managed-services/partners/) sua AWS lista de materiais proposta, sua escolha de nível de serviço (Plus ou Premium) e seu pacote AMS (AMS Accelerate ou AMS Advanced). Isso fornecerá a você um custo total de serviços gerenciados para os:AWS service (Serviço da AWS) componentes da solução transformada. Da mesma forma, você pode obter preços de um AWS parceiro que ofereça seu próprio pacote de serviços gerenciados com base em seus próprios parâmetros. ## Expandindo para um caso de negócios totalmente direcional Em geral, para montar um caso de negócios direcional completo, crie a comparação do TCO, com ou sem o elemento de produtividade de TI, e estime todos os custos de migração e modernização. Em seguida, crie um fluxo de caixa que abranja pares de cenários migrate-and-modernize e t-migrate-and-modernize cenários inativos. O caso mais básico é a preparação de um único par de cenários, em que o t-migrate-and-modernize cenário de não fazer é sua situação atual e o migrate-and-modernize cenário tem as seguintes características: + Sem crescimento ou redução no volume transacional, na computação ou na capacidade de rede + Crescimento constante de baixo volume nos requisitos de armazenamento + Quality-of-service capacidades (como disponibilidade, durabilidade, produtividade e desempenho) que correspondem às capacidades do sistema existente Para todos os portfólios, exceto portfólios muito pequenos, isso se encaixa bem nos objetivos de criar uma caixa direcional. Ele demonstra valor suficiente rapidamente para obter o mandato de seguir em frente. Para portfólios menores, pode ser útil adicionar pares de migrate-and-modernize t-migrate-and-modernize cenários que demonstrem outros aspectos do aumento do valor da migração para a nuvem, como: + Uma combinação de requisitos de crescimento de capacidade moderada e alta em todas as cargas de trabalho onde esse crescimento é esperado + Inclusão de resiliência aprimorada, como alta disponibilidade, DR e tolerância a falhas + Desempenho global aprimorado com computação de ponta, rede de entrega de conteúdo (CDN) e replicação de banco de dados em várias regiões. + Qualquer outra qualidade de serviço específica aprimorada que você tenha priorizado de negócios para o programa Para esses cenários, certifique-se de que os custos e as implicações de fluxo de caixa da atualização da arquitetura atual de infraestrutura que não seja de nuvem para corresponder à nova especificação sejam estimados com precisão. A maneira mais direta de obter essa estimativa pode ser solicitando uma cotação de um integrador de sistemas, especialmente se ele também for um parceiro de AWS consultoria com competência em migração, que pode ajudá-lo tanto nos cenários migrate-and-modernize quanto nos cenários em que não há necessidade. t-migrate-and-modernize Para cada par de cenários, monte um estojo que inclua o seguinte: + Os custos do t-migrate-and-modernize cenário de não fazer. No caso mais básico, isso inclui: + O custo total de propriedade durante o período do business case para a configuração atual da infraestrutura + Aumentos periódicos no consumo de computação, armazenamento e tráfego de rede + Os custos do cenário migrate-and-modernize;, incluindo: + Configurar o programa, que inclui descoberta detalhada, planejamento de migração, desenvolvimento detalhado de casos de negócios, estabelecimento da equipe principal e aprimoramento da equipe, estabelecimento de uma landing zone, se ainda não estiver em vigor, e estabelecimento de gerenciamento de segurança e integração de operações para cargas de trabalho migradas + Os custos de migração e modernização da carga de trabalho + Os custos da infraestrutura de migração, incluindo conexões de rede, serviços de migração de dados [AWS DataSync](https://aws.amazon.com/datasync/), como [AWS Snowball Edge](https://aws.amazon.com/snowball/)e, e os custos de serviços AWS públicos da arquitetura necessária durante o próprio processo de migração (por exemplo, para testes) + O aumento dos custos de AWS serviços públicos ao longo da migração, à medida que as ondas entram em operação, e a redução dos custos de infraestrutura existentes à medida que ela é substituída por serviços AWS baseados e desativada + Os custos de descomissionamento e as baixas de quaisquer ativos perdidos ## Estimando a configuração do programa de migração e modernização Para configurar um programa para o sucesso, talvez seja necessário realizar uma série de atividades fundamentais para criar recursos básicos e o plano detalhado, caso isso não tenha sido feito antes. Essas atividades fundamentais incluem o seguinte: 1. Realizar a descoberta detalhada do portfólio, o planejamento da migração e o desenvolvimento detalhado do caso de negócios, conforme descrito na seção [Análise de portfólio e planejamento da migração](portfolio-analysis-migration-planning.md), além da documentação do custo de qualquer ferramenta de descoberta usada. 1. Estabelecer uma equipe central técnica e comercial na nuvem e desenvolver habilidades internas por meio de treinamento e contratação. Identifique os membros da organização de TI que precisarão de treinamento e aloque um orçamento de treinamento para cada pessoa. 1. Estabelecer uma [landing zone](https://aws.amazon.com/solutions/implementations/aws-landing-zone/) e configurá-la para suportar os recursos de governança de custos, operacionais e de segurança de que você precisará. AWS Os parceiros de consultoria podem ajudar a fornecer estimativas para os itens 1 e 3. *Estimando os custos de migração e modernização* Para atingir os objetivos de um caso de negócios direcional e demonstrar potencial comercial *suficiente* para avançar para a próxima fase, mantenha a estimativa de custos de migração e modernização o mais básica possível. Para isso, recomendamos que você prepare o caso de negócios direcional concentrando-se nos aplicativos que se enquadram nas seguintes estratégias de migração: + Retirada + Reter + Realocar + Redefinir a hospedagem + Redefinir a plataforma + Recompra Normalmente, cerca de 70% das cargas de trabalho podem ser rehospedadas, realocadas ou reformuladas, e outros 5% podem ser retirados. A avaliação dos aplicativos por estratégia de migração geralmente aborda o cerne do caso de redução de custos. **Estimar os custos de refatoração ou rearquitetura pode ser complexo.** Não é prático tentar fazer isso dentro do prazo estabelecido para preparar um caso de negócios direcional. Conforme discutido anteriormente em [Determinando o tipo R para a migração](prioritization-and-migration-strategy.md#migration-r-type), considere o uso de estratégias de rehospedagem, realocação ou replataforma para sua primeira fase de migração e modernização. Essas estratégias de R provavelmente acelerarão o retorno inicial, reduzirão o risco de implementação e melhorarão o caso de negócios no curto prazo. Também é materialmente mais fácil para suas equipes de aplicativos modernizar os aplicativos que estão sendo executados no AWS ambiente do que aqueles que não estão. As estimativas para refatorar (rearquitetar) aplicativos específicos são melhor adicionadas quando o caso de negócios [detalhado](detailed-business-case.md) é preparado. *Estimando o esforço de migração por estratégia* Cada migração é diferente. Antes de comprometer qualquer orçamento ou plano, semeie as estimativas de carga de trabalho para as atividades de migração da equipe que será responsável pelo projeto, seja sua equipe interna de aplicativos, serviços AWS profissionais ou uma organização parceira. AWS Para ajudar a criar o caso direcional, a tabela a seguir fornece faixas indicativas de esforço para os diferentes tratamentos. Esses intervalos pressupõem que um medium-to-large portfólio esteja sendo migrado e que a equipe de migração seja treinada e experiente. Para portfólios pequenos, é melhor que a equipe responsável pela migração prepare a estimativa mesmo para um caso direcional. | Estratégia de migração | Processo de estimativa | Elementos | Horas pessoais | Horas pessoais | | --- |--- |--- |--- |--- | | Reter | Não faça nada, sem custos, sem benefícios e sem redução na dívida de tecnologia. | – | – | – | | Retirada | Estime o descomissionamento do equipamento de hardware usado, se houver. | – | – | – | | Realocar | Estime a cópia da carga de trabalho VMware usando VMware ferramentas. Isso inclui copiar os dados, testar a fumaça para verificar e qualquer descomissionamento de hardware. O esforço de realocação geralmente VMs é menor do que para padrões de rehospedagem de baixa complexidade. | – | – | – | | Redefinir a hospedagem | Faça uma estimativa da cópia da carga de trabalho e dos dados com uma cópia de imagem, testes de fumaça, testes de alta disponibilidade (HA) e recuperação de desastres (DR), quando apropriado, para servidores de produção e qualquer descomissionamento de hardware. A melhor prática é usar ferramentas como [AWS Application Migration Service](https://aws.amazon.com/application-migration-service/). Divida as cargas de trabalho em baixa, média e alta complexidade, com base em fatores como se um banco de dados ou outro software de infraestrutura está em execução, complexidade do banco de dados, se está em cluster, complexidade de integração e volumes de dados. | Esforço por aplicativo por servidor | Migração | Teste HA/DR | | Baixo | 10—14 | 3—5 | | Médio | 16—24 | 4—6 | | Alto | 26—38 | 8—12 | | Redefinir a plataforma | Para migrações de replataforma que incluam atualizações do sistema operacional ou da versão do RDBMS, faça a estimativa de uma nova hospedagem e reserve tempo para executar um teste de reconstrução e fumaça na nova plataforma. Se a replataforma incluir a alteração da tecnologia da plataforma, estime o tempo adicional para o uso das ferramentas de conversão, como e, e um teste de aplicativo mais completo. [AWS Schema Conversion Tool[AWS Database Migration Service](https://aws.amazon.com/dms/)](https://aws.amazon.com/dms/schema-conversion-tool/) Um exemplo de mudança na tecnologia é migrar de um banco de dados comercial proprietário para um substituto de código aberto. | Esforço por aplicativo por servidor | Versão ativa | Mudança tecnológica | | Baixo | Adicione 1—3 | Adicionar 10—15 | | Médio | Adicione 2—5 | Adicione 20—30 | | Alto | Adicionar 4—8 | Adicionar 40—60 | | Recompra | Faça uma estimativa da extração, transformação e upload de dados para a substituição do serviço SaaS recém-adquirido e qualquer descomissionamento de hardware. | – | – | – | *Estimando os custos da infraestrutura de migração* Inclua estimativas para a infraestrutura que você usará durante a migração. Normalmente, essas estimativas incluem: + Um orçamento para serviços de conectividade e troca de dados para carga de trabalho e migração de dados do ambiente atual para AWS + Um orçamento para o Serviços da AWS (especialmente computação e armazenamento) necessário para hospedar as cargas de trabalho migradas durante os processos de migração, teste e substituição + O aumento dos custos de AWS serviços públicos à medida que cada onda de migração é concluída + Os custos de descomissionamento da infraestrutura existente que não executará mais as cargas de trabalho migradas Para troca de dados, examine seus volumes totais de dados e avalie a viabilidade de usar a rede. Se você tiver provisionado um [AWS Direct Connect](https://aws.amazon.com/directconnect/)link ou [Site-to-Site VPN](https://aws.amazon.com/vpn/)de AWS até um ponto na sua WAN com antecedência para uso operacional após a migração, poderá usar esse recurso até sua cota de serviço. Se a capacidade da sua rede for insuficiente, um aumento de curto prazo na largura de banda da Internet com uma rede privada virtual (VPN) geralmente é uma solução altamente econômica. Caso contrário, dispositivos de troca de AWS mídia, como [AWS Snowball Edge](https://aws.amazon.com/snowball/)e [AWS Snowball Edge](https://aws.amazon.com/snowcone/)oferecem soluções na maioria Regiões da AWS. Além disso, para migrações de dados de volume muito alto, considere incluir um orçamento para [AWS DataSync](https://aws.amazon.com/datasync/), o que melhora a confiabilidade e pode acelerar as transferências, independentemente da mídia usada. Modelar o aumento dos AWS serviços e a redução da infraestrutura existente é importante para o elemento de análise do fluxo de caixa do business case. Nesse estágio, é improvável que você tenha um plano de ondas para determinar exatamente quando os custos serão incorridos. Recomendamos o seguinte: + Aumentando os custos a uma AWS taxa constante durante a migração. + Reduzindo os custos da infraestrutura existente que você planeja descomissionar a uma taxa constante durante o mesmo período. AWS Iniciar o aumento de custos de 1 a 2 meses antes da redução da infraestrutura existente. Isso fornece 1 mês de uso do AWS utilitário para conduzir a migração para cada onda. Inclui tempo para testes e tempo adicional para concluir o trabalho de descomissionamento necessário para parar de incorrer em custos na infraestrutura substituída. *Estimando os custos de descomissionamento* Descomissionar equipamentos que não podem ser reimplantados e descartá-los de forma legal e ecológica podem incorrer em alguns pequenos custos. No entanto, para um caso comercial direcional, normalmente a única soma potencialmente material é o custo de amortizar qualquer valor contábil restante dos ativos substituídos. Para o caso comercial direcional, recomendamos que você faça o seguinte: + Revise sua lista de ativos. + Identifique aqueles que seriam desativados. + Para reduzir a baixa, examine as oportunidades de trocar dispositivos para que os dispositivos mais novos da lista possam ser usados para substituir ativos mais antigos e mais totalmente depreciados. + Faça uma avaliação do valor contábil futuro dos ativos que seriam desativados naquele momento. + Inclua isso como o custo de migração do descomissionamento. *Montagem e ajuste do business case direcional completo* Depois de preparar o conjunto completo de custos para cada par de cenários, crie uma demonstração do fluxo de caixa com desconto para cada um e faça um gráfico deles. Recomendamos criar casos de negócios direcionais no mesmo período do ciclo de atualização do hardware. Isso normalmente leva 5 anos para servidores, armazenamento e dispositivos de rede. Quando você usa o mesmo período do ciclo de atualização de hardware, os custos de exatamente uma atualização são incluídos nos custos atuais de cada cenário. Em seguida, calcule as principais métricas financeiras necessárias para obter aprovação e passar para a próxima fase do programa. Geralmente incluímos o seguinte: + O valor presente líquido (VPL) para medir o valor absoluto das reduções de custos e ganhos de produtividade avaliados + O período de reembolso em meses para verificar se os retornos são suficientemente rápidos + A comparação final da taxa de execução para verificar se o processo está reduzindo custos suficientes ao longo do prazo + O retorno sobre o investimento (ROI) e a taxa de retorno do investimento modificada (MIRR) para avaliar o desempenho financeiro relativo do programa em relação a outras demandas de capital que sua organização pode estar priorizando Use a primeira iteração do caso para determinar se o desempenho financeiro esperado significa que refinamentos devem ser feitos, como nos exemplos a seguir: + Se o retorno for muito lento, considere opções para acelerar e reduzir o custo da migração, como as seguintes: + Use AWS parceiros ou serviços AWS profissionais para expandir os recursos disponíveis e paralelizar ainda mais a migração de cargas de trabalho com padrões mais básicos. + Para cargas de trabalho em execução VMware, compare a estratégia de realocação com a estratégia de rehospedagem ou replataforma, pelo menos na fase inicial. Usar a estratégia de realocação pode reduzir o custo da migração e aumentar a velocidade da migração. + Onde for tecnicamente viável, coloque cargas de trabalho que exijam estratégias mais complexas de replataforma ou refatoração (rearquitetura) para uma fase futura, fora do escopo do caso comercial inicial. + Se o ROI e o MIRR forem muito baixos, considere o seguinte: + Os cenários que você está considerando são muito conservadores? Você tem um cenário que reflete as necessidades mais prováveis de crescimento de capacidade e elasticidade? Você tem cenários que comparam os custos, incluindo os aumentos na qualidade do serviço dentro de seus objetivos? + Você pode refinar o escopo do portfólio de aplicativos a ser migrado na primeira fase para se concentrar em cargas de trabalho que produzirão retornos mais fortes, como aquelas com menor utilização atual ou necessidades caras de recuperação de desastres (DR)? + É possível refinar o escopo do portfólio de aplicativos para excluir inicialmente cargas de trabalho específicas que produzem menos resultados comerciais? Por exemplo, você pode adiar cargas de trabalho para as quais as licenças de software de terceiros se tornam mais caras devido aos diferentes termos de implantação na infraestrutura de nuvem pública? + Se a comparação final da taxa de execução não atingir a meta esperada, explore o seguinte: + Primeiro, confirme se as outras métricas atendem às expectativas. O caso comercial direcional serve principalmente para mostrar que há oportunidades financeiras suficientes para justificar o início da próxima fase de preparação da migração. + Identifique uma lista das oportunidades para continuar melhorando o desempenho de custos AWS após a fase inicial da migração. Inclua uma avaliação da lista de oportunidades ao preparar o caso comercial detalhado. Além disso, inclua uma avaliação de oportunidades na manutenção contínua do caso e no processo de month-to-month otimização de custos após a conclusão da migração.