Manter um ERP crítico rodando em infraestrutura envelhecida é uma decisão que cobra seu preço de forma gradual: hardware que não recebe renovação, janelas de indisponibilidade que se alongam e um time de TI que passa mais tempo apagando incêndios do que evoluindo o ambiente. Levar o TOTVS Protheus para a AWS é uma resposta concreta a esse problema, mas a migração envolve decisões de arquitetura, licenciamento e gestão de risco que, se ignoradas, trocam um problema por outro. Este texto apresenta o que muda na prática: da escolha de instâncias ao plano de rollback, passando pelos riscos mais comuns e pelos critérios para selecionar quem vai conduzir o projeto.
Por que levar o Protheus para a nuvem agora
Servidores on-premises acumulam custos que raramente aparecem em uma única linha do orçamento. Renovação de hardware, licenciamento de sistema operacional, contratos de manutenção e o tempo da equipe dedicado a tarefas operacionais somam um TCO que, quando calculado com rigor, frequentemente surpreende gestores que consideram o ambiente "já amortizado". O problema não é só financeiro: ambientes legados têm janelas de recuperação longas em incidentes, e uma indisponibilidade de algumas horas no ERP impacta diretamente operações financeiras, fechamento fiscal e folha de pagamento.
A AWS mantém regiões de disponibilidade no Brasil (São Paulo), o que responde a dois requisitos concretos: latência adequada para usuários locais e residência de dados dentro do território nacional, exigência de empresas sujeitas à LGPD e a regulações setoriais como as do mercado financeiro e da saúde. A decisão de migrar, porém, não é puramente técnica. Ela precisa ser sustentada por uma análise de TCO comparativo, pela revisão dos SLAs que o negócio exige de TI e pela avaliação honesta da capacidade do time interno de sustentar o ambiente atual por mais dois, três ou cinco anos.
Arquitetura do Protheus na AWS
O Protheus opera com um Application Server (Appserver) separado do banco de dados relacional (SQL Server ou Oracle). Cada camada precisa ser dimensionada de forma independente, e o Appserver é sensível à latência entre ele e o banco — colocar as duas camadas em sub-redes diferentes sem considerar esse ponto gera degradação perceptível para o usuário final.
Outro detalhe crítico: o Protheus licencia conexões simultâneas. Superdimensionar instâncias sem mapear quantos usuários realmente acessam o sistema ao mesmo tempo gera custo sem retorno. Esse mapeamento precisa acontecer antes de qualquer decisão de sizing.
A TOTVS mantém documentação de referência para implantação do Protheus em ambientes AWS, incluindo orientações sobre configuração do Appserver, banco de dados e rede. Essa documentação é o ponto de partida técnico obrigatório — mas não substitui o diagnóstico do ambiente específico de cada empresa.
O Protheus tem homologação TOTVS para ambientes cloud, mas a homologação não elimina a necessidade de definir com clareza as responsabilidades de suporte entre a TOTVS, o parceiro de implantação e a AWS. Essa divisão precisa estar documentada antes do início do projeto.
Modelo de infraestrutura recomendado para o Protheus
A referência de partida para um ambiente Protheus na AWS é:
- EC2 com famílias otimizadas para memória (série R) para o Appserver, dado o consumo intensivo de RAM em ambientes com muitos usuários simultâneos.
- RDS SQL Server Multi-AZ para o banco de dados, garantindo failover automático sem intervenção manual em caso de falha na zona de disponibilidade primária.
- VPC dedicada com sub-redes privadas para banco e aplicação; acesso externo somente via VPN ou AWS Direct Connect, nunca exposição direta do Appserver à internet.
- AWS Backup configurado com políticas de retenção definidas pela política de negócio — não pelo padrão técnico do serviço. Backups retidos por mais tempo do que o necessário geram custo desnecessário; backups insuficientes comprometem o RPO.
- CloudWatch com alertas proativos de CPU, memória e latência de banco. O time de TI precisa saber do problema antes que o usuário abra um chamado.
Esse modelo cobre o cenário mais comum, mas ambientes com alto volume de usuários simultâneos ou integrações intensivas com sistemas externos podem demandar ajustes — daí a importância do diagnóstico antes de fechar a arquitetura.
Riscos comuns e como mitigá-los
Cinco riscos aparecem com frequência em projetos desse tipo e merecem atenção explícita no planejamento:
- Sizing incorreto. Migrar com as mesmas especificações do servidor físico quase sempre resulta em superdimensionamento — servidores físicos costumam operar com baixa utilização média. O caminho correto é coletar um baseline de consumo real (CPU, memória, IOPS) por pelo menos 30 dias antes de definir as instâncias na AWS.
- Latência de rede para usuários remotos. Usuários acessando o Protheus via internet sem VPN percebem lentidão, especialmente em operações que envolvem muitas requisições ao Appserver. AWS Client VPN ou acesso via ambiente virtualizado (Workspace, Citrix) são alternativas a avaliar para operações críticas.
- Licenciamento de SQL Server. SQL Server em EC2 segue regras de licença por núcleo diferentes das do RDS com licença inclusa. Mapear o modelo de licenciamento atual antes de escolher a forma de implantação evita exposição em auditorias — um custo que pode ser significativamente maior do que qualquer economia obtida na escolha errada.
- Customizações no Protheus. Fontes alterados podem não ser compatíveis com versões mais recentes do produto, e ambientes cloud frequentemente exigem atualização de versão como pré-requisito de homologação. Inventariar todas as customizações é pré-requisito da migração, não uma etapa opcional.
- Ausência de plano de rollback. Definir um ponto de retorno claro — snapshot do ambiente on-premises ativo e funcional — antes do go-live em nuvem é inegociável. Sem isso, qualquer problema crítico nas primeiras horas de produção vira uma crise sem saída estruturada.
Como estruturar o projeto de migração em fases
Um projeto bem estruturado reduz o risco de surpresas e cria pontos de validação antes de comprometer o ambiente produtivo.
Fase 1 — Diagnóstico: levantamento de versões do Protheus, banco de dados, customizações, integrações com sistemas externos e volume real de usuários simultâneos. Sem esse inventário, qualquer estimativa de arquitetura é especulação.
Fase 2 — Ambiente de homologação na AWS: replicar o ambiente produtivo em escala reduzida, validar performance, testar integrações e envolver usuários-chave de cada área para validação funcional. Problemas encontrados aqui custam uma fração do que custariam em produção.
Fase 3 — Ajuste de sizing e segurança: revisar instâncias com base nos dados reais coletados em homologação, aplicar políticas de IAM com princípio de menor privilégio, configurar criptografia em repouso (EBS, RDS) e em trânsito (TLS).
Fase 4 — Migração de produção: janela planejada com comunicação antecipada às áreas de negócio, equipe de suporte dedicada — tanto técnica quanto funcional — nas primeiras 72 horas após o go-live. Esse período concentra a maior parte dos chamados e exige capacidade de resposta rápida.
Fase 5 — Estabilização e otimização de custos: após 60 a 90 dias de operação estável, revisar o uso real das instâncias e avaliar a conversão para Reserved Instances ou Savings Plans. Essa etapa pode reduzir o custo mensal de forma sustentável sem nenhuma mudança de arquitetura.
Critérios para escolher o parceiro certo para essa migração
A escolha do parceiro é, provavelmente, a decisão mais importante do projeto. Dois perfis técnicos precisam coexistir na mesma equipe: conhecimento profundo de TOTVS Protheus — funcional e técnico, incluindo o comportamento do Appserver e a gestão de customizações — e experiência operacional comprovada em AWS. Quando esses perfis ficam em empresas separadas, as lacunas de responsabilidade aparecem exatamente nos momentos de crise.
Verifique se o parceiro tem experiência específica com SQL Server em ambiente AWS — isso inclui estratégias de licenciamento, configuração de RDS Multi-AZ e gestão de performance de banco em instâncias gerenciadas. É uma combinação menos comum do que parece.
Avalie também o modelo de engajamento pós-migração. Ambientes ERP em nuvem não são estáticos: demandam ajustes de performance, revisões de custo e resposta a incidentes ao longo do tempo. Um parceiro que entrega o projeto e encerra o contrato transfere para o time interno uma responsabilidade que pode não estar dimensionada para absorver.
Por fim, exija um plano de projeto com marcos mensuráveis, critérios de aceite definidos por fase e responsabilidades claras por camada do ambiente. Planos genéricos são o primeiro sinal de que o parceiro não tem experiência suficiente com a especificidade desse tipo de migração.
Próximos passos
Se você está no início da avaliação, o ponto de partida mais produtivo é o diagnóstico do ambiente atual: versões, customizações, integrações e consumo real de infraestrutura. Sem esse levantamento, qualquer proposta de migração que você receber será baseada em premissas, não em dados.
Se a decisão já está tomada e o projeto está em planejamento, revise se os cinco riscos descritos acima estão cobertos no plano e se o parceiro escolhido tem competência simultânea em TOTVS Protheus e AWS — não apenas em um dos dois lados.
A Ascendra atua com projetos de migração e sustentação de ambientes TOTVS Protheus na AWS, combinando equipe técnica certificada em AWS com experiência funcional e técnica no produto. Se fizer sentido conversar sobre o seu cenário específico, estamos disponíveis para uma conversa sem compromisso.
