A migração de ERP é a passagem da operação de uma empresa de um sistema de gestão para outro, levando cadastros, saldos, documentos em aberto e regras fiscais. Serve para quem precisa trocar de sistema sem perder histórico nem parar o faturamento no dia da virada.
A decisão de trocar de sistema costuma ser tomada bem antes da migração começar. O que trava o projeto vem depois: o medo de perder o histórico, de ficar sem emitir nota na semana da virada e de abrir o mês com um estoque que não bate com a contabilidade.
Esses riscos existem, mas quase todos nascem de decisões que podem ser tomadas com antecedência: o que levar para o sistema novo, em que data cortar, como conferir a carga e o que guardar do sistema antigo.


Migração de ERP é o projeto de transferir a operação de um sistema de gestão antigo para um novo, de forma que a empresa continue vendendo, comprando, produzindo e faturando sem interrupção. Envolve dados, mas também processos, configurações fiscais, integrações e o treinamento de quem usa o sistema todos os dias.

O sistema de onde a empresa sai costuma ser chamado de sistema legado: um software que ainda funciona, mas que já não acompanha a operação, seja por falta de suporte, de integração ou de atualização fiscal. Ele não some no dia da virada. Continua existindo, em modo de consulta, por um bom tempo.
Para ver como isso acontece na prática, vale separar o projeto em duas partes. A primeira é a carga: o que sai do sistema antigo, em que formato e em que ordem. A segunda é a virada, a data em que o sistema novo passa a valer para tudo.
Migração e implantação de ERP andam juntas, mas não são sinônimos. A implantação configura o sistema novo para a rotina da empresa. A migração resolve a transição entre os dois sistemas. Uma empresa que sai da planilha implanta um ERP; uma que já tem um ERP e vai trocar duas coisas ao mesmo tempo.
A hora de migrar de ERP chega quando a equipe passa a compensar à mão o que o sistema atual não faz: planilha paralela para custo ou estoque, nota em um sistema e financeiro em outro, regra fiscal atualizada com meses de atraso. Nesse ponto, ficar já custa mais que migrar.
Em indústria e distribuidora, os sinais costumam aparecer em pontos específicos. O custo do produto é calculado fora do sistema porque o ERP não fecha a ordem de produção com o consumo real.
O saldo do sistema diverge da contagem física toda vez que alguém confere. O fechamento do mês depende de exportar relatórios e cruzar no Excel antes de mandar para a contabilidade.
Há também o momento em que vale esperar. Migrar no pico de sazonalidade, durante uma fiscalização em andamento ou sem uma pessoa interna com horas reservadas para o projeto aumenta o risco de erro na virada.
Os sinais de que o sistema chegou ao limite e os critérios para decidir quando trocar de ERP merecem uma análise própria, antes de o projeto de migração começar.
As etapas da migração de ERP seguem uma ordem fixa: diagnosticar a operação atual, definir escopo e fornecedor, sanear os dados, configurar o sistema novo, carregar e conferir os dados, testar em paralelo e fazer a virada.
Pular uma etapa raramente economiza tempo, porque o problema não resolvido aparece na fase seguinte, só que mais caro.

