Todo ano, em outubro, a TOTVS libera uma nova release da linha Protheus. A data é previsível e, justamente por isso, costuma ser tratada como assunto de TI a ser resolvido depois. O problema aparece quando a empresa soma duas informações que raramente estão na mesma mesa: cada release tem prazo de validade, e o projeto para adotá-la leva meses.

O calendário que já está definido

A linha Protheus recebe uma release por ano, com 20 meses de manutenção padrão cada. Encerrado esse período, correções e alterações legais passam a depender de garantia estendida contratada. O quadro atual é este:

  • 12.1.2410 — lançada em outubro de 2024, com suporte padrão encerrado em junho de 2026 e garantia estendida disponível até dezembro de 2027.
  • 12.1.2510 — lançada em outubro de 2025, com suporte padrão até junho de 2027 e garantia estendida até dezembro de 2028.
  • A release de 2026 — chega agora, em outubro, reiniciando o ciclo.

Quem está na 2410 já opera fora da manutenção padrão. Quem está na 2510 tem prazo até junho de 2027 e, na prática, é essa folga aparente que empurra a decisão para o meio do ano que vem.

Por que a conta não fecha se a decisão esperar

Migração de release não é aplicação de pacote. Em ambientes com customização relevante, o projeto costuma consumir de 10 a 16 semanas, com uma janela de cutover de 36 a 72 horas. Decidir em dezembro significa entrar em produção em maio, colado no prazo e sobre o período de fechamento.

O cronograma não é inflado. Ele reflete o trabalho que precisa acontecer antes da virada:

  • Diagnóstico e gap analysis. Release atual, release de destino, lacunas funcionais e prazo de suporte de cada ambiente.
  • Inventário de customizações. User functions, pontos de entrada, campos e parâmetros do dicionário, gatilhos e integrações. É a etapa que mais revela surpresa: o volume real costuma superar bastante a estimativa inicial.
  • Compatibilidade do código. Recompilação do ADVPL na nova release, ajuste de chamadas e tratamento dos pontos de entrada descontinuados.
  • Dicionário e base. Atualização das tabelas de dicionário e aplicação de pacotes, sempre com backup completo e plano de rollback definido.
  • Teste de regressão. Faturamento, fiscal, financeiro, contábil, folha e integrações, com casos reais da operação.
  • Cutover e acompanhamento. Virada em janela planejada e monitoramento de 15 a 30 dias, validando ao menos um fechamento contábil e fiscal completo.

Onde a migração costuma quebrar

Os pontos de falha se repetem de projeto para projeto, e todos têm origem na customização:

  • Ponto de entrada descontinuado pela TOTVS, deixando a customização órfã.
  • Rotina automática cuja estrutura mudou, fazendo a integração rejeitar lançamentos.
  • Campo customizado em conflito com campo novo do padrão.
  • Regra fiscal escrita diretamente na TES, incompatível com a configuração atual de tributos.
  • Tela customizada de desktop que não acompanha a migração para o WebApp.

Nenhum desses problemas aparece na véspera. Todos aparecem no teste, quando há tempo de corrigir, ou em produção, quando não há.

O contexto de 2026 aperta o prazo

Há um fator adicional neste ciclo. O destaque de IBS e CBS nos documentos fiscais é exigência legal desde janeiro de 2026, e toda adequação à Reforma Tributária continua sendo distribuída por pacotes e releases. Um ambiente fora da janela de manutenção padrão não recebe essas atualizações — e a discussão deixa de ser sobre versão de sistema para virar risco fiscal.

O que dá para fazer nas próximas duas semanas

Antes de orçar qualquer projeto, existe uma tarefa barata e de alto retorno: levantar o inventário de customizações e classificar cada item em essencial, complementar ou descartável.

Esse documento responde, com números, às duas perguntas que travam a decisão. Quanto de customização realmente existe no ambiente. E quanto dela ainda faz sentido manter. Na prática, ele encurta semanas de diagnóstico e muda a natureza da conversa: em vez de discutir quanto vai custar, a empresa passa a discutir o que precisa ser revalidado.

A release de outubro é evento de calendário, conhecido com antecedência. O que varia de empresa para empresa é o momento em que a decisão é tomada — e é isso que separa uma atualização planejada de um projeto de emergência.

Com 21 anos como parceira TOTVS e mais de 150 implantações, a ELR Solutions conduz inventário de customizações, planejamento e execução de migração de release no Protheus, com validação em homologação e acompanhamento do primeiro fechamento. Se a sua empresa quer entrar no próximo ciclo com prazo, fale com a nossa equipe.