Migração para nuvem
O que entregamos, como funciona e o que isso traz para a operação.
ARTIGO · INFRAESTRUTURA
Levar o que existe para a nuvem sem mudar nada costuma sair mais caro que o servidor que estava lá. Este texto separa os tipos de migração, mostra onde o custo escapa e dá os critérios para decidir o que vai, o que fica e o que precisa ser reescrito antes.
Nuvem não é mais barata por natureza. Ela troca custo fixo por custo variável, e o resultado depende inteiramente de o que você leva e de como.
Um sistema desenhado para servidor dedicado, movido sem alteração, continua consumindo recurso como se estivesse em servidor dedicado — só que agora a conta é medida por hora e por gigabyte trafegado. Esse é o cenário em que a migração aumenta o custo.
Há um dado de mercado que ajuda a calibrar a expectativa. A pesquisa anual do setor mede há anos o desperdício declarado pelas próprias organizações em gasto de nuvem — ou seja, é problema conhecido e persistente, não novidade de quem migrou mal.
| Tipo | O que acontece | Quando faz sentido |
|---|---|---|
| Mover como está | A máquina virtual sobe igual na nuvem | Data center saindo do ar, prazo curto, sistema estável que será tratado depois |
| Mover com ajuste | Troca de banco por serviço gerenciado, ajuste de tamanho de máquina | Ganho rápido de operação sem tocar no código |
| Reescrever para a nuvem | A aplicação passa a usar serviços gerenciados e a escalar por demanda | Sistema com variação forte de uso, ou que precisa crescer |
| Substituir por serviço pronto | O sistema é trocado por um software de mercado | Processo que não é diferencial da empresa |
| Aposentar | O sistema simplesmente sai | Mais comum do que parece: no inventário sempre aparece algo que ninguém usa há anos |
O erro clássico é tratar a migração como um projeto de um tipo só. Num parque real, os cinco convivem — e a decisão é por sistema, não por empresa.
Cinco linhas que quase nunca entram na estimativa inicial e que, somadas, costumam ser a diferença entre a conta prevista e a real.
Nenhuma dessas linhas é armadilha do fornecedor: todas estão na tabela de preço. Elas escapam porque a estimativa foi feita comparando o preço da máquina, e não o modelo de consumo.
Ser honesto sobre isso é o que torna a recomendação confiável quando ela é a favor.
Não vale quando a carga é constante e previsível, o hardware está pago e ainda em suporte, não há necessidade de escalar e o sistema não precisa mudar. Nesse caso, a nuvem cobra elasticidade que ninguém vai usar.
Não vale ainda quando o sistema é legado a ponto de não poder ser alterado com segurança. Mover para a nuvem um sistema que ninguém consegue mexer entrega o mesmo problema em outro endereço, com fatura variável. Aqui a ordem correta é inversa: modernizar primeiro, migrar depois — ou migrar como está apenas se houver prazo forçando, sabendo que é medida temporária.
Vale quando há variação real de demanda; quando o parque de hardware está no fim da vida e a alternativa é comprar servidor novo; quando a operação precisa de recuperação de desastre que não existe hoje; ou quando o sistema vai ser reescrito de qualquer forma — aí nascer na nuvem custa o mesmo que nascer fora.
Onde o dado fica. Região de processamento e armazenamento tem efeito jurídico, não só técnico. Dado pessoal em região fora do país aciona as regras de transferência internacional da LGPD.
Como se volta. A pergunta que quase ninguém faz antes: se em dois anos a decisão for sair desse provedor, o que precisaria ser refeito? Quanto mais serviço gerenciado específico do fornecedor, mais cara é a saída. Não é motivo para evitá-los — é motivo para saber o preço da escolha.
Quem opera depois. Nuvem não elimina operação; muda a natureza dela. Alguém precisa acompanhar consumo, revisar tamanho de máquina e aplicar política de expurgo. Sem esse alguém, o desperdício vira permanente.
Qual é a linha de base. Antes de migrar, meça o custo atual completo — hardware amortizado, energia, licença, suporte e horas de operação. Sem essa linha, qualquer conta depois será discussão de opinião.
O princípio é o mesmo de qualquer modernização: por partes, com como voltar previsto.
Comece pelo que tem menos acoplamento — ambiente de teste, sistema interno de baixo risco, serviço isolado. Mantenha o legado no ar enquanto o novo recebe tráfego crescente por percentual. Meça latência, erro e custo em cada etapa. E mantenha a possibilidade de retorno ativa até a etapa seguinte estar estável, não até o projeto acabar.
A parte que costuma ser esquecida é a última: desligar o que ficou para trás. Migração pela metade é o pior dos dois mundos — paga-se a nuvem e o servidor antigo ao mesmo tempo, às vezes por anos.
O que entregamos, como funciona e o que isso traz para a operação.
Reengenharia por partes, com o sistema no ar.
Por que o sistema obsoleto parece o mais econômico do parque.
Trinta minutos para levantar a linha de base atual e dizer o que vale mover, o que vale reescrever e o que vale deixar onde está.
Respondemos em até 1 hora útil. Confirmação no mesmo dia útil.