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, análise de portfólio e planejamento de migração.

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 operações de entrada/saída 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 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 utilização máxima de CPU e 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 ou um AWS parceiro 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 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 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. Para analisar e comparar os principais recursos das ferramentas líderes de mercado, consulte Ferramentas de migração de descoberta, planejamento e recomendação.

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. 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. 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.

2. 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.

3. Aplique essas métricas ao número de servidores locais em comparação com o número de EC2 instâncias.

4. 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 abordagem, 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 Amazon Web Services).

Função	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 sua AWS lista de materiais proposta, sua opção 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 de não fazer. 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, como AWS Snowball Edgee, 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, além da documentação do custo de qualquer ferramenta de descoberta usada.

2. 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.

3. Estabelecer uma 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, 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 é 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 dentro do VMware uso de 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. 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 ToolAWS Database Migration Service 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 Connectlink ou AWS VPNde 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 Edgee AWS Snowball Edgeoferecem 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, 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.