Migração do Protheus para Nuvem: Guia Seguro

O que envolve migrar o Protheus para a nuvem

A migração do Protheus para nuvem transfere uma carga de trabalho empresarial composta por aplicação, banco de dados, arquivos, licenciamento, integrações e rotinas operacionais. Não é apenas copiar uma máquina virtual. Para funcionar com segurança, o projeto precisa mapear dependências, dimensionar capacidade com dados reais, construir o ambiente de destino, ensaiar a transferência, validar processos de negócio e preparar uma reversão viável.

O resultado esperado também deve ser explícito. A empresa pode buscar renovar infraestrutura, melhorar recuperabilidade, ampliar capacidade, padronizar operação ou substituir custos de capital por consumo recorrente. A nuvem não entrega esses benefícios automaticamente: uma arquitetura inadequada pode aumentar latência, custo e complexidade.

A documentação oficial sobre Protheus em provedor de nuvem apresenta arquiteturas em nuvens públicas e destaca escalabilidade e escolha de região próxima para reduzir latência. Use essa referência como ponto de partida, mas confirme sempre as plataformas e versões homologadas para o ambiente real.

Quando a migração faz sentido

A decisão deve partir do problema, não da tendência tecnológica. Há um caso mais consistente quando existe uma ou mais destas condições:

• hardware próximo do fim de suporte ou sem capacidade de expansão;
• recuperação lenta, backups não testados ou ponto único de falha;
• dificuldade para criar ambientes de homologação e contingência;
• crescimento sazonal que exige capacidade variável;
• unidades remotas com acesso instável à infraestrutura central;
• operação dependente de poucas pessoas e procedimentos manuais;
• necessidade de melhorar rastreabilidade, segurança ou padronização.

Também há cenários em que convém adiar. Se customizações são desconhecidas, o banco apresenta inconsistências, não existe inventário de integrações ou a organização está em um fechamento crítico, mover o ambiente apenas transporta riscos. Primeiro estabilize a linha de base e defina o que precisa ser corrigido antes, durante ou depois da migração.

Uma avaliação de TI pode organizar essas evidências e separar requisitos de negócio de preferências técnicas.

Mapeie a arquitetura antes de escolher a nuvem

O inventário precisa mostrar como uma transação percorre o ambiente. Conforme o cenário, registre:

• release, binários, LIB, RPO, dicionário e componentes do Protheus;
• AppServers, brokers, portas, serviços, ambientes e arquivos de configuração;
• DBAccess, banco, drivers, aliases, volumes, crescimento e rotinas de manutenção;
• License Server e dependências de conectividade;
• diretórios de dados, documentos, relatórios, temporários e compartilhamentos;
• SmartClient, WebApp, WebAgent, impressão e acesso remoto;
• jobs, agendamentos, filas e processamento em lote;
• APIs, arquivos, mensageria, portais, bancos, dispositivos e sistemas externos;
• certificados, segredos, contas técnicas, regras de firewall e DNS;
• monitoração, logs, backups e procedimentos de recuperação.

A página oficial do TOTVS DBAccess explica seu papel de conectividade entre aplicações TOTVS e bancos homologados. Na migração, essa camada deve ser analisada junto ao banco, à rede e ao AppServer; tratá-la isoladamente pode esconder gargalos e incompatibilidades.

Desenhe as dependências e identifique seus responsáveis. Uma integração pouco documentada, uma impressora fiscal, um compartilhamento ou uma regra de saída por IP pode impedir o go-live mesmo quando o ERP abre normalmente.

Escolha o modelo de destino pelo nível de responsabilidade

“Nuvem” pode significar oferta gerenciada do fabricante, infraestrutura como serviço em provedor público, ambiente privado ou arquitetura híbrida. Compare o que cada alternativa inclui:

O NIST define computação em nuvem como acesso sob demanda a recursos configuráveis que podem ser provisionados e liberados rapidamente, com características e modelos distintos. Consulte a definição de cloud computing do NIST para evitar comparar ofertas diferentes como se fossem equivalentes.

Dimensione com medições, não apenas com usuários

Quantidade de usuários é um indicador insuficiente. Colete uma linha de base em períodos normais e de pico:

• CPU, memória e concorrência por serviço;
• sessões simultâneas e duração das operações;
• latência entre aplicação e banco;
• volume, crescimento, IOPS e throughput de armazenamento;
• tempo de consultas, fechamentos, relatórios e jobs;
• tráfego de integrações e transferência de arquivos;
• janelas de backup e tempo real de restauração;
• disponibilidade, erros e filas atuais.

