Checklist técnico: migrando ERP legado para cloud sem dor

Você acha que tirar um sistema legado do servidor físico e colocar numa cloud é só copiar arquivos e torcer? Engano perigoso. A maioria das migrações de ERP falha não por falta de recursos técnicos, mas por ignorância sobre dependências ocultas e latência de rede. Migrar ERP para a nuvem exige um planejamento cirúrgico. Um erro de configuração de banco de dados ou permissão de arquivo pode derrubar a operação da sua empresa por horas, se não por dias.

A diferença entre uma migração tranquila e um desastre corporativo está nos detalhes que ninguém vê até que o sistema pare. Arquivos temporários, versões específicas de PHP, extensões do kernel do Linux ou até mesmo o fuso horário configurado errado no servidor. Se você é dono de uma PME, gerente de TI ou desenvolvedor responsável por manter esses sistemas rodando, este guia é para você.

Vamos dissecar o processo de migrar ERP sem precisar chamar o suporte a cada dois minutos. Vamos falar sobre infraestrutura, trade-offs reais e como estruturar um ambiente que não apenas funcione, mas que escale quando o negócio crescer. Esqueça a teoria genérica. Aqui é o que funciona no chão de fábrica da infraestrutura.

O que é migrar ERP legado para cloud?

Migrar um ERP legado significa transferir a lógica de negócios, o banco de dados e os arquivos de configuração de um ambiente físico (on-premise) ou de um servidor antigo para uma infraestrutura virtualizada na nuvem. Mas cuidado com a simplificação. Não se trata apenas de "mover caixas". É sobre reconstruir a cadeia de dependências.

Sistemas legados, especialmente os desenvolvidos há mais de 10 anos, muitas vezes foram construídos assumindo que estariam em um ambiente controlado. Eles esperam disco rígido mecânico, latência zero na rede local e acesso root irrestrito. A nuvem não funciona assim. Ela é distribuída, virtualizada e, por padrão, mais restrita em termos de permissões para garantir segurança.

Ao decidir migrar, você ganha elasticidade e redundância, mas perde o controle físico imediato. Isso exige uma mudança de mentalidade. Em vez de consertar o servidor quando ele quebra, você projeta um sistema que não quebra. Ou, pelo menos, recupera-se automaticamente. A infraestrutura moderna exige que você pense em alta disponibilidade desde o primeiro dia, não como um luxo pós-migração.

VPS ou Cloud Dedicada: qual escolher?

Antes de tocar no código ou no banco de dados, você precisa definir onde o ERP vai rodar. A confusão entre VPS (Virtual Private Server) e Cloud Dedicada é o primeiro gargalo de decisão. Ambos usam virtualização, mas a arquitetura por trás é diferente e impacta diretamente a performance do seu ERP.

Muitos profissionais tentam economizar escolhendo uma VPS barata para rodar um ERP crítico. Isso pode funcionar para testes, mas em produção, a "vizinhança" de uma VPS compartilhada pode causar problemas de ruído (noisy neighbor). Se outro usuário na mesma máquina física estiver consumindo muita CPU ou I/O, seu ERP vai sentir. Para um sistema que gerencia financeiro ou estoque, isso é inaceitável.

Aqui está a comparação direta para ajudar na decisão técnica:

Se o seu ERP tem alta frequência de consultas ao banco de dados ou processa grandes relatórios, opte por uma instância com recursos dedicados. A consistência de I/O (Input/Output) é mais importante que o preço mensal. Um ERP lento paralisa vendas. Um servidor caro que funciona é mais barato que um servidor barato que trava.

Checklist técnico: os 5 pilares da migração segura

Para migrar ERP com segurança, você precisa seguir uma ordem lógica. Tentar fazer tudo ao mesmo tempo é receita para o caos. Abaixo, detalhamos os cinco pilares que sustentam uma migração técnica sólida. Siga esta sequência para minimizar riscos.

1. Inventário de Dependências e Auditoria

Antes de instalar qualquer coisa no novo servidor, você precisa saber exatamente o que está rodando no antigo. Não assuma que o PHP 7.4 vai funcionar se o sistema foi feito para o 5.6. Não assuma que o MySQL 8 vai aceitar queries que funcionavam no 5.7.

• Documente todas as extensões do PHP ou Python instaladas.
• Liste as versões exatas do banco de dados e do sistema operacional.
• Verifique se há scripts de cron job (agendados) que rodam diariamente.
• Identifique integrações externas: APIs de pagamento, sistemas de frete, correios.

Essa etapa é chata, mas é onde 80% dos problemas são resolvidos antes de acontecerem. Se você pular isso, vai descobrir no ar que falta uma biblioteca essencial.

2. Preparação do Ambiente (Provisioning)

Não use a configuração padrão. Configure o servidor novo (VPS ou Cloud) para ser espelho do antigo, mas com hardening de segurança. Isso significa:

