Marcelo de Vasconcelos Martins Dá para trocar de ERP sem parar de vender: pela migração-espelho. O novo sistema roda em paralelo ao legado e é validado por fases — emissão de nota, baixa de estoque, conciliação de marketplace, fechamento fiscal — antes de assumir o comando. Isso elimina o risco do big bang, no qual uma carga que falha faz a loja parar.
Trocar o ERP de uma operação de e-commerce em pleno funcionamento parece trocar o motor do carro andando. O medo é legítimo: uma virada malfeita trava o checkout, segura a nota e deixa o pedido do marketplace sem baixa. Por isso a pergunta certa não é “quando desligar o legado”, e sim “como migrar de forma que ninguém perceba”. A resposta tem nome: migração-espelho.
O tema é urgente. Segundo a Mind Consulting (2026), 33,3% das empresas brasileiras planejam trocar de ERP em até dois anos, empurradas por e-commerce, marketplace e uma agenda fiscal que muda quase toda semana. O Gartner (2026) projeta crescimento de dois dígitos no gasto com software corporativo. Muita gente vai migrar. Poucos vão fazer sem sobressalto.
Migração-espelho ou big bang: qual o modelo mais seguro?
A migração-espelho é o modelo seguro. Em vez do “vira-chave” de um fim de semana, o novo ERP opera em paralelo ao legado e cada processo crítico é conferido contra o sistema antigo antes da troca. O big bang concentra tudo em um único corte: se a carga de dados falha ou uma integração não responde, a empresa para de vender. Risco alto, sem rede.
A diferença é de exposição ao risco. No big bang, o dia do corte é uma aposta única. Na migração-espelho, o corte é a confirmação de algo já validado. A recomendação vem de longe. O engenheiro Martin Fowler descreveu, ainda em 2004, o padrão que fundamenta essa abordagem — o Strangler Fig, ou figueira estranguladora.
“Crie o novo sistema aos poucos, em torno das bordas do antigo, deixando-o crescer por anos até que o sistema legado seja estrangulado e possa ser removido.”
— Martin Fowler, engenheiro de software, ao descrever o padrão Strangler Fig (2004)
Por que a maioria das migrações de ERP falha?
Por quatro causas repetidas: escolher o big bang, migrar dado sujo do legado, tratar a troca como assunto só de TI e trocar o sistema sem revisar o processo. As três primeiras derrubam a operação no dia do corte; a quarta faz o novo ERP herdar os vícios do antigo. São falhas de método, não de tecnologia. E método se corrige.
O custo do erro tem escala. A pesquisa KPMG/Abrappe (2025) mediu perdas de R$ 36,5 bilhões no varejo brasileiro em 2024, com ruptura operacional média de 5,10%. Uma migração que trava a baixa de estoque durante um pico de venda transforma esse indicador em cancelamento de pedido e reputação queimada no marketplace. Em uma operação online, cada hora parada é receita que não volta.
Como funciona a validação por fases e os dados mestres?
A validação por fases confere cada processo crítico no novo ERP contra o legado, com conciliação diária, antes de desligar qualquer módulo. Começa pelos dados mestres — cadastro de produto, NCM, CST, CFOP, tabelas fiscais e clientes. Migrar esses dados sem saneamento é migrar o problema: duplicidade de SKU e regra fiscal errada viram nota rejeitada no dia seguinte.
O caminho segue em ondas, do núcleo para a ponta:
| Fase da migração-espelho | O que acontece |
|---|---|
| 1. Diagnóstico e mapeamento | Auditar processos, integrações, tabelas fiscais e qualidade dos dados |
| 2. Migração e saneamento | Carregar catálogo, estoque e financeiro; limpar duplicidade e corrigir NCM/CST |
| 3. Operação-espelho | Rodar os dois sistemas em paralelo, com conciliação diária |
| 4. Cutover por fases | Desligar o legado por módulo ou unidade, nunca tudo de uma vez |
| 5. Estabilização | Monitorar de perto nas primeiras semanas, o período de maior risco |
O que validar antes do cutover?
O cutover é o momento de passar o comando ao novo ERP, e só deve ocorrer quando quatro controles estiverem verdes. Certificação das APIs de marketplace e plataforma de e-commerce. Conciliação diária de estoque, receita e apuração fiscal batendo entre os sistemas. Plano de rollback com o legado ainda vivo. Treinamento por papel concluído antes do desligamento.
A certificação das integrações não é detalhe. Mercado Livre, Shopee e Amazon respondem por cerca de 70% do e-commerce brasileiro por GMV (Mordor Intelligence, 2025). Se o conector de qualquer um deles não estiver homologado no novo ERP antes do corte, o pedido entra e não baixa. Desligue o legado por módulo — fiscal primeiro, depois estoque, depois os canais — para que uma falha isole um processo, e não a operação inteira.
Por que a conformidade fiscal é inegociável na migração de 2026?
Porque a transição de CBS e IBS já começou e um erro tributário vira impacto rápido no caixa. Desde 1º de janeiro de 2026, os campos de CBS e IBS constam no leiaute da NF-e e da NFC-e em fase de teste, com alíquota simbólica de 1% — 0,9% de CBS e 0,1% de IBS (Senado Federal). A obrigatoriedade plena dos novos grupos avança em agosto de 2026, conforme a Nota Técnica RFB/CGIBS nº 2025.002.
Na migração-espelho, a apuração fiscal é validada contra o legado antes do corte. Testar CBS e IBS no novo motor deixou de ser opcional: nota sem os campos corretos é rejeitada, e nota rejeitada é venda travada. Com o e-commerce brasileiro rumo a cerca de R$ 260 bilhões em 2026 (ABComm, 2026), nenhuma operação online pode pagar para descobrir isso no dia do fechamento.
A Onclick opera essa troca pela migração assistida. O ERP Onclick, com o hub APIECOMM, o KPL e o PDV Web na mesma base, valida nota, estoque e conciliação em paralelo ao legado antes de assumir o comando. Conheça os benefícios de um sistema ERP integrado e o ERP Onclick, ou veja as soluções de ERP para o seu segmento. Antes de migrar, faça a conta: entenda o TCO, o ROI e o payback da troca de ERP.
Perguntas frequentes
É possível trocar de ERP sem parar de vender?
Sim, pela migração-espelho. O novo ERP roda em paralelo ao legado e cada processo crítico — emissão de nota, baixa de estoque, conciliação de marketplace e fechamento fiscal — é validado antes de o sistema antigo ser desligado. A operação online continua vendendo enquanto a troca é confirmada por fases.
Qual a diferença entre migração-espelho e big bang?
No big bang, o legado é desligado e o novo ERP entra no ar de uma vez, em um único corte de alto risco. Na migração-espelho, os dois sistemas rodam juntos e o corte só acontece depois de cada processo bater com o antigo. Um aposta tudo em um dia; o outro confirma o que já foi testado.
Por que a maioria das migrações de ERP falha?
Por quatro causas de método: optar pelo big bang, migrar dado sujo do legado, tratar a troca como projeto só de TI e trocar o sistema sem revisar o processo. Nenhuma delas é falha do software. Corrigir os dados mestres e validar por fases neutraliza as quatro antes do cutover.
O que validar antes do cutover?
Quatro controles: certificação das APIs de marketplace e plataforma; conciliação diária de estoque, receita e apuração fiscal batendo entre os sistemas; plano de rollback com o legado ainda ativo; e treinamento por papel concluído. Só com os quatro verdes o legado é desligado, de preferência módulo por módulo.
Por que validar a conformidade fiscal é obrigatório ao migrar em 2026?
Porque a transição de CBS e IBS começou em 2026 e um erro tributário impacta o caixa rápido. Os campos já constam na NF-e e na NFC-e em fase de teste (1%: 0,9% de CBS e 0,1% de IBS), com obrigatoriedade avançando em agosto de 2026 pela NT RFB/CGIBS nº 2025.002. Nota sem os campos corretos é rejeitada e trava a venda.