01 — On-prem → nuvem
Sair do data center
Servidores próprios ou colocation para AWS, Azure, GCP ou Oracle (OCI). Inclusive quando o sistema é antigo e ninguém quer encostar nele.
Migração para a nuvem
Migre o crítico. Sem parar o negócio.
On-premises para a nuvem, ou de uma nuvem para outra. Por partes, com reversão possível a cada etapa, para o sistema que não pode ficar fora do ar nem uma noite.
A migração adiada há anos, pelo motivo certo.
Se o seu sistema crítico ainda roda on-premises, ou preso a uma nuvem que ficou cara, provavelmente não é por falta de vontade. É porque migrar dá medo, e o medo tem fundamento: o sistema não pode parar, o conhecimento sobre ele está concentrado em poucas pessoas e todo mundo conhece uma história de migração que virou projeto de dois anos.
O erro não é adiar. O erro é tratar a migração como um salto único, tudo ou nada, numa madrugada de virada. Migração de sistema crítico se faz como se moderniza sistema crítico: por partes, em produção, com cada etapa reversível.
Como migramos sem big bang.
-
01
Diagnóstico: o que migra, em que ordem, a que custo
Mapeamos o sistema e suas dependências antes de mover qualquer coisa. O que migra como está, o que vale ajustar antes, o que talvez não deva ir. Com estimativa honesta por etapa, inclusive da conta de nuvem que você passará a pagar.
-
02
Migração por partes, em paralelo
Cada módulo atravessa com o ambiente antigo ainda de pé, recebendo tráfego real aos poucos. Se algo se comporta mal, a reversão leva minutos. O negócio não percebe a travessia.
-
03
Otimização: a nuvem do jeito certo
Migrar é a metade do trabalho. Depois vem dimensionar, automatizar e observar, para a infraestrutura custar o que deve e o seu time operar sem depender de nós.
Três travessias que fazemos.
02 — Nuvem → nuvem
Trocar de provedor
Por custo, contrato ou consolidação pós-fusão. Em qualquer direção, inclusive saídas parciais: mover só o que faz sentido.
03 — VM → moderno
Modernizar na travessia
VMs para containers, escala manual para autoescala, logs em arquivo para observabilidade. A migração como oportunidade, não só mudança de endereço.
Casos concretos.
4× a escala
Rastreamento de frota corporativa
Depois de uma fusão, precisava aguentar 4× mais requisições. Refatoramos o core, montamos CI/CD maduro e levamos o sistema para a nuvem: muito mais capacidade, com infraestrutura mais de 3× mais barata que a anterior.
Zero downtime
ERP logístico de 15 anos
Rodava em VMs, com logs em arquivo e deploy manual. Na modernização, trocamos as VMs por containers com autoescala e colocamos observabilidade no lugar, sem parar a operação um único dia.
Perguntas frequentes
O sistema fica fora do ar durante a migração?
O plano é desenhado para que não fique. Migramos por partes, com o ambiente antigo e o novo rodando em paralelo até cada parte provar que funciona. A virada de cada módulo é reversível: se algo se comporta mal, volta-se ao estado anterior em minutos, não em dias.
Vocês fazem lift-and-shift?
Quando é o certo, sim. Para alguns sistemas, replicar como está e evoluir depois é o caminho de menor risco. Mas dizemos com franqueza quando o lift-and-shift só muda o endereço do problema e cria uma conta maior. O plano diz o que migra como está e o que vale ajustar antes.
Também migram de uma nuvem para outra?
Sim. AWS, Azure, Google Cloud e Oracle Cloud (OCI), em qualquer direção, inclusive saídas parciais (mover só o que faz sentido). O motivo costuma ser custo, contrato ou consolidação depois de fusão. O método é o mesmo: por partes, com reversão possível a cada etapa.
E se o sistema for antigo demais para a nuvem?
É raro um sistema não poder ir, mas é comum não valer a pena ir inteiro. Nossa origem é modernização de sistemas legados: quando um módulo precisa de ajuste antes de migrar, fazemos o ajuste, e quando não compensa, dizemos. A migração vira parte do plano de evolução, não um projeto isolado.
Quanto custa e quanto tempo leva?
Depende do tamanho e do acoplamento do sistema. Antes de qualquer proposta fazemos um diagnóstico que entrega o plano faseado com escopo, ordem e estimativa por etapa. Você aprova etapa por etapa, sem assinar um projeto de anos no escuro.
Comece sabendo o que atravessa primeiro.
Uma conversa de 30 minutos, sob NDA, para entender o seu sistema e dizer se há caso.