O que o modelo contém
Migração para nuvem não é um projeto só: é a construção de uma base mais uma onda que se repete. O modelo separa as duas coisas, para que a landing zone esteja pronta antes que as ondas dependam dela:
- Descoberta e avaliação — Inventário de aplicações, mapeamento de dependências, criticidade para o negócio e uma decisão dos 7Rs por carga — rehost, replatform, refactor, repurchase, relocate, aposentar ou manter. Marco: destino das aplicações acordado.
- Landing zone e fundação — Contas e assinaturas, rede e conectividade híbrida, identidade, guardrails de segurança, observabilidade e modelo de custos. Tudo a jusante depende disso. Marco: landing zone em operação.
- Planejamento de ondas e piloto — Agrupar aplicações em ondas por dependência, e não por área, e comprovar o runbook numa onda piloto de baixo risco.
- Ondas de migração — Ciclos repetidos de preparação, migração, teste e virada por onda. O padrão é o mesmo a cada vez; o que muda é o perfil de risco.
- Virada e hypercare — Viradas produtivas, troca de DNS e de tráfego, janelas de rollback e o período de suporte reforçado após cada onda. Marco: virada produtiva concluída.
- Desativação e otimização — Desligar o ambiente de origem, encerrar o contrato de data center ou hospedagem e então dimensionar recursos e contratar capacidade reservada. É aqui que o business case realmente se realiza.
Como adaptar
- Fixe primeiro a data de saída do data center ou do contrato de hospedagem e trabalhe de trás para frente — essa data costuma ser contratual e inegociável.
- Acrescente uma linha por aplicação quando o inventário estiver pronto, agrupada sob a onda que a carrega.
- Duplique a fase de onda para cada onda adicional; a estrutura interna permanece idêntica.
- Tire os candidatos a refactor do plano de ondas: são projetos de desenvolvimento, não migrações, e misturá-los destrói a cadência das ondas.
- Marque landing zone em operação, piloto concluído, cada virada produtiva e a desativação da origem como marcos.
Dicas de cronograma
- Não inicie ondas antes de a landing zone estar concluída. Migrar para uma fundação que ainda muda significa migrar duas vezes, e é a maior fonte de retrabalho nesses programas.
- Agrupe ondas por dependência, não por departamento. Aplicações que conversam entre si devem migrar juntas, ou você pagará pela latência entre dois ambientes enquanto estiverem separadas.
- Faça uma onda piloto de verdade. A função dela é comprovar o runbook e expor as surpresas, então escolha aplicações de baixo risco mas genuinamente representativas, não as três mais fáceis da lista.
- Preveja orçamento para operação em paralelo. Os dois ambientes rodam juntos durante toda a migração; esse custo de sobreposição é real e pertence ao business case desde o primeiro dia.
- Mantenha janela de rollback em toda virada. Virada sem rollback documentado e ensaiado é uma porta de mão única atravessada sem que ninguém tenha decidido atravessá-la.
Modelos relacionados
- Cronograma de implantação de ERP
- Modelo de cronograma para projeto de software
- Cronograma de construção de data center
- Ver todos os modelos de gráfico de Gantt
Este modelo está em português. Páginas relacionadas ainda não traduzidas abrem em inglês.
Perguntas frequentes
Quanto tempo leva uma migração para nuvem?
Em geral de 9 a 24 meses para um parque de porte médio, dependendo sobretudo do número de aplicações, da complexidade das dependências e de quanto refactor está no escopo. O modelo usa um cronograma de cerca de quinze meses, que você pode comprimir ou estender.
O que são os 7Rs da migração para nuvem?
Rehost (mover como está), replatform (ajustar), refactor (reescrever), repurchase (trocar por SaaS), relocate (transferir a plataforma), retire (aposentar) e retain (manter). São as opções de destino atribuídas a cada aplicação durante a avaliação, e defini-las cedo é o que torna o planejamento de ondas possível.
Como sequenciar as ondas de migração?
Primeiro por grupo de dependência, depois por risco. Aplicações que compartilham dados ou se chamam entre si devem migrar na mesma onda, e a onda piloto deve ser de baixo risco mas representativa o bastante para comprovar o runbook.
O plano cobre a desativação do ambiente antigo?
Sim — é uma fase inteira, porque é onde a economia prevista no business case efetivamente aparece, e é a fase mais frequentemente abandonada depois da última virada.
O modelo de migração para nuvem é gratuito?
Sim. Downloads gratuitos em Excel, PowerPoint e CSV, e edição online gratuita, sem cadastro.