A sequência abaixo vale tanto para uma distribuidora com um único CD quanto para uma indústria com várias plantas. O que muda é o tempo de cada etapa.
1. Diagnóstico da operação atual. Liste o que o sistema de hoje faz, as planilhas que existem por fora dele e as integrações ativas, como banco, e-commerce, força de vendas e contabilidade.
2. Escopo e escolha do fornecedor. Defina por escrito o que entra na primeira fase e peça a demonstração com os seus cadastros reais, não com a base de exemplo do vendedor.
3. Saneamento dos dados. Corrija e elimine no sistema antigo, antes de exportar, tudo o que estiver duplicado, inativo ou com dado fiscal errado.
4. Configuração do sistema novo. Parametrize regras fiscais, tabelas de preço, estrutura de produto, centros de custo e permissões de acesso.
5. Carga e conferência. Importe por blocos (cadastros, depois saldos e títulos em aberto, por último o estoque) e confira cada bloco contra um relatório do sistema antigo antes de seguir.
6. Homologação em paralelo. Rode os processos críticos nos dois sistemas e emita documentos fiscais reais no novo, conferindo o retorno da SEFAZ.
7. Virada e estabilização. Na data de corte, o sistema novo passa a valer para tudo; o antigo fica só para consulta e a equipe recebe acompanhamento próximo nas primeiras semanas.
Duas etapas concentram a maior parte dos problemas: o saneamento, porque cadastro ruim no sistema antigo continua ruim no novo, e a conferência da carga, porque um saldo errado na abertura contamina todos os relatórios dali em diante. As próximas seções detalham as duas.
Na migração de ERP, o que vai para o sistema novo são os cadastros ativos, os saldos na data de corte e os documentos ainda em aberto. O histórico de movimentações já encerradas fica no sistema antigo, em modo de consulta, e nos arquivos exportados.
A regra prática é migrar o que a operação usa amanhã e guardar o que só a fiscalização ou a auditoria vão pedir.
Levar cinco anos de vendas detalhadas para o sistema novo parece prudente, mas costuma atrasar o projeto e importar erro antigo. Cada nota histórica carrega cadastros e regras da época, e conciliar isso com a configuração nova consome semanas sem benefício para a operação.
A tabela resume o destino de cada tipo de dado:
| Tipo de dado | Vai para o novo ERP? | Como entra | O que conferir |
| Clientes, fornecedores e produtos ativos | Sim, depois do saneamento | Importação de cadastro | Duplicidades, CNPJ, NCM, unidade de medida |
| Contas a pagar e a receber em aberto | Sim | Títulos individuais com vencimento original | Total por cliente e por fornecedor |
| Saldo bancário | Sim | Saldo na data de corte | Extrato do banco no mesmo dia |
| Estoque | Sim | Quantidade e custo unitário por item e local | Contagem física e saldo contábil |
| Pedidos de venda e de compra em aberto | Sim | Só o saldo pendente de cada pedido | Itens já entregues ou recebidos |
| Ordens de produção em andamento | Depende | Encerrar no antigo ou reabrir com consumo parcial | Materiais já requisitados |
| Notas e movimentações encerradas | Não | Ficam no sistema antigo e nos arquivos exportados | Exportação completa dos XML |
O cadastro é a base de tudo o que o sistema novo vai calcular, por isso o saneamento acontece no sistema antigo, antes da exportação. Corrigir depois da carga significa corrigir em dois lugares, ou aceitar que o novo ERP já começa com erro.
No cadastro de produtos, os pontos que mais geram retrabalho são fiscais e de unidade. Um NCM desatualizado leva a rejeição ou a tributação errada na primeira nota.
Uma unidade de compra diferente da unidade de venda, sem o fator de conversão cadastrado, faz o estoque entrar em caixas e sair em unidades, e o saldo deixa de fazer sentido já na primeira semana.
No cadastro de clientes e fornecedores, o problema mais comum é duplicidade: o mesmo CNPJ cadastrado duas vezes, com endereços diferentes, cada um com uma parte do histórico de compras.
Vale também revisar a inscrição estadual e o indicador de contribuinte do ICMS, porque é ele que define a regra fiscal aplicada na nota.
Outro ponto é a regra fiscal amarrada ao cadastro. Se o sistema antigo definia o CFOP por exceções manuais, digitadas pelo faturista, essa lógica não vem no arquivo de exportação. Ela precisa ser reconstruída como regra no sistema novo, e testada com uma nota de cada tipo de operação.
A carga de estoque precisa trazer, para cada item e local, a quantidade contada e o custo unitário da mesma data de corte. Quantidade certa com custo errado parece um detalhe, mas distorce o custo da mercadoria vendida a partir da primeira venda.
O erro mais frequente é carregar o estoque pelo último preço de compra em vez do custo médio que o sistema antigo usava. O valor do estoque sobe na abertura e, quando aquelas unidades são vendidas, o custo da venda sobe junto.
Veja o efeito em um único item de uma distribuidora com faturamento na casa de R$ 1,5 milhão por mês (valores hipotéticos):
| Componente | Carga pelo custo médio | Carga pelo último preço de compra |
| Quantidade em estoque na data de corte | 2.000 caixas | 2.000 caixas |
| Custo unitário carregado | R$ 42,00 | R$ 48,00 |
| Valor do estoque na abertura | R$ 84.000 | R$ 96.000 |
| Receita com a venda das 2.000 caixas a R$ 60,00 | R$ 120.000 | R$ 120.000 |
| Custo da mercadoria vendida | R$ 84.000 | R$ 96.000 |
| Margem bruta | R$ 36.000 (30%) | R$ 24.000 (20%) |
Pode parecer que o erro fica só no valor do estoque. Ele vira custo assim que o produto sai: a margem desse item cai dez pontos no relatório, sem que nada tenha mudado na operação.
A distorção continua depois, porque a próxima compra entra na média ponderada junto com um custo de abertura inflado. O kardex do item no sistema novo já nasce errado.
Por isso, a conferência do estoque tem duas pontas. A quantidade é validada com uma contagem de estoque feita o mais perto possível da data de corte, e o valor total, contra o saldo da conta de estoques na contabilidade no mesmo dia. Diferença entre os dois precisa ser explicada antes da virada.
Quem trabalha com lote e validade tem uma camada a mais: o saldo precisa entrar separado por lote, com a data de validade de cada um. Carregar o total do item sem o lote quebra a rastreabilidade e o controle de lote e validade no primeiro dia.
Documentos em aberto são tudo o que começou no sistema antigo e ainda não terminou na data de corte: pedidos parcialmente atendidos, compras ainda não recebidas, ordens de produção na metade, mercadoria em poder de terceiros. É aqui que a migração de uma indústria ou distribuidora mais se diferencia da de uma empresa de serviços.
Pedidos de venda com entrega parcial entram no sistema novo só com o saldo pendente. Se o pedido original de 500 unidades já teve 300 faturadas no sistema antigo, o novo recebe 200, com o mesmo preço, prazo e condições negociadas.
Carregar o pedido inteiro gera risco de faturar em dobro. A mesma lógica vale para a ordem de compra com recebimento parcial.
Ordens de produção em andamento pedem uma decisão antes da virada. A opção mais limpa é encerrar no sistema antigo tudo o que for possível até a data de corte.
O que sobrar precisa ser reaberto no novo com o material já requisitado registrado, ou a ordem de produção vai pedir de novo um insumo que já saiu do almoxarifado.
Mercadoria em poder de terceiros também precisa entrar separada do estoque próprio: remessa para industrialização, consignação, demonstração. O estoque em poder de terceiros faz parte do patrimônio da empresa, mas não está fisicamente no armazém.
A nota de retorno vai chegar depois da virada referenciando uma remessa emitida no sistema antigo.
No financeiro, cada título em aberto entra individualmente, com vencimento e documento de origem, e não como um saldo único por cliente. É isso que permite baixar o pagamento certo no contas a receber quando o boleto emitido no sistema antigo for pago depois da virada.
Cadastro saneado, estoque com quantidade e custo da mesma data e documentos em aberto só com o saldo pendente são os três pontos que decidem se a carga entra certa. Definido o que levar, falta decidir quando virar.
A data de corte mais segura para a migração de ERP é o primeiro dia de um mês, de preferência um mês de baixa sazonalidade. Ela coincide com o período das obrigações fiscais mensais, permite fechar o mês anterior inteiro no sistema antigo e dá um ponto único de conferência para estoque, financeiro e contabilidade.
A razão fiscal é concreta. Pelo Guia Prático da EFD ICMS/IPI, o arquivo do SPED Fiscal tem periodicidade mensal e, em regra, começa no primeiro dia do mês de cada estabelecimento.
As exceções previstas são eventos como início de atividade ou mudança na forma de escrituração; a troca de software, em regra, não se enquadra.
Na prática, se a virada acontece no dia 15, as notas da primeira quinzena estão no sistema antigo, as da segunda no novo, e o arquivo do SPED Fiscal daquele mês precisa juntar as duas.
Alguém vai ter de importar documentos de um sistema para o outro ou montar o arquivo fora dos dois. Com o corte no dia 1º, cada sistema gera os meses que são seus.
Para indústrias obrigadas ao Bloco K, o efeito é maior. As ordens de produção do mês, os consumos e o estoque escriturado no fim do período saem do mesmo arquivo mensal.
Uma ordem aberta no sistema antigo e encerrada no novo fica partida entre os dois, e reconciliar esse consumo à mão é trabalho que o corte no início do mês evita.
Na contabilidade, a lógica se repete em escala anual. A virada no início do exercício simplifica a escrituração contábil do ano, porque os saldos de abertura do sistema novo coincidem com o encerramento do balanço.
Nem toda empresa consegue esperar janeiro, e não precisa: basta combinar com o contador como os saldos de abertura e o plano de contas serão conciliados no meio do ano.