• Configurar firewall estrito (apenas portas 80, 443 e SSH).
• Configurar o fuso horário corretamente (geralmente America/Sao_Paulo).
• Instalar o stack LAMP/LEMP correspondente (Linux, Apache/Nginx, MySQL/MariaDB, PHP).
• Configurar limites de memória e timeout para evitar crashes sob carga.

Uma dica prática: se você usa Proxmox ou similar para gerenciar sua infraestrutura, crie um template dessa configuração. Assim, se precisar migrar outro sistema ou restaurar, o processo é repetível.

3. Migração de Dados (Backup e Transferência)

Aqui está o coração da migração. Você precisa mover o banco de dados e os arquivos do sistema. O método depende do volume de dados.

Para bancos de dados pequenos (menos de 5GB), um dump SQL direto via linha de comando é suficiente. Use mysqldump ou pg_dump. Para volumes maiores, considere usar ferramentas de transferência de bloco ou sincronização rsync, mas sempre após garantir a integridade dos dados.

"Nunca migre dados enquanto o sistema antigo estiver recebendo novas vendas ou atualizações de estoque. Pare o serviço (maintenance mode) antes de iniciar a cópia." — Regra de ouro da continuidade de negócios.

Após a transferência, importe os dados no novo servidor. Verifique a integridade comparando o número de registros antes e depois. Uma diferença de uma linha pode indicar corrupção.

4. Configuração de Aplicações e Testes Unitários

Com os dados no novo servidor, é hora de configurar o ERP para falar com ele. Atualize os arquivos de configuração (como config.php ou database.yml) com as novas credenciais de acesso ao banco de dados.

Teste o sistema isoladamente. Não o coloque no DNS público ainda. Use o arquivo hosts local ou um IP temporário para acessar o sistema. Verifique:

• Se o login funciona.
• Se os relatórios geram PDF corretamente (problemas comuns com fontes).
• Se as integrações com APIs externas respondem (certificados SSL podem ter mudado).
• Se a performance de leitura e escrita está aceitável.

Se algo falhar, analise os logs de erro. Eles são sua bússola. Erros de permissão (403 Forbidden) são comuns quando o usuário do servidor web (www-data) não tem acesso aos arquivos do ERP. Ajuste as permissões de pasta e arquivos.

5. Cutover e DNS

Quando tudo estiver validado, é hora de colocar no ar. Baixe a TTL (Time To Live) do DNS do domínio antigo alguns dias antes para facilitar o processo. No dia da migração:

1. Pare o serviço no servidor antigo.
2. Faça um último sync incremental de dados (para pegar o que mudou desde o último backup).
3. Atualize o registro A do DNS para apontar para o IP do novo servidor.
4. Aguarde a propagação do DNS (ou use DNS rápido se sua provedora oferecer).
5. Monitore os logs do novo servidor em tempo real.

Esteja preparado para reverter. Tenha o servidor antigo ligado e acessível por mais 48 horas. Se algo crítico falhar, você volta o DNS para o IP antigo e ganha tempo para corrigir sem pressão.

Erros comuns que travam a continuidade de negócios

Quem já migrou ERPs sabe que o diabo mora nos detalhes. Vamos listar os erros que mais causam downtime e como evitá-los.

1. Esquecer de migrar o Cron Job: Muitos ERPs usam agendadores para enviar e-mails, gerar boletos ou sincronizar estoque. Se você só mover os arquivos e o banco, mas esquecer de configurar o cron no novo servidor, esses processos não vão rodar. O sistema parece funcionar, mas as operações automáticas param silenciosamente.

2. Problemas de Certificado SSL: Sistemas legados muitas vezes têm URLs hard-coded com "http://". Ao migrar para a nuvem, onde o HTTPS é padrão, esses links quebram ou causam avisos de conteúdo misto (mixed content). Verifique se o sistema suporta redirecionamento automático ou atualize as configurações para forçar HTTPS.

3. Configuração de Memória e Timeout: Servidores na nuvem têm configurações de segurança padrão que podem ser muito restritivas para ERPs antigos. Por exemplo, o max_execution_time do PHP pode estar baixo para gerar relatórios longos. O memory_limit pode ser insuficiente para carregar grandes planilhas. Aumente esses valores conforme a necessidade do seu software.

4. Ignorar a Latência do Banco de Dados: Se o seu ERP é uma aplicação web que roda em uma VPS, mas o banco de dados está em outro servidor (arquitetura de microsserviços ou cloud gerenciada), a latência pode matar a performance. ERPs monolíticos antigos funcionam melhor quando o banco de dados e a aplicação estão na mesma máquina física ou na mesma rede privada de alta velocidade.

5. Falta de Plano de Rollback: Como mencionado, não tenha medo de voltar atrás. A migração não é um ponto de não retorno. É um experimento controlado. Se o novo servidor apresentar instabilidade, o plano B deve ser acionado imediatamente, sem heroísmo.

