Como migrar o servidor local da empresa para a nuvem

O servidor fica numa sala ao lado do financeiro, às vezes num armário. Ele roda o ERP, o banco de dados, o compartilhamento de arquivos, um sistema feito sob medida há anos, a rotina de backup e alguma coisa que ninguém lembra quem instalou. O no-break aguenta pouco, a garantia do hardware venceu, e a pessoa que configurou tudo não trabalha mais na empresa.

Migrar para a nuvem resolve boa parte desses riscos, mas a migração em si é um projeto com riscos próprios. O erro mais comum é tratá-la como uma mudança única, "tirar tudo do servidor e colocar na nuvem" num fim de semana. O caminho mais seguro é tratar a migração como um portfólio: cada sistema recebe a estratégia que faz sentido para ele, numa ordem definida por risco e dependências, com ensaio e plano de volta. Este texto mostra como.

O que está rodando naquele servidor, de verdade

Ninguém migra com segurança o que não conhece. O primeiro passo é um inventário honesto, que quase sempre revela surpresas:

• Aplicações: ERP, sistemas próprios, sistemas de terceiros, ferramentas de BI, serviços de impressão, controle de ponto.
• Bancos de dados: qual tecnologia, qual versão, qual tamanho, quem acessa.
• Arquivos: compartilhamentos de rede, quanto espaço ocupam, quem usa, com que permissões.
• Serviços de infraestrutura: controlador de domínio e autenticação de usuários, DNS interno, DHCP, servidor de impressão, VPN.
• Rotinas agendadas: backups, integrações que rodam de madrugada, scripts de importação e exportação, envio de arquivos para bancos e prefeituras.
• Dependências: quem fala com quem. O sistema próprio lê o banco do ERP diretamente? A integração com o banco depende de um certificado instalado na máquina?
• Licenças: o que está licenciado por servidor, por núcleo de processador, por usuário.
• Uso real: consumo de processador, memória, disco e rede ao longo de um período representativo, incluindo fechamento de mês.

As dependências são o ponto crítico. Uma rotina esquecida que roda uma vez por mês pode ser justamente a que gera o arquivo de pagamento para o banco. O inventário precisa incluir conversas com as áreas, não só a leitura do servidor.

Uma estratégia por aplicação, não uma para tudo

Com o inventário pronto, cada item recebe uma estratégia. As opções mais usadas:

Na prática, uma migração típica combina várias: os arquivos vão para uma solução de armazenamento na nuvem com controle de acesso, o controlador de domínio dá lugar a um provedor de identidade em nuvem, o banco vai para um serviço gerenciado, o ERP vai como está para uma máquina virtual, e aquele sistema que ninguém usa é desligado.

A escolha do provedor (AWS, Google Cloud ou Azure) importa menos do que parece para a maioria das empresas. Os três têm região no Brasil, serviços equivalentes para o que uma empresa média precisa, e programas de migração. Critérios práticos: ferramentas que a empresa já usa (um ambiente Microsoft tende a ir para Azure com menos atrito), exigências do fornecedor do ERP e familiaridade de quem vai operar.

Rede, VPN, identidade e quem continua no escritório

As pessoas continuam trabalhando no escritório, na fábrica ou em casa. O que muda é que os sistemas passam a estar longe.

Latência. Aplicações web toleram bem a distância. Sistemas desktop antigos, em que cada tela faz dezenas de consultas diretas ao banco, podem ficar lentos quando o banco vai para a nuvem e o programa fica no computador do usuário. As soluções variam: publicar a aplicação por acesso remoto, colocando programa e banco lado a lado na nuvem, ou modernizar o sistema, como discutimos em migrar sistema desktop para web. Teste com usuários reais antes do corte.

Conectividade. Uma VPN site a site entre o escritório e a nuvem mantém a comunicação com o que fica local, como impressoras, relógios de ponto e equipamentos de produção. O link de internet do escritório passa a ser crítico, e um link redundante costuma deixar de ser luxo.

Identidade. Se os usuários se autenticam num controlador de domínio local, é preciso decidir como isso fica: estender para a nuvem, migrar para um provedor de identidade em nuvem ou um modelo híbrido durante a transição. Aproveite para ativar autenticação em dois fatores.

Equipamentos locais. Balanças, impressoras fiscais, leitores e máquinas de produção que conversam com o servidor precisam de atenção individual.

Licenças, backup e segurança desde o primeiro dia

Licenças. Licenças de sistema operacional, banco de dados e alguns ERPs têm regras específicas para uso em nuvem, que variam por fabricante e por provedor. Uma licença perpétua comprada para servidor físico nem sempre pode ser levada para a nuvem. Verifique com os fabricantes e, se necessário, com um especialista em licenciamento antes de decidir a estratégia de cada sistema.