A estratégia de virada define como o sistema novo entra em uso: tudo de uma vez (big bang), com os dois sistemas rodando juntos por um período (paralelo) ou em partes, módulo a módulo ou unidade a unidade (por fases).
Nenhuma delas serve para todos os casos. A escolha depende de quanto a operação tolera de risco no faturamento e de quanta gente está disponível para lançar em dobro.
| Critério | Big bang | Paralelo | Por fases |
| Como funciona | Todos os módulos e unidades viram no mesmo dia | Os dois sistemas operam juntos por algumas semanas | Entra primeiro um módulo ou uma unidade, depois os demais |
| Risco de parar o faturamento | Alto, se algo falhar na primeira nota | Baixo, o sistema antigo segue emitindo | Médio, concentrado em cada fase |
| Esforço da equipe | Concentrado em poucos dias | Alto, lançamento em dobro | Distribuído ao longo dos meses |
| Integrações provisórias | Nenhuma | Nenhuma | Necessárias entre o módulo novo e o antigo |
| Indicado para | Operação enxuta, com poucos processos críticos | Quem não pode errar na emissão fiscal | Grupos com várias filiais ou plantas |
O paralelo puro tem um custo que costuma ser subestimado: cada pedido, nota e baixa precisa ser lançado duas vezes, e a equipe cansa rápido.
Por isso, em indústria e distribuidora de porte médio, ele funciona melhor curto e focado. Em vez de duplicar a operação inteira, a empresa duplica só os processos mais críticos, como a emissão de nota e a apuração de custo, por duas a quatro semanas.
O modelo híbrido combina as duas lógicas.
Segundo o ERP Report 2026 da Panorama Consulting, mais de um quarto das empresas pesquisadas usou uma abordagem híbrida, com os módulos centrais virando de uma vez e unidades ou funções adicionais entrando depois.
Na prática, para uma distribuidora, isso costuma significar virar faturamento, estoque e financeiro juntos, porque um depende do outro a cada pedido, e deixar para uma segunda fase o que pode esperar, como a integração com a força de vendas ou o WMS.
Quem divide em fases precisa planejar as integrações provisórias entre o módulo novo e o antigo, que somem depois, mas custam horas enquanto existem.
Migrar o ERP para a nuvem pode significar duas coisas diferentes, e o processo muda bastante entre elas. Uma é levar o mesmo sistema de um servidor local para um servidor em nuvem. A outra é trocar de sistema e passar a usar um ERP na nuvem oferecido como serviço, que já nasce online.
No primeiro caso, o software é o mesmo, os cadastros são os mesmos e a regra fiscal é a mesma. O projeto é de infraestrutura: copiar o banco de dados, ajustar acessos e garantir desempenho. Não há saneamento nem nova parametrização, e o risco fica concentrado na janela técnica da transferência.
No segundo caso, a migração é completa. Tudo o que vale para uma troca de sistema se aplica: saneamento, carga, data de corte, homologação e virada.
A diferença é que a empresa deixa de cuidar de servidor, backup e atualização de versão, que passam a ser responsabilidade do fornecedor. Parte da conversa sobre nuvem na busca por migração de ERP mistura os dois casos, e vale perguntar ao fornecedor qual deles está sendo proposto.
Em indústria ou distribuidora de porte médio, uma migração de ERP costuma levar de três a seis meses entre o diagnóstico e a virada, com mais algumas semanas de estabilização depois.
O prazo depende menos do tamanho da empresa e mais de três fatores: a qualidade dos cadastros, o número de integrações e a disponibilidade de uma pessoa interna para conduzir o projeto.
Uma divisão comum, como estimativa de referência, é de três a seis semanas para diagnóstico e escopo, outras quatro a oito para saneamento e configuração, três a seis para carga e conferência e duas a quatro de homologação em paralelo.
Empresas com cadastro limpo e poucas integrações ficam perto do piso. Quem tem cadastro duplicado, regra fiscal por exceção e várias filiais fica perto do teto.
Projetos maiores levam mais tempo. No ERP Report 2026 da Panorama Consulting, que ouviu empresas com receita anual mediana de US$ 200,5 milhões, a mediana de duração foi de nove meses. Quase um quarto delas terminou atrasado, e a causa mais citada foram questões organizacionais, como aprovações demoradas, resistência à mudança e redesenho de processos.
Esse último dado vale para empresas de qualquer porte. O que costuma atrasar a migração é a validação que depende de alguém da operação, a decisão de processo que fica sem dono e a equipe sem horas reservadas para o projeto. Um responsável interno com agenda protegida é a medida que mais encurta o cronograma.

