Migração de release TOTVS: o guia técnico completo (etapas, riscos e o que verificar antes da produção)

Migração de release TOTVS é o processo de atualização da versão da camada de aplicação do ERP — Protheus, Datasul ou RM — para uma release suportada pela TOTVS. O projeto envolve compatibilizar customizações ADVPL ou Progress 4GL, validar o dicionário de dados, executar testes de regressão e garantir adequação fiscal contínua, incluindo IBS, CBS e o Configurador de Tributos.

Resumo executivo

• Quem precisa migrar agora: clientes Protheus na release 12.1.2410 (expira em 30/06/2026), RM 12.1.2502 ou anterior (já expiradas) e Datasul fora das duas últimas releases vigentes.

• Por que importa em 2026: a Reforma Tributária (LC 214/2025) exige NF-e, NFC-e, NFS-e e CT-e com IBS, CBS e o novo Imposto Seletivo destacados. Releases antigas não recebem essas atualizações fiscais.

• Tempo médio de projeto: entre 8 e 16 semanas para ambientes com customizações relevantes; cutover em janela de 36 a 72 horas.

• Risco principal: customizações em ADVPL (User Functions e Pontos de Entrada) que não foram revistas podem quebrar regras fiscais, gerar lançamentos contábeis incorretos ou bloquear emissão de documentos fiscais.

O que é uma release TOTVS

Uma release TOTVS é uma versão oficial do ERP que consolida correções, evoluções funcionais, adequações fiscais e atualizações de tecnologia. Cada release passa a substituir a anterior em ciclos planejados, com janela de suporte definida e expiração formal. Após a expiração, a TOTVS deixa de tratar incidentes, vulnerabilidades e mudanças de legislação naquela versão.

O modelo se baseia em expedição contínua: entre uma release principal e outra, a TOTVS publica patches incrementais que corrigem problemas pontuais e atualizam obrigações acessórias. Esses patches só se aplicam dentro da release vigente.

O ciclo de suporte por produto

Datas-chave Protheus em 2026 (Lei do ciclo de vida TOTVS):

• 30/06/2026 — Expiração da release 12.1.2410 e descontinuação do SmartClient Desktop (apenas WebApp será suportado).

• Outubro/2026 — Configurador de Tributos (CFGTRIB) passa a ser o motor principal de cálculo fiscal.

• 30/06/2027 — Expiração da release 12.1.2510 e descontinuação definitiva do modelo antigo de TES.

Por que migrar release agora: quatro forças que mudaram em 2026

A decisão de migrar release deixou de ser apenas técnica em 2026. Quatro fatores convergiram para tornar o projeto urgente.

1. A Reforma Tributária entrou em vigor

A Lei Complementar nº 214/2025 instituiu IBS, CBS e o Imposto Seletivo. Desde 1º de janeiro de 2026, todos os contribuintes do Lucro Real e Lucro Presumido devem destacar esses tributos em NF-e, NFC-e, NFS-e e CT-e, com os novos códigos CST-IBS/CBS e cClassTrib. A Nota Técnica 2025.002, em sua versão 1.33, detalha os leiautes obrigatórios.

Em 2026 o recolhimento financeiro tem caráter informativo (artigo 348 da LC 214), mas a obrigação acessória é exigível. Em 2027, o PIS e a COFINS são extintos e a CBS passa a ser cobrada com alíquota plena. Releases antigas do Protheus, Datasul e RM não recebem esses leiautes.

2. O SmartClient Desktop deixa de existir no Protheus

A partir da release 12.1.2410, o SmartClient Desktop foi descontinuado. Empresas que ainda operam com o cliente desktop precisam migrar para o WebApp, que é a interface 100% web do Protheus. Essa mudança afeta workflow, integrações, ferramentas de automação RPA e qualquer customização de tela em ADVPL legada.

3. O Configurador de Tributos substitui o TES tradicional

O modelo antigo baseado em TES (Tipo de Entrada e Saída) está em descontinuação. A partir de outubro de 2026, o CFGTRIB (Configurador de Tributos) passa a ser o motor principal de cálculo no Protheus, com o modelo híbrido temporário previsto para acabar na release 12.1.2610. Releases anteriores não recebem a evolução do CFGTRIB.

4. Vulnerabilidades de segurança não recebem mais correção

Releases expiradas deixam de receber patches de segurança. Em 2026, com a Reforma Tributária ampliando integrações entre ERP e Fisco e com a obrigatoriedade de transmissão de novos eventos, manter o ERP em release expirada equivale a operar com um sistema sem manutenção em uma operação fiscal mais exposta.

Os riscos com customizações ADVPL

