Migração de ERP: Como Trocar de Sistema Sem Parar a Operação

Quando migrar (e quando não migrar)

Migrar de ERP é caro, demorado e arriscado se feito sem necessidade real. Antes de iniciar o projeto, vale confirmar que o problema de fato está no sistema — não no uso que se faz dele.

1. Migre quando: o sistema trava o crescimento

   Se abrir uma nova filial, adicionar um módulo ou aumentar o volume de notas fiscais exige um projeto de customização caro e lento, o ERP atual se tornou um freio estrutural.

2. Migre quando: o custo total já não se justifica

   Quando a soma de licenças, customizações e suporte supera o custo de um novo ERP amortizado ao longo de alguns anos, a conta deixa de fazer sentido.

3. Migre quando: o sistema está em fim de vida

   Fornecedor sem perspectiva de evolução, base de profissionais encolhendo e risco de ficar sem suporte técnico são sinais de que esperar só aumenta o risco.

4. Não migre ainda se: o problema é de processo, não de sistema

   Se a reclamação é 'o sistema é lento' mas a causa real é falta de parametrização, retrabalho manual ou processo mal desenhado, um projeto de reestruturação no próprio ERP atual pode resolver por uma fração do custo.

5. Não migre ainda se: faltam dados confiáveis para decidir

   Trocar de ERP sem antes limpar e organizar os dados do sistema atual só transporta a desorganização para o sistema novo, com o custo extra de uma migração no meio do caminho.

6. Não migre ainda se: a equipe não está pronta para o esforço

   Uma migração exige dedicação real dos times-chave durante meses. Se a empresa está no meio de outra crise operacional, o timing errado pode comprometer os dois projetos.

Migração, atualização ou reimplementação: as diferenças

Esses três termos são usados de forma intercambiável no mercado, mas descrevem projetos com risco e esforço bem diferentes — confundi-los no início costuma gerar escopo e orçamento mal dimensionados.

Atualização de versão é trocar a versão do mesmo ERP, mantendo o mesmo fornecedor e, normalmente, a mesma base de dados e estrutura de processos. É o projeto mais simples dos três, embora versões muito antigas possam exigir um esforço próximo ao de uma migração completa.

Reimplementação é reconfigurar o mesmo ERP do zero, sem trocar de sistema — geralmente porque a implantação original ficou mal parametrizada, acumulou customizações problemáticas ou porque a empresa mudou tanto de processo que vale mais recomeçar a configuração do que corrigi-la aos poucos.

Migração de ERP, no sentido mais completo, é sair de um sistema (ou de planilhas) para outro ERP diferente, de outro fornecedor. É o cenário de maior risco e esforço porque muda a estrutura de dados, a lógica de parametrização e, normalmente, a forma como cada processo é operado no dia a dia — nada pode ser simplesmente 'copiado' de um sistema para o outro sem tradução.

Fases do projeto de migração

Uma migração de ERP segue uma sequência clara de fases, cada uma com entregas validadas antes de avançar para a próxima.

1. 1. Diagnóstico e escopo

   Mapeamos o que o sistema atual faz hoje — processos, integrações, relatórios críticos, customizações — e definimos o que precisa existir no novo ERP no primeiro dia de operação.

2. 2. Desenho da solução

   Traduzimos cada processo atual para o novo sistema, decidindo o que é padrão do ERP de destino, o que precisa de parametrização específica e o que exige desenvolvimento sob medida.

3. 3. Mapeamento e extração de dados

   Identificamos quais dados do sistema de origem precisam migrar, em que formato estão e qual a regra de transformação para que façam sentido na estrutura do novo ERP.

4. 4. Configuração e desenvolvimento

   Parametrizamos o novo sistema, construímos as rotinas de carga de dados e desenvolvemos as integrações e customizações definidas na fase de desenho.

5. 5. Migração de dados e testes de integridade

   Executamos a carga de dados em ambiente de homologação e validamos, registro a registro quando necessário, que os saldos, históricos e cadastros migraram corretamente.

6. 6. Testes integrados e treinamento

   Os usuários-chave testam os processos ponta a ponta no novo sistema com dados reais, e a equipe é treinada antes de qualquer decisão sobre a data de corte.

7. 7. Cutover (virada)

   Planejamos o momento exato da virada — normalmente um fim de semana ou período de baixo movimento — com um roteiro minuto a minuto e um plano de rollback caso algo saia do previsto.