Os principais riscos da migração de ERP são parar a emissão de notas na virada, perder histórico fiscal ao desligar o sistema antigo, começar com saldos de estoque e financeiro errados e estourar prazo e orçamento por escopo mal definido. Quase todos aparecem semanas depois da virada, não no primeiro dia.

O estouro de orçamento é o risco mais comum. No ERP Report 2026 da Panorama Consulting, mais de um quarto das empresas terminou acima do orçamento, e a causa mais citada foi a necessidade inesperada de tecnologia adicional: uma integração, um relatório ou um módulo fora do escopo porque ninguém checou se o sistema escolhido atendia aquele processo.
Esse risco se reduz na escolha do fornecedor, com a demonstração feita sobre os processos reais da empresa. Se a operação depende de integração com banco, e-commerce ou força de vendas, a integração de ERP, precisa ser demonstrada funcionando antes da assinatura, e não prometida para depois da virada.
A parada no faturamento costuma vir de configuração fiscal testada só com notas simples. A primeira nota de devolução, de remessa para industrialização ou de venda interestadual para não contribuinte sai no sistema novo e volta rejeitada. O antídoto é a homologação com uma nota real de cada tipo de operação que a empresa faz, inclusive as raras.
O saldo errado na abertura é o risco mais silencioso, porque o sistema funciona normalmente com ele. Só aparece quando a contagem física não bate, quando o custo dispara sem motivo ou quando a contabilidade não consegue conciliar a conta de estoques. A conferência por blocos, descrita nas etapas, existe para pegar isso antes da virada.
Por último, o risco humano. Uma equipe que não participou dos testes descobre na virada que o processo mudou e volta para a planilha por segurança.
Envolver quem emite nota, cobra cliente e confere estoque desde a homologação é o que faz o sistema novo ser usado de verdade, e o que permite medir depois o ROI do ERP com dados confiáveis.
Do sistema antigo, a empresa precisa guardar os XML das notas emitidas e recebidas, os arquivos do SPED já entregues e os registros contábeis. Em regra, o prazo é de cinco anos contados a partir do ano seguinte ao da emissão, e fica maior quando há fiscalização ou cobrança em discussão.
Na prática, uma nota emitida em março de 2026 precisa estar disponível até o fim de 2031, mesmo que a empresa tenha trocado de sistema no meio do caminho. E o que vale é o arquivo XML: o DANFE em PDF sozinho não tem validade fiscal.
Talvez você já tenha visto o prazo de 11 anos. Ele existe, mas trata da guarda feita pelo próprio fisco. Para a empresa, a obrigação continua seguindo o prazo de cinco anos, e guardar por mais tempo é uma escolha de segurança.
Antes de encerrar o contrato com o fornecedor antigo, exporte os XML, os arquivos do SPED com os recibos de entrega e os relatórios de movimentação, e abra alguns para testar. Deixar o sistema antigo em consulta por alguns meses ajuda, mas os arquivos precisam ficar com a empresa, porque o acesso costuma acabar junto com o contrato.
O saneamento também é a hora de olhar os dados pessoais. A LGPD permite manter o que a empresa precisa para cumprir obrigação fiscal, como os dados de clientes que aparecem nas notas. Contatos de clientes inativos, sem ligação com nenhuma nota guardada, podem ficar de fora da carga.
Uma migração de ERP bem feita depende de poucas decisões tomadas cedo: sanear os cadastros antes de exportar, carregar o estoque com quantidade e custo da mesma data, tratar cada documento em aberto, cortar no primeiro dia do mês e guardar o histórico fiscal pelo prazo da lei. Resolvido isso, o dia da virada passa a ser um dia de trabalho comum.
Depois da virada, o ERP WebMais sustenta a operação inteira em uma única base, conectando vendas, compras, estoque, produção, fiscal e financeiro em indústrias, com o ERP para indústria, e distribuidoras, com o ERP para distribuidoras.
A implantação começa pelo mapeamento dos processos mais importantes da sua rotina, presencial ou online, e segue priorizada para o sistema ser usado corretamente desde o primeiro dia.
Se a sua empresa está planejando trocar de sistema, agende uma demonstração gratuita do ERP WebMais e veja, com os seus processos, como a migração funcionaria na sua operação.