Aqui está o ponto mais sensível de qualquer migração de release Protheus. Customizações ADVPL não são parte do código padrão da TOTVS. Elas vivem no RPO (Repositório de Objetos) compilado do cliente e podem ser invalidadas quando a TOTVS altera a função padrão que aquela customização sobrescrevia.

Em termos práticos: o que funcionava antes da migração pode parar de funcionar depois — ou pior, continuar funcionando com lógica errada.

Os tipos de customização que migram com você

Por que customizações quebram em uma migração

Para o decisor: quando a TOTVS atualiza uma rotina padrão, ela pode mudar a assinatura de uma função, o nome de uma variável global, a estrutura de um array de retorno, ou simplesmente remover um Ponto de Entrada que sua customização usava. Sua customização foi escrita assumindo um contrato; o contrato mudou.

Para o time técnico: a checagem mais comum em migração ADVPL inclui validar que User Functions referenciadas em menu (SXB/SX2) ainda compilam contra o novo include protheus.ch, que Pontos de Entrada não foram descontinuados ou renomeados (consultar a documentação TDN), que campos de SX3 não conflitam com campos novos da release e que rotinas que usam MsExecAuto continuam recebendo o array no formato esperado.

O que mais comumente quebra

A partir do histórico de migrações conduzidas pela Groundwork em ambientes Protheus, Datasul e RM, há cinco padrões de quebra que aparecem em quase todo projeto:

1. Pontos de Entrada descontinuados — a TOTVS removeu o ponto, mas a customização ainda é compilada e fica órfã, sem efeito ou com efeito parcial.

2. MsExecAuto com array desatualizado — a estrutura do aRotAuto passou a exigir novos campos da release, e integrações automáticas começam a rejeitar lançamentos.

3. Campos do SX3 conflitantes — a TOTVS criou um campo com mesmo nome do customizado, e o dicionário não compatibiliza.

4. Customizações fiscais em TES antigas — regras escritas direto no TES não funcionam com o Configurador de Tributos.

5. Telas customizadas em SmartClient Desktop — não migram automaticamente para o WebApp; precisam de reescrita parcial ou total.

Equivalentes em Datasul (Progress 4GL) e RM (.NET):

• Datasul: customizações vivem como programas .p ou .r no propath, frequentemente em include files; quebram quando a TOTVS renomeia tabelas, altera a estrutura de includes (.i) ou descontinua APIs internas. A migração de OpenEdge 11 para 12 também exige recompilação de todos os programas customizados.

• RM: customizações em .NET ficam em DLLs compiladas contra a versão do RM.Lib; trocar de release exige recompilar contra a nova biblioteca e validar contratos de objetos RMSObject.

As 9 etapas de uma migração de release TOTVS

Esta é a sequência testada que a Groundwork executa em projetos de migração de release. As etapas se aplicam aos três produtos (Protheus, Datasul e RM), com diferenças de ferramenta apontadas em cada uma.

Etapa 1 — Diagnóstico de release atual e gap analysis

Mapeamento da release vigente, da release-alvo, do gap funcional entre elas (o que mudou no padrão TOTVS), do status de Garantia Estendida, do calendário oficial de expiração e das mudanças de tecnologia adjacentes (SmartClient Desktop, OpenEdge, .NET Runtime).

Entregáveis: matriz de gap, calendário-alvo, plano de comunicação interno.

Etapa 2 — Mapeamento de customizações

Inventário completo de User Functions, Pontos de Entrada, customizações de SX3/SX6/SX7, telas customizadas e integrações. No Protheus, o IXBLOG e o Catálogo de Personalização (SIGACFG) ajudam a identificar customizações que o sistema executa em runtime mas que não estão documentadas. No Datasul, leitura do propath e dos .r compilados. No RM, listagem das DLLs custom.

Entregáveis: inventário de customizações classificado por criticidade (essencial, complementar, descontinuável).

Etapa 3 — Planejamento e cronograma

Definição da janela de cutover, dos ambientes envolvidos (DEV, HML, PRD), das responsabilidades por área (TI, Fiscal, Contábil, RH, áreas de negócio) e dos critérios de aceite. Revisão de SLA, plano de rollback e plano de comunicação com a TOTVS Suporte.

Entregáveis: cronograma macro, plano de cutover, matriz de responsabilidades (RACI), plano de rollback.

Etapa 4 — Provisionamento de ambientes

Criação ou atualização do ambiente de homologação espelhado da produção, ajuste de License Server (TOTVS License Server Virtual), configuração do appserver.ini ou equivalente, definição de portas e infraestrutura de WebApp e WebAgent.

Entregáveis: ambiente HML preparado, ambiente DEV congelado para a release-alvo, plano de infraestrutura.

Etapa 5 — Compatibilização de customizações

