Migração para a nuvem: como planejar sem surpresas

Por que planejamento é crítico em migração cloud

Migração para nuvem é um dos maiores investimentos de TI que empresas fazem. Estudos mostram que, com frequência, sofrem desvios significativos: custos 30-40% acima do orçado, prazos 4-6 meses atrasados, complexidades técnicas muito subestimadas. A causa: planejamento insuficiente.

Planejamento estruturado de migração cloud não é "vamos replicar nossos systems na nuvem" — é análise rigorosa de cada aplicação, estratégia correta para cada uma, estimativa conservadora de esforço, sequenciamento de risco. Um planejamento bem feito custa 5-10% do orçamento total de migração, mas economiza 20-30% em desvios evitados.

Cloud Readiness Assessment: diagnosticando sua postura atual

Antes de planejar migração, avaliar readiness — "estamos prontos para nuvem?" Assessment responde perguntas críticas: qual é nossa maturidade técnica, quais gaps existem, qual é o nível de risco.

Dimensões de readiness assessment incluem:

1. Maturidade técnica: nossas aplicações são modernas o suficiente para nuvem? Temos containerização, CI/CD, monitoramento? Ou dependemos de infraestrutura física (storage direto, hardware específico)?
2. Segurança e conformidade: dados precisam estar em jurisdição específica (Brasil, conforme LGPD)? Temos requisitos de conformidade (SOX, HIPAA)? Nuvem pública atende?
3. Dependências: há aplicações críticas com dependências de rede on-premise, latência baixa ou hardware específico?
4. Capacidade de operação: time de TI conhece nuvem? Temos skills internos ou precisamos treinar/contratar?
5. Capacidade financeira: temos orçamento para migração (projeto) + custos de operação em nuvem (mensal)?

Resultado do assessment é visão clara: quais aplicações migram facilmente, quais precisam refactor, quais precisam de risco ou stay on-premise. Sem esse diagnóstico, subestima-se complexidade.

As 6 estratégias de migração (6 Rs): escolhendo a certa para cada aplicação

Não há uma estratégia única de migração. AWS define 6 Rs — estratégias diferentes para aplicações diferentes. Escolher certa para cada aplicação é chave para eficiência.

1. Rehost (Lift and Shift): copiar aplicação exatamente como está para nuvem. Mais rápido, menos mudança arquitetônica. Apropriado para aplicações estáveis que não exigem mudança. Tempo: 2-4 meses. Custo: moderado.
2. Replatform (Lift, Tinker and Shift): copiar com pequenas otimizações — usar managed database em vez de instalar banco em servidor. Balanceia velocidade e aproveitamento de nuvem. Tempo: 3-6 meses. Custo: moderado a alto.
3. Refactor (Re-architect): redesenhar aplicação para nuvem — separar em microserviços, usar containers. Máximo aproveitamento de nuvem, máxima flexibilidade futura. Mais lento, mais caro. Tempo: 6-12 meses. Custo: alto. Apropriado para aplicações críticas que devem ser modernas.
4. Repurchase (Replace): trocar aplicação antiga por SaaS. Exemplo: substituir on-premise ERP por Salesforce Cloud, SAP Cloud. Elimina manutenção, reduz custo operacional. Tempo: 3-8 meses. Custo: alto inicial, mas baixo operacional. Apropriado para aplicações commodity (CRM, RH, Finance).
5. Retire (Desativate): desligar aplicação — ela não é mais usada ou valor é marginal. Economiza custo operacional, reduz complexidade. Tempo: 1-2 meses. Custo: baixo. Apropriado para sistemas legados subutilizados.
6. Retain: manter on-premise. Aplicações que não são boas candidatas para nuvem (segurança, conformidade, latência crítica, hardware específico). Tempo e custo: zero migração, mas custo operacional mantém.

Uma empresa de porte médio pode ter 30% Rehost, 20% Replatform, 10% Refactor, 25% Repurchase, 10% Retire, 5% Retain. Cada um requer abordagem diferente de planejamento e execução.

Estimativa de custo: evitando surpresas de budget

Custo de migração cloud tem 3 componentes: custo de migração (projeto), custo de operação inicial (ramp-up), custo de operação estável (steady state).

Componentes de custo de migração:

