Migração para nuvem, com a conversa honesta antes do projeto

Tirar o servidor da sala e colocar na nuvem resolve muita coisa — e cria problema novo quando é feito pelo motivo errado. Avaliamos o seu caso, dizemos se vale a pena, e se não valer dizemos isso também.

Falar sobre migração

Quando migrar vale a pena — e quando não vale

Nuvem não é destino obrigatório. É uma escolha de arquitetura que resolve certos problemas e cria outros. A pergunta certa não é se a nuvem é melhor: é o que você está tentando resolver.

Costuma valer quando

O servidor chegou ao fim da vida e a alternativa é desembolsar hardware novo agora.
A empresa tem gente trabalhando fora do escritório e o acesso remoto virou gambiarra.
Existem filiais ou obras que precisam do mesmo sistema.
A operação cresce e encolhe no ano, e dimensionar hardware pelo pico é desperdício.
O ambiente atual não tem redundância nenhuma: um servidor, um disco, uma sala sem clima.
A empresa precisa de continuidade e hoje uma falha de hardware significa dias parados.

Costuma não valer quando

O servidor é novo, está pago e atende bem a operação atual.
O link de internet é único, instável, e não há orçamento para redundância.
O sistema principal é legado e sensível a latência, sem caminho de publicação viável.
A operação depende de equipamento físico local — máquina de produção, balança, coletor, CFTV pesado.
O volume de arquivos é enorme e o uso é intenso e local o dia inteiro.
A motivação é só modernizar, sem um problema concreto para resolver.

Em parte dos diagnósticos que fazemos, a recomendação é manter o servidor local e melhorar o que está fraco em volta dele: backup com cópia fora da empresa, redundância de disco, nobreak decente e monitoramento. Fica mais barato, resolve o risco real e não quebra a operação. Dizer isso custa uma venda e ganha um cliente.

Os três modelos de migração

A escolha define custo, prazo e risco. Quase sempre a resposta certa para PME é a menos glamourosa.

Lift-and-shift

O servidor vai como está para uma máquina virtual na nuvem. É o caminho mais rápido e de menor risco, porque o sistema continua sendo o mesmo. Em compensação, você leva junto os vícios do ambiente antigo e não colhe as vantagens de custo de um desenho feito para nuvem. Para a maioria das PMEs, é por aqui que se começa.

Reconstrução

O serviço é refeito usando recursos gerenciados: banco como serviço, armazenamento de objetos, e-mail e arquivos em plataforma de produtividade. Dá o melhor resultado em custo e resiliência, mas exige projeto, tempo e muitas vezes mexer no sistema. Vale quando o software permite ou quando já se pretendia trocar.

Híbrido

Parte vai, parte fica. O ERP legado e o que depende de equipamento físico continuam locais; e-mail, arquivos, backup e sistemas web vão para a nuvem. É o desenho mais comum na prática, porque respeita a realidade da empresa em vez de forçar um modelo único.

O que costuma dar errado

O custo que sobe depois do terceiro mês

A estimativa é feita com a máquina ligada oito horas por dia e o ambiente acaba ligado o tempo todo. O disco é dimensionado para hoje e cresce sem ninguém acompanhar. Cobrança por tráfego de saída aparece só quando o uso real começa. Backup e ambiente de teste entram como linha nova. A migração não encareceu: a estimativa é que foi otimista. Por isso trabalhamos com projeção baseada em uso medido, com os itens de custo separados, e revisamos a fatura nos primeiros meses.

Link de internet subdimensionado

Com o servidor local, o tráfego pesado ficava dentro da rede interna. Depois da migração, tudo passa pelo link. Se ele estava justo antes, vai estrangular depois. E a falha deixa de ser incômodo e vira parada total: sem link, ninguém trabalha. Medir consumo antes e planejar redundância de operadora não é luxo nesse cenário.

Aplicação legada que não suporta latência

Sistema escrito para rede local costuma fazer muitas conversas curtas com o banco de dados. Cada conversa que antes levava um instante passa a levar alguns milissegundos a mais, e o efeito se multiplica por milhares de chamadas em uma única tela. O usuário sente a diferença no primeiro dia. Isso se testa antes, com gente de verdade usando o sistema, não com ping.

Licenciamento esquecido

Nem toda licença adquirida para servidor físico acompanha a máquina para a nuvem, e as regras variam por fabricante e por modalidade. Descobrir isso depois do corte é caro. Levantamento de licença faz parte do inventário inicial.

Backup que não migrou junto

A rotina de backup apontava para um disco que ficou na empresa. O servidor mudou de endereço e o job continuou rodando contra o nada, ou parou de rodar sem alarme. Toda migração precisa terminar com a proteção do novo ambiente testada, não presumida.

Nuvem sem quem olhe

Servidor na nuvem não se administra sozinho. Ele continua precisando de atualização, monitoramento, controle de acesso e resposta quando algo cai de madrugada. Terceirizar o data center não terceiriza a operação.

Como fazemos o corte com parada mínima

1. Inventário e medição

O que roda hoje, em qual máquina, com qual consumo real de processamento, memória, disco e rede. Quais integrações existem, quais licenças estão em jogo e quem usa o quê em qual horário. Sem esse número, qualquer dimensionamento é chute e qualquer orçamento é ficção.

2. Desenho e projeção de custo

Definição do modelo — lift-and-shift, reconstrução ou híbrido — e a projeção mensal com os itens separados: computação, armazenamento, backup, tráfego e o que mais entrar. Você vê a conta antes de decidir.

3. Ambiente espelho

O ambiente novo sobe em paralelo, com o ambiente antigo intocado e em produção. Os dados são copiados uma primeira vez com antecedência, e depois mantidos sincronizados de forma incremental até o corte.

4. Teste com usuário real