Backup. A nuvem não faz backup sozinha do que é seu. É preciso configurar cópias automáticas, com retenção definida, em conta ou região separada, e testar a restauração periodicamente. Backup nunca restaurado é hipótese. Os conceitos de objetivo de tempo e de ponto de recuperação, e como planejar para o pior dia, estão em plano de recuperação de desastres.

Segurança. Na nuvem, a segurança da infraestrutura física é do provedor; a configuração é sua. Os incidentes mais comuns vêm de configuração: banco de dados exposto à internet, armazenamento de arquivos público, acesso administrativo sem segundo fator. O mínimo desde o primeiro dia:

• contas administrativas com autenticação em dois fatores e acesso mínimo;
• nenhum banco ou servidor de acesso remoto exposto diretamente à internet;
• redes privadas e regras de acesso restritivas;
• criptografia em repouso e em trânsito;
• registro de ações administrativas ativado;
• alertas de gasto e de configuração arriscada.

Migração de dados e a janela de corte

A migração de dados define a janela de corte, o período em que o sistema fica indisponível.

• Bancos pequenos podem ser copiados por backup e restauração dentro de uma janela noturna ou de fim de semana.
• Bancos grandes exigem replicação: o banco na nuvem é sincronizado com o local durante dias, e no corte só falta aplicar as últimas alterações.
• Arquivos podem ser sincronizados antecipadamente, com uma sincronização final no corte.

A janela deve evitar períodos críticos: fechamento de mês, folha de pagamento, pico de vendas, obrigações fiscais com prazo. Combine com as áreas e comunique com antecedência.

Ensaio, plano de volta e validação pós-corte

Ensaio. Antes do corte real, faça pelo menos um ensaio completo: migrar os dados, subir os sistemas na nuvem, validar e medir quanto tempo levou. O ensaio revela as dependências esquecidas e dá uma estimativa realista da janela.

Roteiro de validação. Uma lista de verificações por sistema, feita pelas áreas usuárias: emitir uma nota fiscal de teste, lançar um pedido, gerar o arquivo de pagamento, imprimir uma etiqueta, acessar os arquivos compartilhados. Critérios de sucesso definidos antes, não durante o corte.

Plano de volta. Se algo crítico falhar, como voltar ao servidor local? Enquanto o plano de volta não foi testado, ele não existe. Defina também o ponto de não retorno: a partir de quando as alterações feitas na nuvem tornam a volta mais arriscada do que seguir em frente e corrigir.

Pós-corte. Mantenha o servidor antigo desligado, mas disponível, por um período. Acompanhe desempenho, erros e reclamações de perto nos primeiros dias. Monitoramento com logs e métricas desde o início permite enxergar problemas antes dos usuários, como mostramos em observabilidade: logs, métricas e traces.

Custo recorrente sob controle desde o primeiro mês

A nuvem troca investimento em hardware por custo mensal, e esse custo precisa de gestão. Os erros mais comuns: dimensionar as máquinas na nuvem igual ao servidor antigo (que estava superdimensionado para durar anos), esquecer ambientes de teste ligados, não definir política de retenção para backups e logs, e não considerar o custo do tráfego de saída.

Desde o primeiro mês:

• etiquetas por sistema e ambiente em todos os recursos;
• orçamento e alertas de gasto;
• dimensionamento revisado com base no uso real, depois de algumas semanas de operação;
• desligamento de ambientes de teste fora do horário de uso;
• avaliação de compromissos de uso quando o consumo se estabilizar.

As técnicas de otimização estão em detalhe em como reduzir custos de nuvem.

Erros comuns

• Migrar sem inventário e descobrir a rotina esquecida no primeiro fechamento de mês.
• Uma estratégia só para tudo.
• Ignorar a latência de sistemas desktop antigos.
• Não verificar licenças antes de decidir.
• Cortar sem ensaio e sem plano de volta testado.
• Copiar o dimensionamento do servidor antigo.

Checklist da migração

• Inventário de aplicações, dados, rotinas, dependências e licenças.
• Estratégia definida por aplicação.
• Rede, VPN, identidade e equipamentos locais resolvidos.
• Backup configurado e restauração testada.
• Segurança mínima aplicada antes do primeiro dado subir.
• Ensaio completo, roteiro de validação e plano de volta testado.
• Janela de corte acordada com as áreas.
• Etiquetas, orçamento e alertas de custo ativos.

Da sala do servidor para a nuvem, sem sustos

A Pervian Tech planeja e executa migrações para a nuvem no nosso trabalho de cloud e DevOps: inventário, estratégia por aplicação, segurança, backup, ensaio de corte e acompanhamento de custos depois da virada. Cada migração é sob medida, porque cada servidor esconde uma história diferente.

Começamos por um diagnóstico inicial gratuito do seu ambiente atual. A partir dele definimos as fases, a ordem das aplicações e o investimento, que é sob consulta. Se o seu servidor está chegando ao fim da vida, conte o que roda nele hoje.