Recompilação de todas as User Functions e Pontos de Entrada contra a nova release, ajuste de chamadas a funções padrão alteradas, reescrita de código que dependia de Pontos de Entrada descontinuados, atualização de includes (.ch no ADVPL, .i no Progress, namespaces no .NET).

Entregáveis: RPO compilado e versionado, log de erros de compilação tratados, lista de Pontos de Entrada migrados.

Etapa 6 — Migração de dicionário e bases

No Protheus, atualização do dicionário (SX1 a SXG) com UPDDISTR e UPDDIST e aplicação de patches sobre a release-alvo. No Datasul, execução do Console de Atualização. No RM, aplicação dos pacotes via Atualizador. Backup completo das bases antes do procedimento, com plano de restore validado.

Entregáveis: base atualizada em HML, log do dicionário, evidências de backup.

Etapa 7 — Testes funcionais e de regressão

Execução de roteiros de teste por área crítica: faturamento, fiscal (com simulação de IBS/CBS), financeiro, contábil, folha, estoque, custos, integrações. Validação de obrigações acessórias (SPED, EFD, REINF). Testes de carga em rotinas pesadas (cálculo de folha, fechamento contábil, apuração fiscal).

Entregáveis: matriz de testes assinada pelas áreas-chave, lista de incidentes tratados, certificado de aceite por área.

Etapa 8 — Cutover e janela de produção

Execução do plano de cutover na janela acordada (geralmente fim de semana ou feriado prolongado), com freeze do ambiente de produção, backup, atualização do binário, atualização do RPO, atualização do dicionário, smoke test, liberação para usuários-piloto, e só depois liberação geral.

Entregáveis: ambiente em produção atualizado, evidência de backup pré e pós-cutover, log do procedimento.

Etapa 9 — Pós-go-live e estabilização

Acompanhamento de incidentes nos primeiros 15 a 30 dias, ajuste fino de performance, validação de fechamentos mensais (folha, contábil, fiscal), tratamento de incidentes residuais com TOTVS Suporte e ajustes de customização identificados após o uso real.

Entregáveis: relatório de estabilização, plano de melhorias contínuas, documentação atualizada.

Diferenças por produto: Protheus, Datasul e RM em uma tabela

BT Monitor: como controlar a performance antes e depois da migração

Migrar release sem comparar a performance antes e depois é uma aposta. Uma rotina que rodava em 8 minutos na 12.1.2310 pode rodar em 12 minutos na 12.1.2510 — e ninguém percebe até o fechamento mensal travar.

O BT Monitor é a solução de observabilidade da Groundwork desenvolvida especificamente para ERPs TOTVS, parte da família GWMS (Groundwork Monitor Suite). Em projetos de migração de release, ele cumpre três funções:

1. Espelho de performance pré-migração. O BT Monitor coleta métricas das rotinas críticas (tempo médio, tempo P95, throughput, locks, uso de CPU/memória) durante 4 a 8 semanas antes da migração, criando uma baseline objetiva de como a operação se comporta na release vigente.

2. Comparação durante e após o cutover. Os mesmos dashboards comparam o comportamento das rotinas na nova release. Quando uma rotina que rodava em 4 minutos passa a rodar em 11 minutos, o BT Monitor identifica e alerta.

3. Detecção de regressões em customizações. Como o BT Monitor instrumenta também User Functions e Pontos de Entrada, ele identifica quais customizações específicas degradaram após a migração, permitindo correção cirúrgica sem revisão completa do RPO.

Em projetos recentes, o BT Monitor identificou regressões de performance em até 30% das rotinas críticas após migração, todas resolvidas durante a estabilização. Sem instrumentação, essas regressões só apareceriam no fechamento mensal seguinte.

Conheça o GWMS e o BT Monitor →

Os erros mais comuns em projetos de migração

Cinco padrões de erro aparecem em quase todo projeto de migração mal conduzido. Conhecê-los antes ajuda a planejar contornos.

1. Subestimar o inventário de customizações. O cliente acredita ter "poucas customizações" porque desconhece a maior parte delas. Em uma operação Protheus madura, o inventário real costuma ser 3 a 5 vezes maior do que o estimado em conversa.

2. Pular a etapa de homologação. Migrar direto em produção em fim de semana, sem ambiente HML completo, é a causa número um de rollback emergencial. Toda migração precisa de HML espelhada e roteiro de testes assinado pelas áreas.

3. Ignorar Garantia Estendida e prazos da TOTVS. Empresas descobrem em junho que sua release expirou, perderam o direito a chamados na TOTVS e precisam contratar Garantia Estendida com custo adicional para ganhar tempo. O calendário precisa ser monitorado.

4. Tratar fiscal e contábil como "qualquer outra área". Em 2026, as áreas fiscal e contábil concentram o maior risco da migração, por causa da Reforma Tributária. Validação de SPED, ECF, EFD-Reinf, IBS/CBS deve ter peso maior no roteiro de testes.

