Se sua empresa já tem reunião demais e execução de menos, a migração para nuvem vai piorar o caos se você não criar um projeto do jeito certo. A diferença entre “vai dar” e “vai dar certo” está no que você define antes: escopo, responsáveis, cronograma realista, critérios de sucesso e controle de riscos.
A seguir, você vai ver um passo a passo prático para montar um projeto de migração para nuvem em empresa de médio porte, com entregáveis claros e decisões que não ficam presas no WhatsApp.
Defina o objetivo do projeto (sem isso, tudo vira discussão)
Antes de falar em tecnologia, escreva o objetivo em uma frase e depois quebre em resultados mensuráveis. Exemplos do tipo de resultado (você adapta ao seu caso): reduzir tempo de provisionamento, aumentar disponibilidade, diminuir custo operacional, padronizar ambientes, melhorar governança.
Para não virar “objetivo bonito”, transforme em critérios de sucesso. Use perguntas como:
- O que precisa estar rodando na nuvem para considerarmos a primeira etapa concluída?
- Quais serviços devem migrar primeiro e por quê?
- Quais indicadores vão provar que a migração funcionou?
Monte o escopo com base em serviços, não em “sistemas”
Em empresas de médio porte, o erro mais comum é listar “sistemas” sem detalhar o que cada um precisa para operar. Em vez disso, organize o escopo por serviços e dependências.
Um bom escopo de migração para nuvem normalmente inclui:
- Aplicações (incluindo versão, linguagem e dependências)
- Infraestrutura (servidores, redes, balanceadores, storage)
- Dados (origem, volume aproximado, requisitos de retenção e migração)
- Integrações (APIs, filas, integrações com sistemas legados)
- Identidade e acesso (usuários, permissões, autenticação)
- Ambientes (dev, homologação, produção)
- Requisitos de segurança e conformidade (o que é obrigatório no seu setor)
Se você não tiver clareza do inventário, comece pelo que gera mais risco e mais valor. Migrar “o que é fácil” sem entender dependências costuma atrasar o resto.
Escolha a estratégia de migração (e registre o porquê)
Você não precisa de “um modelo perfeito”. Precisa de uma estratégia que faça sentido para o seu portfólio e para o seu time.
Defina a estratégia com base em três perguntas:
- O que precisa ficar disponível e com qual criticidade? (produção, janelas de manutenção, tolerância a indisponibilidade)
- O que pode ser refeito vs. o que precisa só ser movido?
- Quais integrações são mais sensíveis? (legados, bancos, rotinas de integração)
Depois, documente decisões. Exemplo do que não pode ficar solto:
- Quais cargas vão primeiro
- Como você vai validar antes de trocar para produção
- Como será a estratégia de rollback
Estruture governança: quem decide, quem executa, quem aprova
Se a migração ficar “no colo” de uma pessoa, você perde previsibilidade. Para evitar isso, crie uma estrutura simples de governança.
Papel mínimo para empresa de médio porte
- Sponsor (diretoria): remove obstáculos e aprova prioridades.
- Gerente de projeto: controla plano, prazos, riscos, comunicação.
- Owner de negócio (por domínio): garante requisitos e validações.
- Responsável técnico: define arquitetura, padrões e segurança.
- Time de migração: executa atividades e prepara evidências.
- Segurança/Compliance (quando aplicável): valida controles e acessos.
Ritual de decisão (para reunião não virar conversa)
Defina uma cadência e regras. Por exemplo:
- Reunião semanal curta de acompanhamento
- Reunião de decisão apenas quando houver itens prontos para aprovar
- Registro de decisões e responsáveis em um único lugar
Se você não registrar decisão, o time volta para o “achismo” na semana seguinte.
Faça o planejamento por fases (com entregas intermediárias)
Um projeto grande precisa ser dividido em fases que gerem resultado visível. Um modelo prático para migração em empresa de médio porte:
- Fase 1: Descoberta e inventário (mapear aplicações, dependências, dados e requisitos)
- Fase 2: Planejamento e desenho (arquitetura, padrões, segurança, estratégia de testes)
- Fase 3: Preparação do ambiente (redes, acesso, base de observabilidade, templates)
- Fase 4: Piloto (migrar um conjunto controlado e validar processo)
- Fase 5: Execução por ondas (migrar em ciclos com critérios de entrada e saída)
- Fase 6: Cutover e estabilização (troca para produção, monitoramento e ajustes)
- Fase 7: Encerramento (lições aprendidas, documentação, operação definida)
O piloto não é “para experimentar”. É para provar que seu método funciona antes de aumentar o ritmo.
Crie um plano de migração com critérios de entrada e saída
Para cada onda de migração, defina o que precisa estar pronto antes de começar e o que precisa estar validado para concluir.
Critérios de entrada (antes de migrar)
- Requisitos funcionais e não funcionais confirmados
- Dependências mapeadas
- Ambiente homologado configurado
- Plano de testes definido
- Plano de rollback definido
Critérios de saída (depois de migrar)
- Testes executados com evidências
- Dados validados (consistência e integridade)
- Performance e disponibilidade dentro do esperado
- Monitoramento e alertas configurados
- Documentação e handover para operação
Sem critérios, você “termina” quando alguém lembra, e não quando o risco está controlado.
Defina testes e validação como parte do projeto
Uma migração falha mais por validação fraca do que por tecnologia. Trate testes como atividade com dono, agenda e evidência.
Planeje pelo menos:
- Teste funcional: comportamento esperado
- Teste de integração: fluxos com outros sistemas
- Teste de dados: migração, consistência e retenção
- Teste de carga (quando aplicável): performance realista
- Teste de segurança: acessos e permissões
- Teste de contingência: rollback e recuperação
Gerencie riscos com uma lista curta e atualizada
Risco não é planilha gigante. É uma lista curta que todo mundo entende e que muda conforme você avança.
Organize por categorias e sempre deixe:
- Risco
- Impacto (no negócio e na operação)
- Probabilidade (mesmo qualitativa)
- Ação de mitigação
- Dono
- Status
Exemplos de riscos que costumam aparecer em migração: dependência de integrações, lacunas no inventário, falhas de acesso, janela de corte apertada, falta de evidência em testes, e dificuldade de rollback.
Plano de comunicação: menos ruído, mais previsibilidade
Se você não comunicar, o time descobre mudanças quando já está atrasado. Se você comunicar demais, ninguém lê.
Defina o que comunicar e para quem:
- Diretoria: marcos, riscos relevantes, decisões necessárias
- Negócio: janelas, impacto esperado, validações necessárias
- Operação e suporte: handover, rotinas, alertas, playbooks
- Times técnicos: padrões, arquitetura, mudanças planejadas
Use um canal único para status do que está “em execução”, “em teste” e “pronto para corte”.
Prepare a operação antes do cutover
Uma migração que termina e deixa a operação sem método vira incidente em sequência. Antes do cutover, garanta:
- Monitoramento: o que você vai observar e como
- Alertas: quais eventos geram ação
- Playbooks: o que fazer em incidentes comuns
- Gestão de acessos: quem entra, como aprova, como audita
- Rotinas de backup e recuperação: como testar e com que frequência
Se você não definir isso, o “dia da migração” vira um dia de improviso.
Documente os entregáveis do projeto (para não recomeçar do zero)
Para empresa de médio porte, a documentação precisa ser suficiente para executar e manter. Inclua:
- Plano do projeto (fases, ondas, marcos)
- Inventário e mapeamento de dependências
- Arquitetura e padrões (incluindo segurança e acesso)
- Plano de testes e critérios de validação
- Plano de cutover e rollback
- Riscos e plano de mitigação
- Documentação de handover para operação
- Registro de decisões e lições aprendidas
Checklist rápido para você começar hoje
- Escreveu o objetivo do projeto e os critérios de sucesso?
- Definiu escopo por serviços e dependências, não só por “sistemas”?
- Nomeou sponsor, gerente de projeto e responsáveis técnicos e de negócio?
- Dividiu em fases e definiu o que sai pronto em cada uma?
- Planejou piloto e critérios de entrada e saída por onda?
- Definiu testes, evidências e validação antes de corte?
- Montou uma lista curta de riscos com dono e mitigação?
- Preparou operação (monitoramento, alertas, playbooks) antes do cutover?
Erros comuns que atrasam migração em empresa de médio porte
- Começar pela tecnologia e não pelo escopo e validação.
- Não ter inventário confiável e descobrir dependências no meio do caminho.
- Fazer reunião sem decisão e deixar status espalhado em mensagens.
- Não definir critérios de sucesso para cada onda.
- Não preparar rollback e tratar cutover como “tudo ou nada”.
- Deixar a operação para depois do corte.
Se você quer previsibilidade, trate a migração como projeto com método: decisões registradas, entregas por fase e validação com evidência. É assim que a empresa ganha controle enquanto o negócio continua rodando.