O destino deve suportar o pico relevante e permitir crescimento sem criar desperdício permanente. Faça testes com dados e concorrência representativos. Uma rotina que funciona com poucos registros na homologação pode degradar quando encontra o histórico completo.

Registre os indicadores atuais antes da mudança. O artigo sobre performance do Protheus mostra como separar sintomas por cliente, rede, AppServer, DBAccess, banco, customização e job. Essa linha de base evita atribuir à nuvem problemas que já existiam — ou aceitar regressões por falta de comparação.

Rede e latência são parte da aplicação

Na nuvem, distância e caminho de rede influenciam a experiência. Meça latência, perda, estabilidade e largura de banda entre usuários, filiais, integrações e região escolhida. Considere VPN, conexão dedicada, redundância de operadoras, DNS, proxies, regras de saída e acesso administrativo.

A orientação da Microsoft para planejar uma migração recomenda localizar dependências, agrupar componentes relacionados, mover ambientes não produtivos primeiro e definir o caminho de transferência de dados conforme volume e conectividade. Esses princípios são independentes do provedor e ajudam a reduzir períodos híbridos frágeis.

Se aplicação e banco dependem de comunicação frequente, colocá-los em regiões ou redes distantes pode adicionar atraso a cada operação. A arquitetura deve minimizar percursos desnecessários e preservar acesso seguro às dependências que permanecerem locais.

Segurança começa na zona de destino

Antes de receber o ERP, a conta ou assinatura de nuvem deve ter uma base operacional:

• identidades individuais, autenticação forte e menor privilégio;
• separação entre produção, homologação e administração;
• redes segmentadas e exposição pública mínima;
• criptografia em trânsito e em repouso conforme risco;
• segredos fora de código e arquivos compartilhados;
• logs centralizados, alertas e retenção definida;
• políticas de atualização e gestão de vulnerabilidades;
• tags, orçamento, responsáveis e trilha de mudanças.

Não presuma que o provedor administra todas as camadas. Responsabilidades variam entre serviço gerenciado e máquinas virtuais. Documente quem protege sistema operacional, banco, aplicação, dados, identidades, cópias e integrações. A governança e compliance deve acompanhar o desenho técnico desde o início, principalmente quando o ERP trata dados pessoais, financeiros ou fiscais.

Backup, alta disponibilidade e desastre são decisões diferentes

Backup preserva cópias; alta disponibilidade reduz interrupções de determinados componentes; recuperação de desastre restabelece a operação após um evento grave. Uma solução não substitui automaticamente a outra.

Defina RPO, a perda máxima de dados tolerável, e RTO, o tempo aceitável para recuperar o serviço. Depois, projete retenção, imutabilidade quando aplicável, cópia em domínio de falha separado e testes de restauração. O guia de confiabilidade do AWS Well-Architected Framework enfatiza fundações sólidas, arquitetura resiliente, gestão consistente de mudanças e recuperação comprovada.

Teste não só a restauração do banco, mas a reconstrução coerente do serviço: versões, configurações, RPO, arquivos, certificados, integrações e ordem de inicialização. Para aprofundar o tema, veja o guia de disaster recovery em nuvem.

Migração do Protheus para nuvem em oito etapas

1. Defina objetivos e critérios

Registre motivação, escopo, responsáveis, restrições, orçamento, RPO, RTO, janela e métricas de sucesso. Identifique períodos fiscais, contábeis, de folha e de faturamento que não podem ser interrompidos.

2. Crie o inventário e a linha de base

Mapeie componentes, customizações, integrações, dados, acessos e desempenho. Classifique dependências críticas e itens desconhecidos.

3. Desenhe e aprove a arquitetura

Escolha região, redes, serviços, capacidade, armazenamento, segurança, backup, monitoração e responsabilidades. Calcule custo mensal em cenários normal e de pico.

4. Construa primeiro a não produção

Implemente a zona de destino e migre desenvolvimento ou homologação. Valide conectividade, automações, permissões e observabilidade antes de envolver produção.

5. Migre uma cópia e homologue

Restaure dados controlados, instale componentes compatíveis, aplique configurações e teste processos completos. Proteja dados pessoais usados na homologação e restrinja acessos.