Ferramentas e automação: salvando a pele

Manual é propenso a erros. Se você vai migrar ERPs com frequência, invista em automação. Ferramentas como Ansible, Terraform ou scripts bash personalizados podem garantir que o ambiente novo seja idêntico ao antigo, sempre.

Para migrações pontuais, ferramentas de linha de comando são suas melhores amigas. Rsync é excelente para sincronizar arquivos de forma eficiente, mantendo permissões e links simbólicos. Mysqldump é o padrão ouro para exportação de bancos MySQL/MariaDB. Para bancos PostgreSQL, pg_dump é insubstituível.

Além disso, considere o uso de containers (Docker) para isolar a aplicação do ERP. Isso abstrai as dependências do sistema operacional. Se o ERP precisa de uma versão antiga do PHP, você roda um container com aquela versão específica, sem poluir o sistema hospedeiro. Isso facilita muito a migração futura e a recuperação de desastres.

A infraestrutura como código (IaC) não é apenas para gigantes da tecnologia. Para uma PME, um script bem escrito que configura seu servidor VPS em 10 minutos vale o tempo de desenvolvimento. Você elimina a variabilidade humana e garante consistência.

Perguntas frequentes

1. Posso migrar meu ERP legado para uma VPS sem downtime?

Migrar para uma VPS sem nenhum downtime é tecnicamente possível, mas complexo e arriscado para ERPs monolíticos. Envolve sincronização em tempo real de banco de dados e failover automático de DNS. Para a maioria das PMEs, um downtime planejado de 1 a 2 horas é mais seguro e fácil de gerenciar do que tentar uma migração "ao vivo". A chave é comunicar-se bem com os usuários e agendar a migração para horários de baixo tráfego.

2. Meu ERP é muito antigo e roda em Windows Server. Posso migrar para Linux?

Sim, mas com ressalvas. Se o ERP foi desenvolvido para rodar nativamente no IIS e usa tecnologias proprietárias da Microsoft (como .NET Framework antigo ou SQL Server), a migração para Linux exigiria reescrever ou adaptar o sistema, o que é caro e demorado. Nesse caso, o ideal é migrar para uma VM (Máquina Virtual) na nuvem que rode Windows Server, mantendo a mesma arquitetura, mas aproveitando a infraestrutura de cloud para backup e segurança. Não force a migração de plataforma se não for necessário.

3. Como garantir a segurança do meu ERP após a migração?

A segurança começa antes da migração. Atualize o ERP para a última versão estável disponível. Configure um firewall de aplicação (WAF) na frente do servidor. Use senhas fortes e autenticação de dois fatores para acesso administrativo. Mantenha o sistema operacional e o servidor web atualizados. E, acima de tudo, tenha backups automáticos e testados. Segurança é camadas, não uma única solução mágica.

4. O que acontece se a migração falhar?

Se a migração falhar e o novo servidor não estiver funcionando, você deve reverter imediatamente para o servidor antigo. Como você deve ter mantido o antigo ligado e os dados sincronizados (ou pelo menos um backup recente), basta apontar o DNS de volta para o IP antigo. O sistema volta a funcionar como estava. O tempo de recuperação depende da velocidade de propagação do DNS, que pode ser acelerada baixando a TTL antes.

5. Preciso de uma equipe de TI para fazer essa migração?

Não necessariamente uma equipe grande. Um profissional de TI generalista ou um desenvolvedor backend com experiência em servidores pode fazer isso. No entanto, a complexidade aumenta se o ERP for crítico e tiver muitas integrações. Se você não se sente confortável com a linha de comando ou configuração de servidores, contrate um especialista ou use uma provedora de hospedagem gerenciada que ofereça suporte na migração. O custo de um erro é muito maior que o custo de uma consultoria.

Conclusão

Migrar um ERP legado para a cloud não é apenas uma atualização tecnológica; é uma decisão estratégica de negócios. A cloud oferece a escalabilidade e a resiliência que sistemas modernos exigem, mas exige respeito pela complexidade do legado. O sucesso não está na velocidade da migração, mas na precisão do planejamento.

Siga o checklist técnico, respeite as dependências e tenha sempre um plano de contingência. Não tenha pressa na fase de testes. É melhor gastar uma semana testando do que um mês corrigindo problemas em produção. A infraestrutura de hoje deve suportar o crescimento de amanhã, e uma migração bem feita é a base para isso.

Se você está enfrentando dificuldades para estruturar esse ambiente ou precisa de uma infraestrutura de cloud estável e segura para abrigar seu sistema crítico, conte com a expertise da Toda Solução. Oferecemos soluções sob medida para PMEs e profissionais de TI que não querem perder tempo com configurações básicas e querem focar no que realmente importa: o crescimento do seu negócio.