• Consultoria / serviços profissionais: avaliação, planejamento, execução. Tipicamente 30-40% do custo de migração. Depende de complexidade e tamanho de empresa.
• Infraestrutura de nuvem (projeto): custo de executar migração (dados, instâncias temporárias, storage). Tipicamente 20-30%.
• Treinamento / ramp-up: treinar time em nuvem, onboarding de novos skills. Tipicamente 10-15%.
• Contingência: riscos não previstos. Típica 15-20%. ERRO COMUM: não incluir contingência e sofrer atraso.

Custo de operação em nuvem é tipicamente 10-30% menor que on-premise para ambiente estável, mas ramp-up pode ser mais caro se arquitetura não está otimizada (exemplo: muitas instâncias grandes em vez de pequenas). Baseline conservador: assumir que nos primeiros 6 meses, custo de nuvem será 20% maior (ineficiência de arquitetura), depois cai conforme otimização.

Estimativa de esforço: fatores que impactam cronograma

Tempo de migração varia muito por contexto, mas fatores principais incluem:

• Número de aplicações: 5 aplicações vs. 50 = ordem de magnitude diferente.
• Complexidade técnica: Rehost é rápido (2-4 meses por aplicação), Refactor é lento (6-12 meses).
• Qualidade de documentação: se aplicação tem documentação e dependências claras, migração é mais rápida. Se tudo está na cabeça de quem desenvolveu, mais lenta.
• Capacidade de paralelização: se você pode migrar múltiplas aplicações em paralelo (recursos disponíveis), cronograma cai. Se sequencial, cronograma estica.
• Complexidade de cutover: se aplicação pode ficar offline 1 dia, cutover é simples. Se precisa estar 100% disponível (zero-downtime migration), complexidade sobe muito.
• Conformidade / validação: se precisa passar por auditoria de conformidade pós-migração, adiciona 2-4 semanas por aplicação.

Abordagem conservadora: estimar tempo baseado em "piores casos" (maioria vai ser melhor). Exemplo: "Refactor típico leva 6 meses, seu pode levar 8-10."

Análise de risco: segurança, conformidade, vendor lock-in

Riscos críticos de migração cloud que precisam de gestão ativa:

1. Segurança de dados: dados vão estar em nuvem pública? Criptografia em repouso (dados armazenados) e em trânsito (dados viajando)? Controle de acesso (quem pode acessar dados)? Auditoria (rastrear quem acessou quando)?
2. Conformidade (LGPD, SOX, etc): empresa regulada? Nuvem precisa comprovar conformidade com regulations. Jurisdição de dados? LGPD exige dados de pessoas do Brasil estarem em data center no Brasil (ou controlado por empresa brasileira).
3. Continuidade de negócio: que acontece se nuvem cai? Há backup/redundância? Quanto tempo RTO (Recovery Time Objective — tempo para recuperar) e RPO (Recovery Point Objective — quanto de dado você pode perder)?
4. Vendor lock-in: dados e aplicações ficam reféns de um vendor? Se usar serviços específicos de AWS (DynamoDB, Kinesis), migração para Azure fica cara. Mitigação: usar serviços genéricos (databases open-source, infraestrutura padrão).
5. Custo runaway: nuvem é "pay as you go" — se não há governance, contas crescem rápido. Exemplo: instâncias deixadas ligadas acidentalmente, dados armazenados sem limite, saída de dados (transferência entre regiões) não monitorada.

Gestão de risco exige: definição clara de risk appetite (quanto risco é aceitável?), mitigação por risco (o que fazer para reduzir?), monitoramento durante execução, escalonamento se risco materializa.

Sequenciamento de migração: começar com quick wins

Sequência de qual aplicação migrar primeiro é estratégica. Começa com "quick wins" — aplicações com menor risco, maior impacto, para gerar momentum e aprendizado.

Critérios para priorizar:

• Risco técnico: aplicações simples (Rehost ou Repurchase) antes de complexas (Refactor).
• Risco de negócio: aplicações não-críticas antes de críticas. Se dá ruim, impacto é menor.
• Valor de demonstração: aplicações que, uma vez migradas, geram benefício visível (custo reduzido, performance melhorada, novas funcionalidades). Demonstração gera apoio da liderança.
• Aprendizado para time: aplicação que permite time aprender cloud sem risco. Conhecimento transfere para próximas migrações.
• Dependências: aplicações com poucas dependências (não bloqueiam outras) antes de aplicações centrais.

Típico: Wave 1 é aplicações simples + low risk. Wave 2 é moderadamente complexas. Wave 3 é aplicações críticas + complexas (benefit de aprendizado e infrastructure madura de Wave 1/2).