6. Ensaie a virada

Execute o roteiro com cronômetro: congelamento, cópia ou sincronização, validações, abertura e retorno. Registre duração, erros, responsáveis e melhorias. Repita até caber na janela.

7. Faça o cutover com decisão de go/no-go

Use checklist, canal de comunicação e autoridade clara para prosseguir ou reverter. Preserve logs e evidências. Não improvise alterações paralelas durante a janela.

8. Estabilize e encerre

Monitore processos críticos, integrações, filas, desempenho, custos e segurança. Mantenha operação assistida, atualize documentação e desative o ambiente antigo somente após cumprir critérios de retenção e retorno.

Testes que devem bloquear a entrada em produção

O aceite não pode se limitar ao login. Cubra:

• pedidos, estoque, compras, faturamento, financeiro, fiscal, contábil, RH ou produção conforme o uso;
• cancelamentos, estornos, exceções e autorizações;
• relatórios, impressão, arquivos e documentos;
• jobs, integrações, APIs e reconciliação de dados;
• perfis, contas técnicas e trilha de auditoria;
• carga, concorrência, fechamentos e processamento em lote;
• backup, restauração, failover e rollback;
• acesso de filiais, usuários remotos e suporte.

Cada teste precisa de responsável, dado de entrada, resultado esperado e evidência. Falhas críticas devem impedir o go-live até correção ou aceite formal de risco.

Como estimar o custo real

Inclua computação, banco, armazenamento por capacidade e desempenho, snapshots, tráfego, conexão dedicada, balanceamento, firewall, logs, monitoração, suporte, licenças, ambientes não produtivos e contingência. Some ainda implantação, testes, documentação e operação assistida.

Compare períodos equivalentes e modele crescimento. Descontos por compromisso podem reduzir preço, mas limitam flexibilidade; dimensione antes de contratar. Após a migração, acompanhe recursos sem uso, armazenamento crescente e custos de transferência. O guia de FinOps para empresas ajuda a distribuir responsabilidade e criar uma rotina de otimização.

Erros que aumentam o risco

• migrar sem conhecer customizações e integrações;
• juntar migração, atualização de release e grandes mudanças funcionais sem necessidade;
• copiar o dimensionamento físico sem revisar uso real;
• testar com base pequena e poucos usuários;
• ignorar latência de filiais e sistemas que permanecem locais;
• considerar backup existente como rollback testado;
• expor portas administrativas ou compartilhar credenciais;
• desligar o ambiente anterior antes de validar ciclos críticos;
• avaliar sucesso apenas pela infraestrutura, sem processos de negócio.

Separar mudanças costuma reduzir o número de causas possíveis durante um incidente. Quando migração e atualização precisarem ocorrer juntas por compatibilidade ou suporte, amplie ensaios, regressão e critérios de retorno. O checklist de atualização do Protheus ajuda a planejar essa frente.

Checklist final de prontidão

• Objetivos e indicadores foram aprovados?
• Arquitetura e plataformas estão homologadas?
• Dependências, customizações e integrações foram inventariadas?
• Sizing usa métricas de pico e testes representativos?
• Rede e latência foram medidas em cada local relevante?
• Responsabilidades de segurança e operação estão definidas?
• RPO, RTO, restauração e rollback foram ensaiados?
• Homologação funcional e técnica possui evidências?
• A virada cabe na janela com margem?
• Critérios de go/no-go e autoridade de decisão estão claros?
• Custos recorrentes e variáveis estão visíveis?
• Existe plano de estabilização e desativação do legado?

Conclusão

A migração do Protheus para nuvem é bem-sucedida quando arquitetura, operação e processos de negócio chegam juntos ao destino. Inventário, medições, homologação e reversão testada valem mais do que uma simples réplica do servidor atual. O melhor desenho depende das versões, dependências, criticidade, equipe e tolerância da empresa a indisponibilidade e custo.

Para avaliar o ambiente, desenhar a arquitetura e planejar a transição com escopo e critérios claros, conheça a consultoria Protheus, a migração para cloud e fale com a Mattos Tech Solutions.

Fontes e referências

• TOTVS TDN — Protheus em Provedor de Nuvem
• TOTVS TDN — DBAccess
• Microsoft Cloud Adoption Framework — Planeje sua migração
• AWS Well-Architected Framework — Reliability Pillar
• NIST SP 800-145 — The NIST Definition of Cloud Computing