Resposta direta
Migrar para cloud faz sentido quando existe um motivo de negócio e a arquitetura consegue convertê-lo em resultado: absorver variações relevantes de demanda, aumentar disponibilidade, acelerar a criação de ambientes, ampliar a capacidade de recuperação ou retirar da empresa uma dependência de infraestrutura que não diferencia sua operação. A nuvem é um modelo de consumo e operação, não um destino obrigatório para todo sistema.
Manter parte do ambiente local pode ser melhor quando latência, conectividade, soberania de dados, equipamentos próximos à operação, licenças, integrações legadas ou custo estável tornam a migração desproporcional. Em muitos casos, a decisão correta é híbrida: cada workload permanece onde entrega a melhor combinação de risco, desempenho, governança e custo total.
Quando cloud costuma fazer sentido
- A demanda varia de forma relevante e a capacidade pode crescer ou reduzir sem comprometer o serviço.
- Disponibilidade e recuperação exigem redundância geográfica, automação e testes que seriam caros ou lentos de construir localmente.
- A empresa precisa provisionar ambientes, dados ou serviços com mais velocidade e padrões repetíveis.
- A renovação do parque exigiria investimento relevante, desde que a comparação inclua todo o ciclo de vida e não apenas a compra inicial.
- O workload pode aproveitar serviços gerenciados, automação ou modernização, em vez de apenas reproduzir servidores locais em máquinas virtuais.
- Existe capacidade para operar identidade, segurança, observabilidade, custos, backup, continuidade e mudanças no novo modelo.
Quando manter localmente pode ser a melhor decisão
- O sistema depende de resposta muito rápida junto a equipamentos, linhas de produção ou grande volume de dados gerado no local.
- A conectividade disponível não oferece redundância, latência ou estabilidade compatíveis com a criticidade do processo.
- Licenças, appliances ou contratos criam restrições técnicas e econômicas que não foram resolvidas com o fornecedor.
- A carga é previsível, estável e já opera em infraestrutura amortizada, eficiente e com capacidade suficiente.
- A aplicação legada tem dependências pouco conhecidas e a migração imediata aumentaria o risco sem produzir benefício proporcional.
- Requisitos regulatórios ou contratuais impõem controles de localização, acesso ou custódia que o desenho proposto ainda não comprova.
Os critérios que realmente mudam a decisão
| Critério | O que precisa ser verificado | Implicação arquitetural |
|---|---|---|
| Elasticidade | Amplitude, frequência e previsibilidade dos picos; tempo aceitável para adicionar capacidade. | Cloud ganha força quando a variação é real e a aplicação consegue escalar. Capacidade fixa pode ser mais econômica em carga estável. |
| Disponibilidade e recuperação | RTO, RPO, dependências, redundância, testes e modo degradado do processo. | Distribuir recursos não basta. O desenho precisa eliminar pontos únicos de falha e comprovar recuperação utilizável. |
| Latência e dados | Origem, volume, movimentação, retenção, latência e custo de transferência dos dados. | Processamento local, edge ou híbrido pode ser necessário quando dados e operação precisam permanecer próximos. |
| Dependências | Bancos, diretórios, integrações, equipamentos, fornecedores, certificados e rotinas de operação. | Dependências desconhecidas aumentam o risco de interrupção e favorecem descoberta e migração por ondas. |
| Licenciamento | Direito de uso em cloud, mobilidade de licença, suporte, núcleos, contratos e benefícios aplicáveis. | A mesma aplicação pode ter custos muito diferentes conforme contrato e plataforma. A premissa deve ser confirmada antes do business case. |
| Competência operacional | Capacidade de operar segurança, identidade, redes, automação, observabilidade, custos e incidentes. | Sem modelo operacional, a migração troca ativos conhecidos por uma plataforma mais dinâmica e potencialmente menos controlada. |
| Custo previsível | Consumo, crescimento, suporte, equipe, conectividade, backup, transferência, compromissos e variação cambial. | Cloud exige orçamento, alocação e rotina de otimização. Preço por recurso não equivale a custo total. |
| Risco de migração | Janela, coexistência, replicação, testes, retorno, integridade de dados e impacto para usuários. | Quanto maior a criticidade e a incerteza, mais justificável é uma onda piloto com critérios claros de avanço e retorno. |
Arquitetura híbrida não é indecisão
Um ambiente híbrido pode preservar sistemas próximos à operação, usar cloud para backup e disaster recovery, executar novos serviços digitais em nuvem e integrar identidades, redes e monitoramento. Também pode ser uma etapa de transição. Em ambos os casos, precisa ser desenhado como arquitetura permanente enquanto existir, e não tratado como improviso.
A contrapartida é a complexidade. Dois ambientes significam políticas, conectividade, observabilidade, competências e responsabilidades que precisam funcionar em conjunto. Sem padrões de identidade, segurança, endereçamento, logs, custos e continuidade, o híbrido duplica pontos de falha em vez de distribuir risco.
Como avaliar o custo sem criar uma falsa promessa
Uma comparação defensável parte do custo atual e de uma arquitetura futura dimensionada para o mesmo nível de serviço. No ambiente local, entram hardware, suporte, licenças, energia, espaço, conectividade, backup, segurança, renovação e equipe. Em cloud, entram consumo, suporte, licenças, armazenamento, proteção, tráfego, observabilidade, operação, compromissos de uso e crescimento esperado.
A migração também tem custo próprio: descoberta, adequações, testes, ferramentas, transferência de dados, coexistência temporária, treinamento e contingência. Calculadoras oficiais da AWS e da Azure ajudam a modelar preços, mas o resultado depende das premissas informadas. Economia financeira só deve ser afirmada depois de validar inventário, métricas de uso, licenciamento e arquitetura-alvo.
Uma sequência segura para decidir
1. Inventarie por workload
Registre dono, criticidade, usuários, dados, desempenho, licenças, integrações, dependências, incidentes, capacidade e custos. Inventário sem dependências não sustenta uma ordem de migração.
2. Defina o resultado esperado
Explicite se a prioridade é continuidade, velocidade, elasticidade, modernização, expansão, saída de um datacenter ou redução de risco. Objetivos diferentes levam a arquiteturas diferentes.
3. Compare cenários equivalentes
Modele manter, modernizar localmente, migrar, substituir por SaaS e adotar desenho híbrido. Use o mesmo horizonte, nível de serviço, crescimento e escopo de custos em todos os cenários.
4. Valide com uma onda controlada
Escolha workloads representativos, mas reversíveis. Teste desempenho, integração, segurança, backup, recuperação, operação e custo observado antes de ampliar a migração.
5. Aprove por evidência
Defina critérios de avanço, exceção e retorno. O plano deve registrar o que migra, o que permanece, por quê, quem assume a operação e quando a decisão será revista.
O que a experiência prática acrescenta
A experiência da G2C com arquitetura, migração e sustentação em AWS, Azure e ambientes híbridos reforça que o maior risco costuma aparecer nas interfaces: identidade, rede, dados, licenças, monitoramento, backup, responsabilidades e conhecimento concentrado. A tecnologia de destino é apenas parte da mudança.
A frente de Cloud cobre arquitetura, migração e sustentação. A Infraestrutura de TI trata redes, servidores, backup e continuidade. Antes de escolher um destino ou precificar uma migração, o Diagnóstico Executivo organiza dependências, riscos e prioridades para uma decisão comparável.
Conclusão prática
Cloud é adequada quando melhora de forma comprovável a capacidade do negócio e a empresa consegue governar o novo modelo. Não é adequada por princípio, nem precisa receber todos os workloads. Sistemas locais podem continuar sendo a opção correta; ambientes híbridos podem ser o estado-alvo, não apenas uma etapa intermediária.
A decisão madura é específica por workload, compara cenários equivalentes e inclui migração, operação e saída. Se inventário, dependências, licenças, nível de serviço e custos ainda são hipóteses, o próximo passo não é contratar a migração. É realizar um assessment e transformar incerteza em critérios de decisão.
Fontes consultadas
- AWS Prescriptive Guidance — Assess, Mobilize and Migrate: Avaliação de prontidão, business case, TCO, fundações de segurança e operação e migração por etapas.
- Microsoft Cloud Adoption Framework — Assess workloads for cloud migration: Descoberta de componentes, dependências, requisitos, desempenho, segurança, código e bancos antes da migração.
- AWS Pricing Calculator: Modelagem oficial de custos da arquitetura AWS a partir das premissas informadas.
- Azure Pricing Calculator: Estimativa oficial de preços de serviços Azure conforme configuração e consumo previstos.
Quer aplicar isso na sua empresa?
O Diagnóstico Executivo de TI da G2C traduz o cenário atual em prioridades claras, sem compromisso comercial.