5. Não medir performance antes e depois. Sem baseline, não há como provar que a release nova trouxe ou não regressão. Esse é exatamente o gap que o BT Monitor preenche.

Perguntas frequentes sobre migração de release TOTVS

Quanto tempo demora uma migração de release TOTVS?

Para ambientes Protheus com customizações relevantes, o projeto leva entre 10 e 16 semanas, do diagnóstico ao pós-go-live. Datasul costuma ficar entre 8 e 14 semanas e RM entre 6 e 12 semanas. A janela de cutover em si dura entre 36 e 72 horas, geralmente em fim de semana ou feriado prolongado. Operações com poucas customizações ou apenas uma release de gap conseguem encurtar o ciclo.

Posso migrar release sem mexer nas minhas customizações?

Não. Toda customização precisa ser, no mínimo, recompilada contra a nova release. Em mudanças maiores (como Protheus 12.1.2310 → 12.1.2410, com fim do SmartClient Desktop), parte das customizações precisa ser revisada ou reescrita. Pular a etapa de compatibilização é a causa mais comum de quebras em produção.

Sou obrigado a migrar por causa da Reforma Tributária?

Sim, na prática. A LC 214/2025 obriga, desde janeiro de 2026, o destaque de IBS e CBS em NF-e, NFC-e, NFS-e e CT-e. Releases antigas do Protheus, Datasul e RM não recebem os leiautes da Nota Técnica 2025.002 nem o Configurador de Tributos. Em 2027, com PIS e COFINS extintos e CBS em alíquota plena, operar em release expirada significa não conseguir emitir documentos fiscais válidos.

Qual o downtime esperado durante a virada?

O downtime real costuma ficar entre 12 e 36 horas para Protheus e Datasul, dependendo do volume de bases e do tempo de aplicação do dicionário. Para RM costuma ser menor, entre 6 e 18 horas. Empresas que precisam reduzir esse tempo trabalham com estratégias de migração em duas etapas (binário primeiro, dicionário em janela posterior) e ambientes em paralelo durante a transição.

Posso conduzir a migração com o time interno, sem consultoria?

É possível em ambientes pequenos, com poucas customizações e equipe técnica TOTVS dedicada. Em ambientes maiores, com customizações relevantes em fiscal e contábil, a presença de uma consultoria certificada reduz tempo de projeto, custo de erro e risco de rollback. Em 2026, com a complexidade adicional da Reforma Tributária, a maior parte das empresas opta por conduzir o projeto com um parceiro homologado pela TOTVS.

Como a Groundwork conduz migrações de release TOTVS

A Groundwork acumula mais de uma década conduzindo migrações de release em ambientes Protheus, Datasul e RM, com mais de 110 contratos ativos de sustentação que passam por essas migrações em ciclos regulares. Atendemos clientes como CNN, AutoZone, Continental, Aeroporto de Fortaleza, Floripa Airport e Braveo, com time multidisciplinar de mais de 100 especialistas TOTVS distribuídos em São Paulo, Joinville e Fortaleza.

Nosso modelo de atuação combina três frentes:

• Consultoria especializada (Protheus, Datasul e RM) para o projeto de migração propriamente dito, do diagnóstico ao go-live.

• SSG (Serviços de Sustentação Groundwork) para garantir que, depois do go-live, a operação fique sustentada sob SLA, com pacote de tickets e horas planejadas, do N1 ao N4.

• GWMS / BT Monitor para instrumentar a operação antes, durante e depois da migração, com baseline de performance e detecção de regressões.

Ideal para empresas que:

• Operam em release Protheus 12.1.2310 ou 12.1.2410 e precisam migrar antes do fim do suporte

• Estão em RM 12.1.2502 ou anterior e perderam suporte ativo

• Operam Datasul em release fora das duas vigentes

• Não conseguem mapear sozinhos o inventário de customizações ADVPL ou Progress

• Precisam de previsibilidade de prazo e custo, com plano de cutover testado

• Querem garantir que IBS, CBS e o Configurador de Tributos entrem em operação sem quebrar fechamento

Quer entender o impacto de uma migração de release no seu ambiente?

Fale com nosso time de especialistas. Em uma conversa inicial, mapeamos sua release atual, riscos com customizações, calendário-alvo e cenário de Reforma Tributária, e desenhamos um plano realista de migração para o seu ambiente.

Falar com um especialista Groundwork →

Última atualização: 29 de abril de 2026. As informações sobre datas de expiração de releases TOTVS, prazos da Reforma Tributária e versões de notas técnicas seguem a documentação oficial da TOTVS, da Receita Federal e do Comitê Gestor do IBS publicadas até esta data.