

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

# Práticas recomendadas para grandes migrações
<a name="best-practices"></a>

Grandes migrações podem se tornar desafiadoras, dependendo dos fatores que governam o funcionamento de uma organização. Esta seção aborda alguns dos principais fatores que podem simplificar grandes migrações se abordados durante as fases iniciais do esforço e monitorados durante todo o projeto.

As práticas recomendadas a seguir para grandes migrações são baseadas em dados capturados de outros clientes. As melhores práticas são divididas em três categorias:
+ Pessoas
+ Tecnologia
+ Processos

# Perspectiva das pessoas
<a name="people"></a>

Esta seção se concentra nas seguintes áreas principais da perspectiva das pessoas:
+ Suporte executivo — Identificação de um líder unidirecional que tenha o poder de tomar decisões
+ Colaboração e propriedade da equipe — Colaboração entre várias equipes
+ Treinamento — Treinamento proativo de equipes nas várias ferramentas

## Suporte executivo
<a name="executive"></a>

**Contents**
+ [Identifique um líder com uma única linha](#leader)
+ [Alinhe a equipe de liderança sênior](#align-leadership)

### Identifique um líder com uma única linha
<a name="leader"></a>

Ao iniciar uma grande migração, é importante identificar um líder técnico único que seja 100% dedicado ao projeto e responsável. Esse líder tem o poder de tomar decisões, ajudar a evitar silos e simplificar os fluxos de trabalho, mantendo prioridades consistentes.

Um grande cliente global de migração conseguiu escalar de um servidor por semana no início do programa para mais de 80 servidores por semana no início do segundo mês. O suporte total do CIO como líder unidirecional foi fundamental para a rápida expansão dos servidores que estavam sendo migrados. O CIO atendeu a chamadas semanais de transição de migração com a equipe de migração para garantir o escalonamento e a resolução de problemas em tempo real, o que acelerou a velocidade da migração.

### Alinhe a equipe de liderança sênior
<a name="align-leadership"></a>

É importante criar um alinhamento entre as várias equipes em relação aos critérios de sucesso da migração. Embora o planejamento e a implementação da migração possam ser realizados por uma equipe pequena e dedicada, surgem desafios ao definir a estratégia e realizar atividades periféricas. Esses possíveis obstáculos podem exigir ações ou escalonamentos de diferentes áreas da organização de TI, incluindo o seguinte:
+ Negócios
+ Aplicativos
+ Redes
+ Segurança
+ Infraestrutura
+ Fornecedores terceirizados

A ação direta dos proprietários do aplicativo, a liderança, o alinhamento e uma clara escalação para o líder unidirecional tornam-se importantes.

## Colaboração e propriedade da equipe
<a name="team"></a>

**Contents**
+ [Crie uma equipe multifuncional de capacitação em nuvem](#cross-function)
+ [Defina com antecedência os requisitos para equipes e indivíduos fora da equipe principal de migração](#define-reqs)
+ [Verifique se não há problemas de licenciamento ao migrar cargas de trabalho](#licensing)

### Crie uma equipe multifuncional de capacitação em nuvem
<a name="cross-function"></a>

**Contents**

Uma primeira etapa crítica em um grande projeto de migração é permitir que a organização trabalhe na nuvem. Para fazer isso, recomendamos criar um [Cloud Enablement Engine](https://d1.awsstatic.com/whitepapers/cloud-enablement-engine-practical-guide.pdf) (CEE). A CEE é uma equipe capacitada e responsável, focada na prontidão operacional da organização para migrações para. AWS O CEE deve ser uma equipe multifuncional que inclua representação de infraestrutura, aplicativos, operações e segurança. A equipe é encarregada das seguintes responsabilidades:
+ Políticas de desenvolvimento
+ Definir e implementar ferramentas, processos e arquiteturas que estabelecerão o modelo de operações em nuvem da organização
+ Continuando a facilitar o alinhamento das partes interessadas em todas as áreas que elas representam

Um cliente do setor de saúde não começou com um CEE. No entanto, por meio de migrações piloto iniciais, a lacuna foi identificada. *Antes da data final de transição da migração, com prazos rigorosos em vigor, a equipe implementou uma sala de guerra migratória.* Na sala de guerra de migração, as partes interessadas da infraestrutura, segurança, aplicativos e negócios poderiam ajudar na resolução de problemas.

### Defina com antecedência os requisitos para equipes e indivíduos fora da equipe principal de migração
<a name="define-reqs"></a>

Identifique equipes e indivíduos que estão fora do programa principal e defina seu envolvimento durante as fases de planejamento da migração. Para facilitar a dinâmica da migração durante os estágios posteriores, preste atenção específica ao envolvimento das equipes de aplicativos. Será necessário que eles conheçam a aplicação, a capacidade de diagnosticar problemas e a necessidade de aprovar a transição.

Embora a migração seja liderada por uma equipe principal, as equipes de aplicativos provavelmente estarão envolvidas na validação do plano de migração e nos testes durante a transição. Os clientes geralmente abordam a migração para a nuvem como um projeto de infraestrutura, em vez de uma migração de aplicativos. Isso pode causar problemas durante a migração.

Recomendamos considerar o envolvimento necessário da equipe de aplicativos ao selecionar uma estratégia de migração. Por exemplo, uma estratégia de rehospedagem exige menos envolvimento da equipe de aplicativos em comparação com uma estratégia de replataforma ou refatoração na qual mais do cenário de aplicativos está sendo alterado. Se a disponibilidade do proprietário do aplicativo for limitada, considere usar a rehospedagem ou a replataforma em vez das estratégias de refatoração, realocação ou recompra.

### Verifique se não há problemas de licenciamento ao migrar cargas de trabalho
<a name="licensing"></a>

O licenciamento pode mudar quando você migra produtos corporativos prontos para uso para a nuvem. Seus contratos de licença podem se concentrar em sua propriedade local. Por exemplo, uma licença pode ser por CPU ou vinculada a um endereço MAC específico. Como alternativa, os contratos de licença podem não incluir o direito de hospedar em um ambiente de nuvem pública. No entanto, a renegociação do licenciamento com fornecedores pode incluir prazos de entrega longos e dificultar a migração.

Recomendamos colaborar com suas equipes de fornecimento ou gerenciamento de fornecedores assim que o escopo da migração for definido. O licenciamento também pode influenciar a arquitetura de destino e os padrões de migração.

## Treinamento
<a name="training"></a>

**Contents**
+ [Treine equipes em novas ferramentas e processos](#tools-training)

### Treine equipes em novas ferramentas e processos
<a name="tools-training"></a>

Depois que a estratégia de migração for definida, invista tempo em entender qual treinamento pode ser necessário para a migração e para seu modelo operacional de destino. Durante a migração, você provavelmente usará ferramentas AWS Database Migration Service, como as que são novas em sua organização. O treinamento proativo das equipes reduz os atrasos ocorridos durante as fases de migração.

Recomendamos buscar métodos ativos de transferência de conhecimento que ofereçam a oportunidade de experimentar as ferramentas de forma prática. Como exemplo, a AWS Professional Services forneceu várias sessões de treinamento do Cloud Migration Factory para três AWS parceiros integradores de sistemas (SI) responsáveis por uma grande migração. Isso garantiu que a equipe tivesse familiaridade básica à medida que entrava na fase de migração. Também ajudou a identificar especialistas no assunto (SMEs) que poderiam atuar como escalonadores de primeira linha em cada equipe do SI AWS Partner.

# Perspectiva da tecnologia
<a name="technology"></a>

A tecnologia fornece uma excelente base para acelerar grandes migrações. Por exemplo, a solução Cloud Migration Factory está focada em como fornecer end-to-end automação para migrações. Esta seção explora algumas das melhores práticas para usar a tecnologia para alcançar a escala e a velocidade necessárias, alinhadas com o escopo, a estratégia e os cronogramas.

O princípio geral é examinar as áreas de automação sempre que possível. Se você tiver milhares de servidores no escopo, realizar tarefas manualmente pode ser um esforço caro e demorado.

Para realizar uma migração, normalmente são usadas várias ferramentas, como as seguintes:
+ Descoberta
+ Implantação da migração
+ Banco de dados de gerenciamento de configuração (CMDB)
+ Planilha de inventário
+ Gerenciamento de projetos

Essas ferramentas são usadas em diferentes estágios das migrações, desde a avaliação até a mobilização até a implementação. A seleção dessas ferramentas é orientada pelos objetivos e cronogramas de negócios.

Depois que as fases de migração forem planejadas, a próxima etapa é garantir que a equipe de migração tenha as habilidades necessárias para usar as ferramentas necessárias. Se uma equipe não tiver as habilidades ou a experiência, planeje treinamentos direcionados para aumentar o conjunto de habilidades. Se possível, crie eventos em que as equipes possam obter experiência com as ferramentas de migração em um ambiente seguro. Por exemplo, existem servidores de sandpit ou de laboratório que as equipes podem migrar para experimentar com as ferramentas? Como alternativa, é aceitável que as cargas de trabalho de desenvolvimento inicial sejam usadas para fins de aprendizado?

## Automação, rastreamento e integração de ferramentas
<a name="integration"></a>

**Contents**
+ [Automatize a descoberta da migração para reduzir o tempo necessário](#discovery)
+ [Automatize tarefas repetitivas](#repeating)
+ [Automatize o rastreamento e a geração de relatórios para acelerar a tomada de decisões](#decision)
+ [Explore ferramentas que podem facilitar sua migração](#tooling)

### Automatize a descoberta da migração para reduzir o tempo necessário
<a name="discovery"></a>

A maioria dos grandes programas de migração começa entendendo o escopo da migração (o que deve ser migrado) e desenvolvendo uma estratégia (como ela será migrada). A descoberta é um aspecto importante disso. Os pontos de metadados necessários são capturados para formar uma árvore decisória da estratégia de migração. Para migrar cargas de trabalho em ritmo acelerado, você deve identificar e importar os metadados de migração necessários para seus processos de implementação, como uma fábrica de migração. Um mecanismo totalmente automatizado para extrair, transformar e carregar (ETL) os metadados de migração reduz consideravelmente o tempo e o nível de esforço envolvidos no processo de descoberta.

Um cliente desenvolveu um processo de entrada de dados totalmente automatizado para sua fábrica de migração. O plano da onda de migração com todos os metadados de migração foi hospedado e mantido em uma planilha na Microsoft. SharePoint Quando foram feitas alterações na fonte, uma AWS Lambda função foi iniciada para carregar os dados na fábrica de migração sem intervenção manual. Esse processo automatizado de entrada de dados ajudou o cliente a reduzir o trabalho manual, minimizar o erro humano e acelerar sua velocidade. Eles conseguiram migrar mais de 1.000 servidores para o. AWS

### Automatize tarefas repetitivas
<a name="repeating"></a>

Na fase de implementação da migração, muitos pequenos processos devem ser repetidos com frequência. Ao usar AWS Application Migration Service (MGN), por exemplo, você deve instalar o agente em cada servidor que esteja no escopo da migração.

Construir uma fábrica de migração que atenda às suas necessidades técnicas e comerciais específicas é a maneira mais eficaz de obter a eficiência e a velocidade necessárias para realizar uma grande migração bem-sucedida. Uma fábrica de migração fornece uma estrutura de integração e orquestração que usa um conjunto de dados padronizado para acelerar a migração. Depois que todas as tarefas forem identificadas, dedique algum tempo à automatização de todas as tarefas manuais que podem ser automatizadas junto com os runbooks prescritivos.

A solução [Cloud Migration Factory](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-factory-cloudendure/welcome.html) é um exemplo disso. O Cloud Migration Factory foi projetado para fornecer as bases de automação de migração sobre as quais você pode automatizar aspectos específicos da sua organização. Por exemplo, talvez você queira atualizar um sinalizador em seu CMDB para destacar que os servidores locais agora podem ser desativados. Nesse cenário, você pode criar uma automação que executa essa tarefa no final da onda de migração. O Cloud Migration Factory tem um armazenamento centralizado de metadados com todos os metadados do wave, do aplicativo e do servidor. O script de automação pode se conectar ao Cloud Migration Factory para obter uma lista de servidores nessa onda e realizar qualquer ação de acordo. Suporta o Cloud Migration Factory [AWS Application Migration Service](https://docs.aws.amazon.com/mgn/latest/ug/what-is-application-migration-service.html).

### Automatize o rastreamento e a geração de relatórios para acelerar a tomada de decisões
<a name="decision"></a>

Recomendamos criar um painel automatizado de relatórios de migração para rastrear e relatar dados ativos, incluindo os principais indicadores de desempenho (KPIs) do programa. Os projetos de migração envolvem partes interessadas de toda a organização, incluindo o seguinte:
+ Equipes de aplicação
+ Testadores
+ Equipes de descomissionamento
+ Arquitetos
+ Equipes de infraestrutura
+ Liderança

Para desempenhar suas funções, essas partes interessadas precisam de dados ativos. Por exemplo, as equipes de rede devem conhecer as próximas ondas de migração para entender o impacto na conexão compartilhada entre recursos locais e. AWS As equipes de liderança querem entender o quanto da migração foi concluída. Ter um feed de dados ao vivo confiável e automatizado evita falhas de comunicação e fornece uma base sobre a qual as decisões podem ser tomadas.

Um grande cliente da área de saúde estava trabalhando para sair do data center com um prazo próximo. Dada a escala e a complexidade, uma quantidade significativa de tempo foi inicialmente gasta no rastreamento e na comunicação do status da migração entre as partes interessadas. Posteriormente, a equipe de migração usou o [Amazon Quick Sight](https://docs.aws.amazon.com/quicksuite/latest/userguide/quick-bi.html) para criar painéis automatizados que visualizavam os dados, simplificando significativamente o rastreamento e as comunicações e aumentando a velocidade da migração.

### Explore ferramentas que podem facilitar sua migração
<a name="tooling"></a>

Escolher as ferramentas certas para sua migração não é fácil, especialmente se ninguém em sua organização já gerenciou uma grande migração antes.

Recomendamos dedicar algum tempo para escolher as ferramentas adequadas para apoiar a migração. Essa exploração pode envolver um custo de licença, mas pode oferecer um benefício de custo quando você considera a iniciativa mais ampla. Como alternativa, você pode descobrir que as ferramentas incorporadas à sua organização podem fornecer um resultado semelhante. Por exemplo, talvez você já tenha ferramentas de monitoramento de desempenho de aplicativos implantadas em sua propriedade, que podem fornecer informações valiosas de descoberta.

Inicialmente, um cliente de tecnologia relutou em executar ferramentas de descoberta automatizadas durante a migração devido à falta de familiaridade. Como resultado, um AWS parceiro de SI teve que realizar 510 horas de reuniões por aplicativo para descobrir a propriedade manualmente, incluindo nomes de servidores, versões do sistema operacional e dependências. Estimou-se que, se as ferramentas de descoberta tivessem sido usadas, o esforço de descoberta poderia ter sido reduzido em mais de 1.000 horas.

## Pré-requisitos e validação pós-migração
<a name="pre-post"></a>

**Contents**
+ [Construa a landing zone durante a fase de pré-migração](#landing-zone)
+ [Descreva as atividades de pré-requisitos](#outline)
+ [Implemente verificações pós-migração para melhoria contínua](#post-checks)

### Construa a landing zone durante a fase de pré-migração
<a name="landing-zone"></a>

Recomendamos criar o ambiente de AWS destino, ou landing zone, com antecedência, em vez de criar as nuvens privadas virtuais (VPCs) e sub-redes de destino durante a onda de migração. Construir uma landing zone bem arquitetada é um pré-requisito para a migração. A landing zone deve incluir monitoramento, governança, controles operacionais e de segurança.

Construir e validar a landing zone antes da migração minimiza a incerteza resultante da execução de suas cargas de trabalho em um novo ambiente. Com a landing zone estabelecida, as partes interessadas podem se concentrar na migração das cargas de trabalho sem se preocupar com aspectos gerenciados em nível de conta ou VPC.

### Descreva as atividades de pré-requisitos
<a name="outline"></a>

Além da landing zone, é importante alinhar outros pré-requisitos técnicos antes da migração, especialmente processos com prazos de entrega longos. Por exemplo, faça as alterações necessárias no firewall para permitir que os dados sejam replicados do local para o. AWS A comunicação antecipada dos pré-requisitos técnicos ajuda a preparar e alocar os recursos necessários. É comum que as migrações parem porque os pré-requisitos não foram atendidos. Isso não afeta apenas a onda de migração em andamento, mas também pode atrasar as datas de todas as migrações futuras enquanto o problema está sendo corrigido.

Uma empresa de serviços financeiros pretendia realizar uma migração em massa para AWS, com o objetivo de desocupar vários data centers. No entanto, sua largura de banda estava disponível entre locais e não AWS era suficiente para a velocidade pretendida. Infelizmente, o aumento da largura de banda exigiu uma nova conexão e teve um prazo de entrega de três meses. Isso significou que a velocidade de migração foi restringida nos primeiros três meses.

### Implemente verificações pós-migração para melhoria contínua
<a name="post-checks"></a>

Por fim, lembre-se de implementar validações pós-migração, como integração de operações, otimização de custos e verificações de governança e conformidade. A validação pós-migração inclui a avaliação de cargas de trabalho migradas anteriormente para descobrir as lições técnicas aprendidas que devem ser aplicadas às futuras ondas.

Além disso, essa é uma ótima oportunidade para implementar operações de controle de custos. Por exemplo, durante a migração, você pode decidir combinar o tamanho das AWS instâncias com sua propriedade local para reduzir a necessidade de testes de desempenho. Agora que os testes não estão mais no caminho crítico para o fechamento do data center, você pode usar CloudWatch a Amazon para avaliar a utilização da instância e determinar se uma instância menor seria adequada.

Para ilustrar a importância dessa fase, um grande cliente de tecnologia estava realizando uma grande migração, mas inicialmente não incluiu validações pós-migração. Depois de migrar mais de 100 servidores, eles identificaram que o AWS Systems Manager Agente (Agente SSM) não estava configurado corretamente. Todos os servidores migrados anteriormente tiveram que ser corrigidos, e a migração foi paralisada. O cliente também identificou que as instâncias eram cinco vezes maiores que as estimativas iniciais, então implementou um ponto de verificação de custos no final de cada onda de migração.

# Perspectiva do processo
<a name="process"></a>

Os processos trazem consistência, mas também evoluem e são suscetíveis a mudanças porque cada projeto é único. Ao executar o processo repetidamente, você identificará lacunas e espaço para melhorias que podem resultar em enormes benefícios à medida que você falha, aprende, adota e repete. Essas mudanças podem levar a novas ideias ou inovações que o projeto e a empresa podem aproveitar no futuro, o que fornece um catalisador de crescimento que traz qualidade e confiança à equipe.

Os processos nas migrações podem ser complexos, pois cruzam tecnologias e fronteiras que talvez não tenham sido vinculadas anteriormente. Essa perspectiva fornece processos e orientações sobre requisitos específicos para grandes migrações.

## Preparando-se para sua grande migração
<a name="prepare"></a>

As seções a seguir descrevem os princípios fundamentais necessários para garantir que você inicie sua jornada de migração com uma orientação clara e a adesão das partes interessadas, o que será fundamental para seu sucesso.

**Contents**
+ [Defina os fatores de negócios e comunique o cronograma, o escopo e a estratégia](#bus-drivers)
+ [Defina um caminho de escalonamento claro para ajudar a remover os bloqueadores](#escalation)
+ [Minimize mudanças desnecessárias](#change)
+ [Documente e end-to-end processe com antecedência](#end-to-end)
+ [Documente padrões e artefatos de migração padrão](#artifacts)
+ [Estabeleça uma única fonte confiável para metadados e status da migração](#metadata)

### Defina os fatores de negócios e comunique o cronograma, o escopo e a estratégia
<a name="bus-drivers"></a>

Ao abordar uma grande migração para AWS, você descobrirá rapidamente que existem várias maneiras de migrar seus servidores. Por exemplo, você pode fazer o seguinte:
+ Hospede novamente as cargas de trabalho usando o. [AWS Application Migration Service](https://docs.aws.amazon.com/mgn/latest/ug/what-is-application-migration-service.html)
+ Containerize seu aplicativo e hospede-o na plataforma de [contêiner gerenciada Amazon Elastic Container Service](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html) (Amazon ECS) ou [Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) (Amazon EKS).
+ Redesenhe sua carga de trabalho em um aplicativo totalmente sem servidor.

Para determinar o caminho correto de migração, é importante trabalhar de trás para frente com seus impulsionadores de negócios. Se seu objetivo final é aumentar a agilidade nos negócios, você pode preferir os dois segundos padrões, que envolvem mais níveis de transformação. Se sua meta é desocupar um data center até o final do ano, você pode optar por rehospedar as cargas de trabalho devido à velocidade que a nova hospedagem oferece.

Uma grande migração normalmente envolve uma grande variedade de partes interessadas, incluindo as seguintes:
+ Proprietários da aplicação
+ Equipes de rede
+ Administradores de banco de dados
+ Patrocinadores executivos

É fundamental identificar os impulsionadores comerciais da migração e incluir essa lista em um documento, como uma carta de projeto que os membros do programa de migração possam acessar. Além disso, crie indicadores-chave de desempenho (KPIs) que se alinhem estreitamente aos resultados comerciais desejados.

Por exemplo, um cliente queria migrar 2.000 servidores em 12 meses para atingir o resultado comercial desejado de desocupar seu data center. No entanto, suas equipes de segurança não estavam alinhadas com esse objetivo. O resultado foram vários meses de debates técnicos sobre a possibilidade de perder a data de fechamento do data center, mas modernizar ainda mais os aplicativos ou rehospedá-los inicialmente para permitir o fechamento oportuno do data center e, em seguida, modernizar os aplicativos. AWS

### Defina um caminho de escalonamento claro para ajudar a remover os bloqueadores
<a name="escalation"></a>

Os grandes programas de migração para a nuvem geralmente envolvem uma grande variedade de partes interessadas. Afinal, você está potencialmente alterando aplicativos que foram hospedados no local por várias décadas. É comum que cada uma das partes interessadas tenha prioridades conflitantes.

Embora todas as prioridades possam gerar valor, o programa provavelmente terá um orçamento limitado e um resultado alvo definido. Gerenciar as várias partes interessadas e focar nos resultados comerciais desejados pode ser um desafio. Esse desafio é agravado quando você o multiplica pelas centenas ou milhares de aplicativos que estão no escopo da migração. Além disso, as partes interessadas provavelmente se reportam a diferentes equipes de liderança, que têm outras prioridades. Com isso em mente, além de documentar claramente os resultados comerciais desejados, é importante definir uma matriz de escalonamento clara para ajudar a remover os bloqueios. Isso pode economizar uma quantidade significativa de tempo e ajudar a alinhar as várias equipes em direção a um objetivo comum.

Um exemplo que demonstra isso é uma empresa de serviços financeiros cuja meta era desocupar seu data center principal em 12 meses. Não havia um mandato claro ou um caminho de escalonamento, o que resultou na elaboração dos caminhos de migração desejados pelas partes interessadas, independentemente das restrições de tempo e orçamento. Após uma escalação para o CIO, um mandato claro foi definido e um mecanismo foi fornecido para solicitar as decisões necessárias.

### Minimize mudanças desnecessárias
<a name="change"></a>

Mudar é bom, mas mais mudanças significam mais riscos. Quando o caso comercial da grande migração é aprovado, é provável que haja um resultado comercial alvo impulsionando essa iniciativa, como desocupar um data center em uma data específica. Embora seja comum que os tecnólogos queiram reescrever tudo para aproveitar ao máximo AWS os serviços, essa pode não ser sua meta comercial.

Um cliente se concentrou em uma migração de dois anos de toda a infraestrutura de escala web da empresa para o. AWS Eles criaram uma regra de duas semanas como mecanismo para evitar que as equipes de aplicativos passassem meses reescrevendo seus aplicativos. Ao usar a regra de duas semanas, o cliente conseguiu sustentar uma migração de longo prazo com uma cadência consistente quando centenas de aplicativos precisavam ser movidos em um período de vários anos. Para obter mais informações, consulte a postagem do blog [A regra das duas semanas: refatore seus aplicativos para a nuvem em 10 dias](https://aws.amazon.com/blogs/enterprise-strategy/the-two-week-rule-refactor-your-applications-for-the-cloud-in-10-days/).

Recomendamos minimizar qualquer alteração que não esteja alinhada com o resultado comercial. Em vez disso, crie mecanismos para gerenciar essas mudanças adicionais em projetos futuros.

### Documente e end-to-end processe com antecedência
<a name="end-to-end"></a>

Documente o processo completo de migração e a atribuição de propriedade nos estágios iniciais de um grande programa de migração. Essa documentação é importante para educar todas as partes interessadas sobre como a migração será executada e suas funções e responsabilidades. A documentação também ajudará você a entender onde os problemas podem ocorrer e a fornecer atualizações e iterações do processo à medida que você avança nas migrações.

Durante o desenvolvimento do projeto de migração, garanta que todos os processos existentes sejam compreendidos e que os pontos de integração e dependências estejam documentados de forma clara. Inclua locais onde será necessário o envolvimento com proprietários de processos externos, incluindo solicitações de mudança, solicitações de serviço, suporte de fornecedores e suporte de rede e firewall. Depois que o processo for compreendido, recomendamos documentar a propriedade em uma matriz responsável, responsável, consultada e informada (RACI) para rastrear as diferentes atividades. Para finalizar o processo, estabeleça um plano de contagem regressiva identificando os cronogramas envolvidos em cada etapa da migração. O plano de contagem regressiva geralmente funciona retroativamente a partir da data e hora de transição da migração da carga de trabalho.

Essa abordagem de documentação funcionou bem para uma empresa multinacional de eletrodomésticos que migrou AWS com sucesso em menos de um ano e saiu de quatro data centers. Eles tinham seis equipes organizacionais diferentes e vários terceiros envolvidos, o que introduziu uma sobrecarga de gerenciamento, resultando em back-and-forth decisões e atrasos na implementação. A equipe de Serviços AWS Profissionais, junto com o cliente e seus terceiros, identificou os principais processos para as atividades de migração e os documentou com os respectivos proprietários. A matriz RACI resultante foi compartilhada e acordada por todas as equipes envolvidas. Usando a matriz RACI e uma matriz de escalonamento, o cliente aliviou os bloqueios e os problemas que estavam criando atrasos. Em seguida, eles conseguiram sair dos data centers antes do previsto.

Em outro exemplo de uso de RACI e matrizes de escalonamento, uma seguradora conseguiu sair do data center em menos de 4 meses. O cliente entendeu e implementou um modelo de responsabilidade compartilhada, e uma matriz RACI detalhada foi seguida para acompanhar o progresso de cada processo e atividade durante a migração. Como resultado, o cliente conseguiu migrar mais de 350 servidores nas primeiras 12 semanas de implementação.

### Documente padrões e artefatos de migração padrão
<a name="artifacts"></a>

Pense nisso como criar cortadores de biscoitos para a implementação. Referências, documentação, runbooks e padrões reutilizáveis são a chave para a escalabilidade. Eles registram a experiência, o aprendizado, as armadilhas, os problemas e as soluções que futuros projetos de migração podem reutilizar e evitar, acelerando significativamente a migração. Os padrões e artefatos também são um investimento que ajudará a melhorar o processo e orientar projetos futuros.

Por exemplo, um cliente estava realizando uma migração de um ano em que os aplicativos estavam sendo migrados por três parceiros de SI AWS diferentes. Nos estágios iniciais, cada AWS parceiro estava usando seus próprios padrões, runbooks e artefatos. Isso colocou várias tensões nas equipes de clientes, porque as mesmas informações poderiam ser apresentadas a elas de maneiras diferentes. Após essas dificuldades iniciais, o cliente estabeleceu a propriedade central de toda a documentação e artefatos a serem usados na migração, com um processo para enviar as alterações recomendadas. Esses ativos incluem o seguinte:
+ Um processo de migração padrão e listas de verificação
+ Estilo de diagrama de rede e padrões de formato
+ Padrões de arquitetura e segurança de aplicativos com base na importância dos negócios

Além disso, as alterações em qualquer um desses documentos e padrões foram enviadas a todas as equipes semanalmente, e cada parceiro foi obrigado a confirmar o recebimento e a adesão a todas as alterações. Isso melhorou muito a comunicação e a consistência do projeto de migração e, quando um grande esforço de migração separado em outra unidade de negócios começou, essa equipe conseguiu adotar o processo e os documentos existentes, acelerando consideravelmente seu sucesso.

### Estabeleça uma única fonte confiável para metadados e status da migração
<a name="metadata"></a>

Quando se trata de planejar uma grande migração, estabelecer uma fonte confiável é importante para manter as várias equipes alinhadas e permitir decisões baseadas em dados. Ao iniciar essa jornada, você pode encontrar várias fontes de dados que você pode usar, como o banco de dados de gerenciamento de configuração (CMDB), ferramentas de monitoramento de desempenho de aplicativos, listas de inventário e assim por diante.

Como alternativa, você pode descobrir que há poucas fontes de dados e precisa criar mecanismos para capturar os dados necessários. Por exemplo, talvez você precise usar ferramentas de descoberta para descobrir informações técnicas e pesquisar líderes de TI para obter informações comerciais.

É importante agregar as várias fontes de dados em um único conjunto de dados que você possa usar para a migração. Em seguida, você pode usar a única fonte confiável para rastrear a migração durante a implementação. Por exemplo, você pode rastrear quais servidores foram migrados.

Um cliente de serviços financeiros que queria migrar todas as cargas de trabalho para AWS se concentrou em planejar a migração com o conjunto de dados fornecido. Esse conjunto de dados tinha lacunas importantes, como informações sobre a importância dos negócios e a dependência, então o programa iniciou um exercício de descoberta.

Em outro exemplo, uma empresa do mesmo setor entrou na implementação da onda de migração com base na out-of-date compreensão de seu inventário de infraestrutura de servidores. Eles rapidamente começaram a ver os números de migração diminuírem porque os dados estavam incorretos. Nesse caso, os proprietários dos aplicativos não foram compreendidos, o que fez com que não conseguissem encontrar testadores a tempo. Além disso, os dados não estavam alinhados ao descomissionamento que suas equipes de aplicativos haviam concluído, então os servidores estavam funcionando sem serem usados para fins comerciais.

## Executando sua grande migração
<a name="running"></a>

Depois de estabelecer os resultados de seus negócios e comunicar a estratégia às partes interessadas, você pode começar a planejar como dividir o escopo da grande migração em eventos ou ondas de migração sustentáveis. Os exemplos a seguir fornecem orientações importantes para fazer o plano de ondas.

**Contents**
+ [Planeje as ondas de migração com antecedência para garantir um fluxo constante](#plan-waves)
+ [Mantenha a implementação e o planejamento de ondas como processos e equipes separados](#separate)
+ [Comece pequeno para obter ótimos resultados](#start-small)
+ [Minimize o número de janelas de transição](#cutover-numbers)
+ [Falhe rapidamente, aplique a experiência e repita](#iterate)
+ [Não esqueça a retrospectiva](#retrospective)

### Planeje as ondas de migração com antecedência para garantir um fluxo constante
<a name="plan-waves"></a>

Planejar sua migração é uma das fases mais importantes do programa. Acompanha o ditado “se você falhar em planejar, planeja falhar”. Planejar as ondas de migração com antecedência permite que o projeto flua rapidamente à medida que a equipe se torna mais proativa em relação à situação de migração. Isso ajuda o projeto a escalar com mais facilidade e melhora a tomada de decisões e a previsão à medida que as demandas do projeto aumentam e se tornam complexas. Planejar com antecedência também melhora a capacidade da equipe de se adaptar às mudanças.

Por exemplo, um grande cliente de serviços financeiros estava trabalhando em um programa de saída do data center. Inicialmente, o cliente planejou as ondas de migração de forma sequencial, completando uma onda antes de começar a planejar a próxima. Essa abordagem resultou em menos tempo para se preparar. Quando as partes interessadas foram informadas de que seus aplicativos estavam sendo migrados AWS, elas ainda tinham várias etapas a serem executadas antes de iniciar a migração. Isso adicionou atrasos significativos ao programa. Depois que o cliente percebeu isso, implementou um fluxo de planejamento de migração holístico e focado no futuro, em que as ondas de migração foram planejadas com vários meses de antecedência. Isso forneceu um aviso suficiente para que as equipes de aplicativos realizassem suas atividades de pré-migração, como notificar AWS os parceiros, analisar o licenciamento e assim por diante. Eles poderiam então remover essas tarefas do caminho crítico do programa.

### Mantenha a implementação e o planejamento de ondas como processos e equipes separados
<a name="separate"></a>

Quando as equipes de planejamento e implementação de ondas estão separadas, os dois processos podem funcionar paralelamente. Com comunicação e coordenação, isso evita a desaceleração da migração porque não há servidores ou aplicativos suficientes prontos para atingir a velocidade esperada. Por exemplo, a equipe de migração pode precisar migrar 30 servidores por semana, mas somente 10 servidores estão prontos na onda atual. Esse desafio geralmente é causado pelo seguinte:
+ A equipe de implementação da migração não estava envolvida no planejamento de ondas e os dados coletados na fase de planejamento de ondas não estão completos. A equipe de implementação da migração deve coletar mais dados do servidor antes de iniciar a onda.
+ A implementação da migração está programada para começar logo após o planejamento da onda, sem buffer entre elas.

É fundamental planejar as ondas com antecedência e criar uma barreira entre a preparação e o início da implementação da onda. Também é importante garantir que a equipe de planejamento de ondas e a equipe de migração trabalhem juntas para coletar os dados certos e evitar retrabalho.

### Comece pequeno para obter ótimos resultados
<a name="start-small"></a>

Planeje começar aos poucos e aumentar a velocidade de migração a cada onda subsequente. A onda inicial deve ser um aplicativo único e pequeno, com menos de 10 servidores. Adicione aplicativos e servidores adicionais em ondas subsequentes, aumentando sua velocidade de migração total. Priorizar aplicativos menos complexos ou arriscados e aumentar a velocidade em um cronograma dão à equipe tempo para se adaptar ao trabalho em conjunto e aprender o processo. Além disso, a equipe pode identificar e implementar melhorias no processo com cada onda, o que pode melhorar substancialmente a velocidade das ondas posteriores.

Um cliente estava migrando mais de 1.300 servidores em um ano. Ao começar com uma migração piloto e algumas ondas menores, a equipe de migração conseguiu identificar várias maneiras de melhorar as migrações posteriores. Por exemplo, eles identificaram novos segmentos de rede de data center mais cedo. Eles trabalharam com a equipe de firewall no início do processo para implementar regras de firewall que permitissem a comunicação com as ferramentas de migração. Isso ajudou a evitar atrasos desnecessários em futuras ondas. Além disso, a equipe conseguiu desenvolver scripts para ajudar a automatizar mais seus processos de descoberta e transição a cada onda. Começar aos poucos ajudou a equipe a se concentrar nas melhorias iniciais do processo e aumentou muito sua confiança.

### Minimize o número de janelas de transição
<a name="cutover-numbers"></a>

As migrações em massa exigem uma abordagem disciplinada para impulsionar a escala. Ser muito flexível em algumas áreas é um antipadrão para grandes migrações. Ao limitar o número de janelas de transição semanais, o tempo gasto em atividades de transição tem um valor maior.

Por exemplo, se a janela de transição for muito flexível, você poderá acabar com 20 transições com cinco servidores cada. Em vez disso, você poderia ter duas transferências com 50 servidores cada. Como o tempo e o esforço de cada transição são semelhantes, ter menos e maiores transições reduz a carga operacional do agendamento e limita atrasos desnecessários.

Uma grande empresa de tecnologia estava tentando migrar de alguns data centers alugados antes da expiração do contrato. Perder a expiração resultaria em prazos de renovação caros e de curto prazo. No início da migração, as equipes de aplicativos podiam ditar o cronograma de migração até o último minuto, incluindo optar por não migrar por qualquer motivo, poucos dias antes da transição. Isso levou a vários atrasos nos estágios iniciais do projeto. Muitas vezes, o cliente precisava negociar com outras equipes de inscrição no último minuto para preencher o formulário. O cliente acabou aumentando sua disciplina de planejamento, mas esse erro precoce gerou estresse constante para a equipe de migração. Atrasos no cronograma geral fizeram com que alguns aplicativos não saíssem dos data centers a tempo.

### Falhe rapidamente, aplique a experiência e repita
<a name="iterate"></a>

Inicialmente, toda migração tem armadilhas. Falhar cedo ajuda a equipe a aprender, entender os gargalos e aplicar as lições aprendidas em ondas maiores. Espera-se que as primeiras duas ondas em uma migração sejam lentas pelos seguintes motivos:
+ Os membros da equipe estão se adaptando uns aos outros e ao processo.
+ As grandes migrações geralmente envolvem muitas ferramentas e pessoas diferentes.
+ É preciso tempo para integrar, testar, falhar, aprender e melhorar continuamente o end-to-end processo.

Problemas são comuns e esperados durante as primeiras duas ondas. É importante entender e comunicar isso a toda a organização, porque algumas equipes podem não gostar de experimentar coisas novas e falhar. O fracasso pode desencorajar a equipe e se tornar um obstáculo para futuras migrações. Garantir que todos entendam que os problemas iniciais fazem parte do trabalho e incentivar todos a tentarem e falharem é fundamental para uma migração bem-sucedida.

Uma empresa planejou migrar mais de 10.000 servidores em 24 a 36 meses. Para atingir essa meta, eles precisavam migrar quase 300 servidores por mês. No entanto, isso não significa que eles migraram 300 servidores desde o primeiro dia. As primeiras duas ondas foram ondas de aprendizado para que a equipe pudesse entender como as coisas funcionavam e quem tinha permissão para fazer o quê. Eles também identificaram integrações que melhorariam o processo, como a integração com o CMDB e. CyberArk Eles usaram as ondas de aprendizado para falhar, melhorar e falhar novamente, refinando o processo e a automação. Depois de 6 meses, eles conseguiram migrar mais de 120 servidores por semana.

### Não esqueça a retrospectiva
<a name="retrospective"></a>

Essa é uma parte importante de um processo ágil. É onde a equipe se comunica, ajusta, aprende, concorda e avança. Uma retrospectiva no nível mais básico é olhar para trás, discutir o que aconteceu, determinar o que correu bem e o que precisa melhorar. As melhorias podem então ser criadas com base nessas discussões. As retrospectivas envolvem alguma formalidade ou processo em torno da ideia de lições aprendidas. As retrospectivas são importantes porque, para alcançar a escala e a velocidade necessárias para que grandes migrações tenham sucesso, os processos, as ferramentas e as equipes devem evoluir e melhorar constantemente. As retrospectivas podem desempenhar um papel significativo nisso.

As sessões tradicionais de lições aprendidas não acontecem até o final de um programa, então, muitas vezes, essas lições não são revisadas no início da próxima onda de migração. Com grandes migrações, as lições aprendidas devem ser aplicadas à próxima onda e devem ser uma parte fundamental do processo de planejamento de ondas.

Para um cliente, foram realizadas retrospectivas semanais para discutir e documentar as lições aprendidas com as transições. Nessas sessões, eles descobriram áreas em que havia espaço para simplificação do ponto de vista do processo ou automação. Isso resultou na implementação de um cronograma de contagem regressiva com atividades, proprietários e scripts de automação específicos para minimizar as tarefas manuais, incluindo a validação de ferramentas de terceiros e a instalação de CloudWatch agentes da Amazon, durante a transição.

Em outra grande empresa de tecnologia, retrospectivas regulares foram realizadas com a equipe para identificar problemas com ondas migratórias anteriores. Isso resultou em melhorias no processo, no script e na automação que reduziram o tempo médio de migração em 40% ao longo do programa.

## Considerações adicionais
<a name="additional"></a>

Muitas áreas devem ser consideradas em um grande programa de migração. As seções a seguir fornecem ideias sobre outros itens que devem ser considerados.

**Contents**
+ [Limpe à medida que avança](#clean-up)
+ [Implemente várias fases para qualquer transformação adicional](#phases)

### Limpe à medida que avança
<a name="clean-up"></a>

Uma migração não é considerada bem-sucedida se custar 10 vezes mais do que o esperado e o projeto não for concluído até que os recursos usados para a migração sejam encerrados e limpos. Essa limpeza deve fazer parte da atividade pós-migração. Isso garante que você não deixará recursos e serviços não utilizados em seu ambiente, o que aumentará os custos. A limpeza pós-migração também é uma boa prática de segurança para evitar ameaças e vulnerabilidades que exponham seu ambiente.

Dois resultados principais da mudança para o Nuvem AWS são a economia de custos e a segurança. Deixar recursos não utilizados pode anular o propósito comercial de migrar para a nuvem. Os recursos mais comuns que não são limpos incluem o seguinte:
+ Dados de teste
+ Testar bancos de dados
+ Contas de teste, incluindo regras de firewall, grupos de segurança e endereços IP da lista de controle de acesso à rede (ACL de rede)
+ Portas provisionadas para testes
+ Volumes do Amazon Elastic Block Store (Amazon EBS)
+ Snapshots
+ Replicação (como interromper a replicação de dados do local para) AWS
+ Arquivos que consomem espaço (como backups temporários do banco de dados usados para migrar)
+ Instâncias que hospedam as ferramentas de migração

Em um exemplo de práticas inadequadas de limpeza, os SI AWS Partners não estavam removendo os agentes de replicação após uma migração bem-sucedida. Uma AWS auditoria descobriu que os servidores de replicação e os volumes do EBS que já haviam sido migrados estavam custando \$120.000 (USD) por mês. Para mitigar o problema, a AWS Professional Services criou um processo de auditoria automatizado que notificou AWS os SI Partners quando servidores obsoletos ainda estavam sendo replicados. Os AWS parceiros SI poderiam então agir em instâncias não utilizadas e obsoletas.

Para futuras migrações, foi adotado um processo para definir um período de hiperatendimento pós-migração de 48 horas para garantir a adoção tranquila da plataforma. Em seguida, a equipe de infraestrutura do cliente enviou uma solicitação de desativação dos servidores locais. Foi informado que, após a aprovação da solicitação de desativação, os servidores da respectiva onda seriam removidos do console do serviço de migração de aplicativos.

### Implemente várias fases para qualquer transformação adicional
<a name="phases"></a>

Ao realizar uma grande migração, é importante manter o foco em seu objetivo principal, como o fechamento do data center ou a transformação da infraestrutura. Em migrações menores, a variação do escopo pode ter um impacto mínimo. No entanto, alguns dias de esforço adicional multiplicados por potencialmente milhares de servidores podem adicionar uma quantidade significativa de tempo ao programa. Além disso, as mudanças adicionais também podem exigir atualizações na documentação, no processo e no treinamento das equipes de suporte.

Para superar possíveis desvios de escopo, você pode implementar uma abordagem de várias fases para sua migração. Por exemplo, se sua meta era desocupar um data center, a fase 1 pode incluir apenas a rehospedagem da carga de trabalho o AWS mais rápido possível. Depois que uma carga de trabalho é rehospedada, a fase 2 pode implementar atividades transformacionais sem arriscar o resultado comercial desejado.

Por exemplo, um cliente planejou sair do data center em 12 meses. No entanto, sua migração abrangeu outras atividades de transformação, como a implantação de novas ferramentas de monitoramento de desempenho de aplicativos e a atualização de sistemas operacionais. Mais de 1.000 servidores estavam no escopo da migração, então essas atividades adicionaram um atraso significativo à migração. Além disso, essa abordagem exigiu treinamento no uso das novas ferramentas. Posteriormente, o cliente decidiu implementar uma abordagem de várias fases com foco inicial na rehospedagem. Isso aumentou a velocidade de migração e reduziu o risco de não cumprir a data de fechamento do data center.