O ponto em que migrar deixa de ser opcional
Hardware envelhece, contrato de manutenção sobe, time interno encolhe e o concorrente já está em cloud virando produto em cima do dado. Migrar é a parte difícil — derrubar relatório de CEO durante a transição é o que paralisa o projeto.
- ●Cluster Hadoop on-premise em hardware vencendo contrato
- ●Conta da Oracle Cloud / nuvem atual crescendo acima do retorno
- ●Time interno encolheu, ninguém quer cuidar de cluster físico
- ●Compliance/auditoria pedindo cloud regulamentada
- ●Concorrente migrou e está mais rápido em entrega de dado
O que entregamos
Migração completa em ondas planejadas, com dual-run, validação de hash arquivo a arquivo e contingência por etapa. Plus modernização da arquitetura no destino — não 'levanta igual ao on-prem', moderniza enquanto migra.
Como funciona o projeto
- 01
Assessment (3-4 semanas)
Mapeamento de tabelas, jobs, consumidores e tecnologia. Análise de uso pra identificar tabelas zumbis (em geral 30-50% não tem consulta há > 6 meses).
- 02
Fundação cloud (4-8 semanas)
Storage, IAM, catálogo, engine de query, primeiro pipeline ETL completo. 1 caso de uso de referência rodando ponta-a-ponta.
- 03
Migração em ondas (3-6 meses)
Cada onda tem 4 etapas: copiar dado, validar consistência, apontar consumidores, dual-run de 1-2 semanas.
- 04
Decomissionamento (4-6 semanas)
On-prem desativado onda por onda com backup final em cold storage. Documentação completa no catálogo da cloud.
O que ficou medido
No case da RD Station: 100 TB migrados em ~12 meses, zero downtime visível pra operação, 40% de redução na conta mensal e cluster reduzido de 35 pra 18 servidores no destino. +25% de performance no que ficou.