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á.
# Estágio de pré-substituição
Suas opções de substituição dependem de vários fatores, incluindo o padrão de migração que você está usando e as ferramentas, tecnologias e configurações do ambiente de origem e de destino. Por exemplo, as opções de transferência são diferentes para migrar um VMware ambiente AWS em comparação com a criação de uma pilha completamente nova.
Fundamentalmente, todas as substituições buscam alcançar o mesmo resultado: transferir uma workload para outro local. É importante entender para onde os servidores ou as aplicações foram migrados para que você possa configurar as dependências upstream e downstream para se conectar ao novo endpoint.
Dependendo da natureza do serviço, os bancos de dados existentes e suas conexões com outros sistemas que se movem para o novo local podem ser complexos. A sincronização de bancos de dados para garantir dados consistentes em ambos os locais pode aumentar a complexidade. Além disso, vários serviços exigem que você ajuste sua configuração de rede ou corte vários serviços ao mesmo tempo.
## Desenvolver um plano de substituição
Para reduzir o risco de atrasos, retrabalho, interrupções não planejadas, perda de dados, problemas de performance e uma experiência de usuário ruim, é possível desenvolver um plano de substituição, criar uma pasta de trabalho de substituição e ensaiar a substituição. Recomendamos que o plano de substituição inclua planos de contingência e estratégias de mitigação de risco em caso de falha no evento de uma substituição malsucedida. Certifique-se de documentar um procedimento de reversão como parte do plano de substituição.
Recomendamos analisar e avaliar os seguintes itens essenciais como parte do seu processo de planejamento antes da substituição:
+ Tempo de inatividade necessário, incluindo:
+ Impacto na empresa (por exemplo, na receita ou na confiança) causado pelo prolongamento da janela de tempo de inatividade alocada
+ Contingência para atividades “fix forward” em caso de eventos imprevistos
+ Tempo de reversão em caso de falha
+ Conectividade do usuário
+ Dependências de aplicações e sistemas
+ Alterações na infraestrutura
+ Alterações operacionais
+ Planos de teste, incluindo:
+ Teste funcional
+ Teste de performance com testes de linha de base e testes pós-substituição
+ Teste de integração e conectividade para aplicações, sistemas e serviços dependentes
+ Teste de estratégias durante o período de substituição e garantia
+ Alterações na implantação relacionadas a ferramentas e estratégia
Por fim, considere incorporar o seguinte em seu plano:
+ Definições e duração da tarefa
+ Proprietários da tarefa
+ Sequência de estágios e tarefas
## Criar um runbook de substituição
Recomendamos que você crie um runbook de substituição para ser usado por sua equipe de migração para monitorar as atividades, incluindo seus respectivos horários planejados de início e término, sequência e proprietários. É possível usar uma matriz RACI para atribuir responsabilidades aos membros apropriados da equipe. Um runbook de substituição pode fornecer os seguintes benefícios:
+ Risco reduzido ao alinhar proativamente diferentes partes interessadas
+ Aumento da produtividade com a reutilização de um mecanismo comprovado para migrar aplicativos para a nuvem AWS
+ Maior velocidade de migração de aplicações por meio de um modelo estruturado para planejamento de transição
+ Fornecer uma estrutura para que os processos necessários sejam seguidos
+ Fornecer um mecanismo que permita que as alterações nos processos sejam comunicadas a todas as equipes