Como migrar Sankhya para cloud: etapas, banco e JVM
A migração do Sankhya para cloud envolve três componentes distintos com suas próprias complexidades: o dump e restore do banco de dados (Oracle ou SQL Server), a reinstalação e configuração do servidor de aplicação (Tomcat/WildFly) com parâmetros JVM corretos, e a reconfiguração de todas as integrações externas (NF-e, boleto, APIs) que apontam para endereços do ambiente antigo.
Integrações com SEFAZ, bancos e sistemas legados frequentemente têm o IP ou hostname do servidor Sankhya configurado diretamente no parceiro externo. Após a migração, esses parceiros precisam ser atualizados, processo que pode levar dias em sistemas externos.
O arquivo de start do Tomcat no ambiente antigo pode ter customizações de JVM acumuladas ao longo de anos, GC flags, parâmetros de rede, configurações de SSL. Sem documentar antes da migração, o comportamento no destino pode divergir.
Dumps Oracle Data Pump (expdp) têm compatibilidade de versão. Exportar de Oracle 12c e importar em Oracle 19c requer flag COMPATIBLE e pode exigir upgrade do catálogo. Valide a compatibilidade antes de definir o ambiente de destino.
Extraia o conteúdo do setenv.sh (Linux) ou catalina.bat (Windows) com todos os parâmetros JVM. Liste todas as integrações ativas no Sankhya (Configurações > Integrações) com seus endpoints e credenciais.
Execute o dump completo do banco (expdp para Oracle, backup full para SQL Server). Restaure no ambiente de destino e execute a validação de integridade. Para Oracle, valide com VALIDATE STRUCTURE em tabelas críticas.
Instale o servidor de aplicação na mesma versão (ou superior compatível) com os parâmetros JVM documentados. Adicione as melhorias de GC (G1GC, -Xms/-Xmx iguais) que não estavam no ambiente antigo.
No cutover, aplique o dump incremental desde o backup completo, atualize os endpoints das integrações externas e valide os módulos críticos. Mantenha o ambiente antigo operacional por 48 horas como rollback.
A Boreal Tecnologias conduz migrações Sankhya com ambiente de homologação provisionado, suporte técnico na janela de cutover e diagnóstico gratuito. Cloud privada no Brasil, sem câmbio, com SLA 99,99% em reais e dados dentro do território nacional.
Preparação e homologação levam de 3 a 7 dias úteis. O cutover com banco abaixo de 200 GB cabe em uma janela de 4 a 6 horas. Bancos Oracle grandes (acima de 500 GB) podem exigir export incremental prévio para reduzir a janela de downtime.
Sim, o servidor de aplicação Sankhya precisa ser instalado e configurado no ambiente de destino. Não é possível simplesmente copiar os arquivos do Tomcat entre servidores, pois há dependências de caminho, licença e configuração específicas do SO.
Provisione o ambiente de destino com uma cópia do banco de homologação (não o produtivo). Valide todos os módulos usados diariamente, verifique relatórios críticos e teste as integrações de NF-e em modo de homologação SEFAZ. Só então agende o cutover.
Sim, a licença do Sankhya é vinculada ao servidor. Após migrar para uma nova VM, contate o suporte Sankhya ou seu parceiro para reativação. Solicite com antecedência mínima de 2 dias úteis antes do cutover planejado.
Receba um diagnóstico estratégico gratuito e descubra o que está limitando performance, estabilidade e escala hoje.
Sem compromisso. Resposta em até 15 minutos em horário comercial.