Gente da operação usa o ambiente novo antes do corte, executando as tarefas do dia a dia. É aqui que aparece o relatório que demora, a impressora que não responde, a integração que ninguém tinha mencionado. Encontrar isso agora é barato.

5. Janela de corte

Em horário combinado, a última sincronização, o apontamento e a validação em roteiro. Cada etapa tem responsável e horário previsto, e existe um ponto de decisão definido: se até tal hora tal item não estiver validado, o plano de retorno é acionado.

6. Observação e ajuste

Nas primeiras semanas, acompanhamento de perto: desempenho, custo real contra o projetado, backup do novo ambiente testado e o ambiente antigo preservado desligado. Só depois desse período ele é desmontado.

O que muda no custo: o investimento vira mensalidade

Antes: desembolso grande de uma vez

Servidor, discos, nobreak, licença, contrato de garantia. Tudo pago no início, depreciado ao longo dos anos, dimensionado pelo pico que talvez nunca venha e substituído inteiro quando o ciclo acaba.

Depois: custo recorrente e ajustável

Mensalidade proporcional ao que está ligado e ao que está armazenado. Dá para aumentar quando a operação cresce e reduzir quando encolhe, sem comprar nem revender hardware.

Essa troca tem uma consequência que pouca gente comenta: o custo fica visível todo mês. O servidor comprado há quatro anos não aparece em lugar nenhum no orçamento atual, mesmo que esteja consumindo energia, manutenção e horas de quem o cuida. A fatura de nuvem aparece. Isso é bom para gestão, mas exige alguém acompanhando — o ambiente que ninguém revisa engorda sozinho.

Também muda a natureza do risco. No modelo local, o risco é concentrado e silencioso: um disco que falha, uma queda de energia longa, um roubo. Na nuvem, o risco se desloca para o link, para a configuração de acesso e para a conta que administra o ambiente. Nenhum dos dois é isento; são riscos diferentes, e cada um exige um controle diferente.

Vale ler também sobre infraestrutura de rede para empresas, que é o que sustenta qualquer ambiente em nuvem, o backup em nuvem corporativo e o NOC 24x7, que monitora o ambiente depois que ele sai da sua sala.

Perguntas Frequentes sobre migração para nuvem

Migrar para a nuvem sai mais barato?

Nem sempre, e quem promete isso sem olhar o ambiente está adivinhando. A nuvem troca investimento por mensalidade: você deixa de comprar servidor, nobreak, licença e contrato de garantia, e passa a pagar por uso. Em ambiente com demanda variável, com equipe distribuída ou com hardware chegando ao fim da vida, a conta costuma fechar bem. Em ambiente estável, com servidor novo já pago e uso previsível o ano inteiro, a conta pode ficar pior. O que muda de verdade é a natureza do custo, não necessariamente o valor. A comparação honesta soma tudo: máquina, energia, licença, backup, link de internet, horas de manutenção e o custo de ficar parado quando algo quebra.

Quanto tempo o sistema fica fora do ar na migração?

O objetivo é que a parada seja uma janela planejada, geralmente de madrugada ou em fim de semana, e não um período aberto. Isso é possível porque a maior parte do trabalho acontece antes: o ambiente novo é montado e testado em paralelo, os dados são copiados com antecedência e depois sincronizados de forma incremental. Na janela de corte, só resta a última sincronização, o apontamento e a validação. Para arquivos e sistemas de gestão de porte médio, isso costuma caber em poucas horas. Sistema com banco muito grande ou com integração externa complexa exige janela maior e um plano de retorno claro, que sempre definimos antes de começar.

Minha internet aguenta tudo rodando na nuvem?

Essa é a pergunta certa e é onde a maioria dos projetos tropeça. Quando o servidor sai de dentro da empresa, cada acesso a arquivo e cada tela do sistema passam a depender do link. Antes de migrar, medimos o que a operação consome, quantos usuários simultâneos existem e qual é o perfil de uso. Também olhamos o que quase ninguém olha: se existe um segundo link de operadora diferente, porque com o servidor na nuvem o link deixa de ser conveniência e vira infraestrutura crítica. Empresa com um link só e sem redundância não deveria migrar tudo antes de resolver isso.

Dá para voltar atrás se der errado?

Dá, desde que o plano preveja isso desde o início. Nós mantemos o ambiente original intacto e desligado, sem apagar nada, por um período combinado depois do corte — normalmente algumas semanas de observação. Se aparecer um problema que não dá para resolver no ambiente novo, o retorno é uma decisão operacional, não uma reconstrução. Migração sem plano de retorno é aposta, e nós não trabalhamos assim.

Meu ERP antigo roda em nuvem?

Depende de como ele foi escrito. Sistema que conversa com o banco de dados por muitas idas e vindas curtas sofre com latência: o que era instantâneo na rede local vira lento quando cada resposta atravessa a internet. Muitos sistemas de gestão legados brasileiros são exatamente assim. Existem caminhos — publicar o sistema em terminal remoto, colocar aplicação e banco na mesma região da nuvem, ou manter esse sistema local num modelo híbrido. O que não existe é levar o servidor para a nuvem sem testar e torcer. Teste com usuário real antes do corte é parte do projeto, não um extra.

Guias sobre infraestrutura e nuvem

Ver todos os artigos do blog →

Comece pela análise de viabilidade

Levantamos o seu ambiente, medimos o uso real e apresentamos a projeção de custo junto com a recomendação. Se o melhor caminho for continuar com o servidor local e arrumar o que está em volta, é isso que a gente vai dizer.

Pedir análise de viabilidade

Contato Rápido

Fale com a VNC TEC

Está com alguma dúvida ou precisa de uma solução personalizada em TI? Envie sua mensagem e nossa equipe retornará em até 1h útil.