Sim. O caminho é homologar a emissão fiscal no sistema novo, com notas reais de cada tipo de operação, enquanto o antigo continua faturando. A virada só acontece depois que a emissão foi validada, de preferência no primeiro dia útil do mês.
Não. O histórico de vendas encerradas fica no sistema antigo, em modo de consulta, e nos arquivos XML exportados. Para análise de tendência, algumas empresas levam um resumo mensal de vendas por produto e cliente dos últimos dois anos, sem as notas individuais.
As duas partes. O fornecedor do sistema novo define o formato de importação, faz a carga e configura o sistema. A empresa é responsável por exportar do sistema antigo, sanear os cadastros e conferir cada bloco carregado, porque só quem opera sabe se um saldo está certo.
O custo tem três partes: a licença ou mensalidade do sistema novo, os serviços de implantação e migração, e as horas da equipe interna. Os serviços variam conforme o número de módulos, de integrações e a qualidade dos dados. As horas internas são a parte mais esquecida no orçamento.
Mantenha o sistema antigo em modo de consulta por alguns meses, até a operação se estabilizar no novo. Antes de encerrar o contrato, exporte os XML, os arquivos do SPED com recibos e os registros contábeis, e guarde tudo em local controlado pela própria empresa.
Não. A implantação configura um sistema para a rotina da empresa. A migração é a transição de um sistema existente para outro, com carga de dados e virada. Quem troca de ERP faz as duas ao mesmo tempo.
Conteúdo quinzenal