8. 8. Estabilização pós-go-live

   Acompanhamos de perto as primeiras semanas de operação no novo sistema, com suporte dedicado para resolver rapidamente qualquer ajuste que só aparece com o uso real.

Migração de dados e histórico

Uma das perguntas mais frequentes em qualquer migração é o que fazer com anos de histórico acumulado no sistema atual — notas fiscais, movimentações de estoque, lançamentos financeiros, histórico de atendimento a clientes.

A resposta raramente é 'migrar tudo'. Nem todo histórico precisa viver dentro do novo ERP para estar disponível. Em geral, separamos os dados em três categorias: dados operacionais vivos (cadastros de clientes, fornecedores, produtos e saldos atuais, que precisam estar 100% corretos no novo sistema desde o primeiro dia), histórico recente relevante para a operação (normalmente os últimos exercícios fiscais, necessários para comparação e para obrigações legais) e histórico de longo prazo (que pode ficar arquivado em um ambiente de consulta, sem precisar ocupar a estrutura do ERP novo).

Essa separação importa porque migrar todo o histórico bruto para dentro do novo sistema costuma ser caro, lento e, na maioria dos casos, desnecessário — o time de auditoria ou fiscal raramente precisa consultar um lançamento de cinco anos atrás dentro do ERP do dia a dia; precisa conseguir acessá-lo quando for preciso.

Por isso, definimos junto com o cliente, ainda na fase de diagnóstico, qual é a janela de histórico que realmente precisa estar operacional dentro do novo ERP e qual pode ficar em um ambiente de consulta (um banco de dados legado mantido só para leitura, por exemplo), reduzindo o volume e o risco da carga de dados sem perder nenhuma informação.

Riscos e plano de contingência

Toda migração de ERP carrega risco — a pergunta certa não é 'como eliminar o risco' (impossível), mas 'como ele é identificado e mitigado antes de se tornar um problema real na operação'.

O risco mais comum é a perda ou corrupção de dados durante a carga: um cadastro migrado com o CNPJ errado, um saldo de estoque que não bate, uma duplicidade de lançamento financeiro. Mitigamos isso com testes de integridade em homologação, comparando totais e amostras entre o sistema de origem e o de destino antes de qualquer dado ir para produção.

O segundo risco mais comum é operacional: a equipe não estar pronta para operar o novo sistema no dia do go-live, gerando erro de digitação, processo mal executado ou retrabalho nas primeiras semanas. Mitigamos com treinamento antes da virada e suporte presencial ou remoto intensivo logo depois do go-live.

O terceiro risco é o de continuidade do negócio durante o cutover: a empresa não pode parar de vender, faturar ou pagar fornecedores enquanto o sistema está sendo trocado. Por isso o cutover é planejado com um roteiro detalhado, uma janela de baixo movimento quando possível, e um plano de rollback — a capacidade de voltar a operar no sistema antigo rapidamente se um problema crítico for identificado antes da virada se consolidar.

Por fim, existe o risco fiscal e de compliance: lançamentos feitos no período de transição precisam ser auditáveis e corretos nos dois sistemas. Esse ponto é tratado junto com a equipe fiscal e contábil do cliente desde o desenho do projeto, não como um detalhe de última hora.

Quanto tempo leva uma migração de ERP

Não existe um prazo único — o tempo de uma migração de ERP depende do número de módulos em uso, do volume e da qualidade dos dados a migrar, da quantidade de integrações com outros sistemas e da complexidade fiscal e societária da empresa (uma matriz com várias filiais em estados diferentes leva mais tempo do que uma operação de CNPJ único).

Em termos qualitativos: uma migração mais simples, com poucos módulos e dados relativamente limpos, tende a se concentrar em semanas de projeto ativo mais um período de estabilização pós-go-live. Uma migração de maior porte, com múltiplos módulos, integrações críticas e grande volume histórico, se estende por vários meses, com fases de diagnóstico e desenho mais longas antes mesmo de qualquer dado começar a ser migrado.

O fator que mais influencia o prazo, na prática, não é o tamanho da empresa — é a qualidade dos dados de origem e a clareza do escopo definido no início. Projetos que começam com diagnóstico superficial quase sempre atrasam na fase de migração de dados, quando inconsistências que deveriam ter sido tratadas antes aparecem no meio do caminho.

Conteúdos relacionados

• Consultoria ERP — Implantação, migração e sustentação do seu ERP.
• Integração ERP — Conecte o novo ERP a CRM, BI, e-commerce e sistemas internos.