Migração Protheus → Odoo: RH, PCP e fiscal num projeto único

TOTVS Protheus é o ERP brasileiro com maior base instalada — estimadas 35 mil empresas usam algum produto TOTVS, com Protheus dominando mid-market industrial e distribuição. Tem localização BR nativa, módulos SIGAPCP (PCP), SIGAGPE (folha) e SIGAFIS (fiscal) consolidados há décadas.

Migrar de Protheus para Odoo é um dos projetos mais frequentes da KMEE. Este artigo é uma síntese técnica do que aprendemos: por que empresas migram, como estruturar o projeto, e onde estão os riscos reais.

Por que empresas migram

Não é “Protheus é ruim”. É uma combinação de fatores que se acumulam:

• Custo de manutenção com horas de consultoria TOTVS sobe ano após ano.
• Customizações em ADVPL acumuladas sem governança Git, difíceis de manter.
• Upgrade de versão vira projeto de 6-12 meses cada.
• Time interno com baixa rotatividade fica preso ao “como sempre se fez”.
• Roadmap regulatório (Reforma Tributária, EFD-Reinf, eSocial S-1.3) entra na fila do fabricante.
• Integração com sistemas modernos (e-commerce headless, BI cloud, IA) exige adaptadores caros.

Em fóruns como TOTVS Tech Community e Reclame Aqui os padrões são consistentes.

A tese de migração unificada

A tentação clássica em projetos de migração é faseamento por módulo: primeiro fiscal, depois financeiro, depois RH, depois PCP. Em teoria, reduz risco. Na prática, dobra o custo total porque exige interface temporária Protheus ↔ Odoo durante 18-36 meses.

A abordagem unificada — que adotamos quando o cliente está pronto — é fazer RH + PCP + fiscal no mesmo go-live. Vantagens:

• Sem integração temporária custosa.
• Folha de pagamento (eSocial) e fiscal são interdependentes — migrar junto evita reconciliação cruzada.
• PCP gera apontamento → custo → fiscal → folha (custo de mão de obra direta). Cortar isso em fases é receita para inconsistência.

Stack técnica adotada

• Odoo Enterprise como base (versão 18 ou 19 dependendo do cliente).
• l10n-brazil — OCA, fiscal BR completo (NF-e, NFS-e, CT-e, MDF-e, SPED).
• l10n-brazil-hr — folha BR, eSocial S-1.x, S-2.x, S-1200.
• Manufacturing nativo + módulos OCA para PCP (mrp_*, quality_*).
• Doodba — stack Docker padrão com PR/CI.
• OpenUpgrade (github.com/OCA/OpenUpgrade) para upgrades futuros.

Fases típicas de um projeto unificado

Fase 0 — Diagnóstico (4-6 semanas)

• Mapeamento completo dos processos atuais no Protheus (frequentemente o cliente não sabe o que customizou).
• Levantamento de customizações ADVPL e regras de negócio implícitas.
• Análise dos relatórios em uso (geralmente os relatórios revelam mais regras de negócio do que o código).
• Inventário de integrações (e-commerce, banco, CRM externo, BI).

Fase 1 — Setup técnico (4 semanas)

• Doodba + repos + CI no GitLab/GitHub.
• Sandbox 1 (dev), Sandbox 2 (staging), Produção.
• Restore inicial de cadastros (parceiros, produtos, plano de contas).

Fase 2 — Fiscal + Financeiro (8-12 semanas)

• Configuração l10n_br_* por CFOP, NCM, CEST, ST.
• Conciliação bancária CNAB.
• DRE, DFC, Balancete equivalentes ao SIGAFIN.
• Testes de emissão NF-e/NFS-e em homologação.

Fase 3 — PCP + Estoque (8-12 semanas)

• BOM multi-nível, roteiros, work centers.
• Apontamento de produção (manual e via terminal de chão de fábrica).
• WMS via stock_barcode e módulos OCA.
• Inventário cíclico, lote/série, FIFO.

Fase 4 — RH + Folha (10-14 semanas)

• Cadastro completo de colaboradores migrado.
• Folha mensal, férias, 13º, rescisão.
• eSocial S-1000, S-1010, S-1020, S-1200, S-1210, S-2200, S-2299, S-2300, S-2399.
• Benefícios (VR, VT, plano saúde) via parceiros de mercado.

Fase 5 — Cutover (2-4 semanas)

• Restore final de saldos.
• Validação fiscal em paralelo (Protheus + Odoo emitindo o mesmo dia, comparação byte-a-byte).
• Go-live.

Fase 6 — Estabilização (8-12 semanas)

• Hypercare com analistas dedicados.
• Tuning de performance.
• Treinamento dos key users.

Tempo total típico: 9-15 meses para empresa mid-market industrial com 200-500 usuários.

Riscos reais (que vimos em campo)

1. Cliente subestima esforço de mapeamento. Achar que “o Protheus já tá funcionando, é só migrar” é a causa #1 de projeto travado.
2. Customizações ADVPL não documentadas. Encontrar a lógica certa em milhares de linhas de ADVPL leva tempo.
3. eSocial em paralelo. Errar S-1200 é multa imediata. Validação em homologação é não-negociável.
4. Cutover de inventário industrial. Empresas de manufatura têm dezenas de milhares de SKUs com saldos por lote/série. Cutover precisa ser planejado em janela específica (geralmente domingo após inventário físico).

Comparativo Odoo vs Protheus

Detalhamos em /comparativos/odoo-vs-protheus/.

Quando NÃO migrar do Protheus

• Empresa com Protheus estável, customização sob controle, time interno bem treinado, e roadmap fiscal sob controle. Não há ROI em migrar por migrar.
• Empresa em meio a projeto interno grande (M&A, abertura de capital, ERP de filial nova). Migração de ERP no meio é receita para confusão.
• Sem orçamento para projeto unificado. Faseamento é caro mas, se o orçamento exige, melhor faseado bem feito que unificado mal feito.
• Time interno avesso a stack Python/Linux. Migrar para Odoo sem buy-in técnico é problema garantido.

Quando vale planejar migração

• Custo TOTVS anual > R$ 800k/ano (licença + horas).
• Última atualização de versão Protheus > 4 anos.
• Backlog de customização > 12 meses sem entrega.
• Projeto Reforma Tributária 2026-2033 está atrasado no fornecedor atual.
• Time interno foi contratado/renovado nos últimos 2 anos e tem perfil técnico moderno.

Se 3 ou mais batem, vale conversar. Fale com um especialista KMEE para um diagnóstico aplicado ao seu Protheus específico.