Como migrar dados de outro ERP para o Odoo com segurança

Migrar para o Odoo não significa apenas configurar um novo sistema. Em algum momento, a empresa precisa decidir o que fazer com os dados acumulados no ERP anterior.

Clientes, fornecedores, produtos, preços, estoques, contratos, títulos financeiros, pedidos, documentos fiscais e históricos podem ser necessários para que a nova operação comece com continuidade.

Copiar tudo sem análise pode transportar cadastros duplicados, códigos inconsistentes, informações obsoletas e regras que já deveriam ter sido abandonadas.

Por isso, a migração deve ser tratada como um projeto de dados, com escopo, critérios de validação, cargas de teste, responsáveis e um plano de corte para a entrada em produção.

Resposta direta: como migrar dados para o Odoo?

O processo normalmente envolve oito etapas:

Inventariar as fontes, definir o escopo, extrair os dados, sanear as informações, mapear campos e relacionamentos, realizar cargas de teste, conciliar os resultados e executar a carga final.

Dependendo da complexidade, a migração pode utilizar planilhas de importação, scripts em Python, consultas ao banco do sistema anterior, APIs ou uma combinação dessas abordagens.

A ferramenta utilizada para importar é importante. Mas o maior trabalho geralmente está em decidir o significado de cada dado e garantir que ele continue correto depois da transformação.

Migração de outro ERP não é upgrade do Odoo

É importante separar dois projetos diferentes.

Migração de outro ERP para o Odoo

Os dados saem de um sistema com estruturas, conceitos e regras próprias e precisam ser transformados para os modelos do Odoo.

Exemplos incluem migrar de sistemas proprietários, softwares contábeis, ERPs nacionais, planilhas ou aplicações desenvolvidas internamente.

Upgrade de uma versão antiga do Odoo

Nesse caso, a base já utiliza os modelos do Odoo, mas precisa ser adaptada para uma versão mais recente.

O upgrade envolve mudanças no banco de dados, nos módulos e nas customizações. Ferramentas como os serviços oficiais de upgrade ou o projeto OpenUpgrade podem fazer parte dessa estratégia, conforme a edição e a arquitetura utilizada.

É necessário migrar todo o histórico?

Na maioria dos projetos, não.

A empresa deve avaliar quais dados são necessários para operar, atender obrigações, consultar informações relevantes e tomar decisões.

Uma estratégia comum é separar os dados em camadas:

Migrar dez anos de pedidos apenas porque eles existem pode elevar custo, tempo e risco sem gerar benefício proporcional.

Em alguns casos, preservar o sistema antigo em modo de consulta ou criar um repositório histórico é mais eficiente.

Histórico não precisa obrigatoriamente morar no novo ERP para continuar disponível.

Quais dados normalmente são migrados?

Clientes e fornecedores

Razão social, nome, documentos, inscrições, endereços, contatos, condições comerciais e informações fiscais.

Produtos e serviços

Códigos internos, descrições, unidades, categorias, preços, custos, classificações fiscais, fornecedores e códigos de barras.

Estoque

Quantidades por produto, localização, lote, número de série, validade e proprietário, quando aplicável.

Financeiro

Títulos em aberto, vencimentos, parcelas, contas bancárias, formas de pagamento e informações necessárias à cobrança ou ao pagamento.

Contabilidade

Plano de contas, saldos, lançamentos de abertura e dimensões analíticas, conforme o escopo contábil do projeto.

Pedidos e contratos em andamento

Documentos que ainda produzirão entregas, faturamento, compras, atividades ou obrigações futuras.

Projetos e serviços

Projetos ativos, tarefas, etapas, horas, contratos, equipes e informações necessárias à continuidade operacional.

Documentos e anexos

Arquivos relevantes que precisam permanecer vinculados aos registros do novo sistema.

A primeira etapa é conhecer as fontes

Antes de criar qualquer planilha de importação, é necessário entender de onde os dados serão extraídos.

As fontes podem incluir:

Banco de dados do ERP anterior, relatórios, arquivos CSV, planilhas, APIs, pastas compartilhadas, sistemas satélites e documentos armazenados fora do sistema principal.

Também é importante identificar quem conhece cada informação.

O time comercial pode compreender os clientes, o estoque conhece produtos e saldos, o financeiro valida títulos e a contabilidade avalia contas e lançamentos.

Inventário de dados

O inventário registra quais conjuntos de dados existem e o que será feito com cada um.

Esse inventário evita descobrir na semana do go-live que existe uma planilha indispensável conhecida por apenas uma pessoa.

Saneamento: limpar antes de importar

O saneamento corrige ou separa dados inadequados antes da carga.

Entre os problemas mais comuns estão:

Clientes duplicados, documentos inválidos, endereços incompletos, produtos sem unidade, códigos fiscais ausentes, fornecedores inativos, títulos já liquidados e cadastros com convenções diferentes entre filiais.

A limpeza não deve ser feita apenas pela consultoria. A empresa precisa definir regras para:

Identificar duplicidades, escolher o registro principal, completar informações obrigatórias, padronizar códigos e decidir o que pode ser descartado.

Migrar dados ruins com perfeição técnica continua produzindo um resultado ruim.

Mapeamento entre o sistema antigo e o Odoo

O mapeamento descreve como cada campo da origem será transformado no destino.

Algumas correspondências são diretas. Outras precisam de regras.

Por exemplo:

Os relacionamentos são um dos pontos mais importantes.

Um pedido precisa apontar para o cliente certo. Uma linha precisa encontrar o produto correto. Um título precisa estar ligado à empresa e ao documento correspondentes.

Para garantir essa ligação, podem ser utilizados códigos legados e identificadores externos estáveis.

O que são identificadores externos?

Identificadores externos permitem reconhecer um registro de forma estável durante importações e atualizações.

Por exemplo, o cliente 4587 do sistema antigo pode receber um identificador que preserve essa referência.

Em cargas futuras, o processo consegue localizar o mesmo registro em vez de criar uma nova cópia.

Essa estratégia é útil para:

Repetir cargas de teste, atualizar cadastros, manter relacionamentos e rastrear a origem das informações.

Planilha, script ou integração?

A ferramenta depende do volume, da complexidade e da frequência da carga.

Importação por planilha

É adequada para cadastros simples, volumes controlados e cargas pontuais.

O Odoo possui ferramentas para importar registros a partir de arquivos estruturados. Entretanto, as importações são permanentes e precisam ser testadas previamente em um ambiente separado.

Scripts em Python

São indicados quando existem transformações complexas, relacionamentos, grandes volumes, múltiplas etapas ou necessidade de repetir o processo com controle.

O script pode validar dados, registrar erros, controlar lotes e gerar relatórios de conciliação.

Acesso ao banco de origem

Pode facilitar extrações extensas, desde que exista documentação e acesso autorizado.

Mesmo com acesso direto, não é recomendável copiar tabelas para o banco do Odoo. Os dados precisam respeitar seus modelos, regras e relacionamentos.

Integração por API

Pode ser utilizada quando os dois sistemas precisam operar paralelamente durante um período ou quando a origem não fornece acesso direto aos dados.

É necessário tratar autenticação, paginação, limites, falhas e reprocessamento.

Inserir registros diretamente no PostgreSQL pode parecer rápido, mas ignora regras do Odoo e cria riscos difíceis de detectar. Velocidade sem integridade é só um acidente chegando antes.

Por que realizar cargas de teste?

A primeira carga raramente será a definitiva.

Cargas de teste permitem identificar:

Campos ausentes, valores inválidos, relacionamentos quebrados, diferenças de quantidade, problemas de desempenho e regras de transformação incompletas.

Um ciclo típico pode envolver:

Extração, transformação, carga, validação, correção das regras e nova carga em uma base limpa ou restaurada.

Quanto mais cedo os dados reais forem testados, menor o risco de concentrar descobertas próximo ao go-live.

Como validar os dados migrados?

A validação deve combinar controles quantitativos e funcionais.

Contagem de registros

Comparar a quantidade extraída, rejeitada, consolidada e importada.

Totais financeiros

Conferir valores de contas a receber, contas a pagar, saldos e documentos.

Saldos de estoque

Comparar quantidades por produto, localização, lote e número de série.

Amostragem

Selecionar registros variados e verificar campos, relacionamentos e documentos.

Validação operacional

Utilizar os dados migrados para executar vendas, entregas, cobranças, pagamentos e demais processos.

Rastreabilidade

Manter o código legado ou uma chave que permita localizar o registro original quando houver divergência.

Migração de estoque

O estoque merece atenção especial porque envolve quantidade, localização, custo, lotes, séries e movimentações.

Uma estratégia comum é definir uma data de corte, concluir ou congelar movimentos no sistema antigo e importar os saldos de abertura.

É necessário decidir:

Quais localizações serão utilizadas, como os lotes serão identificados, qual data será considerada, como o custo será tratado e como as diferenças serão conciliadas.

Migrar todo o histórico de movimentações pode ser muito mais complexo do que importar a posição inicial do novo sistema.

Migração financeira

No financeiro, o foco costuma estar nos títulos ainda em aberto na data do corte.

A carga pode incluir:

Cliente ou fornecedor, documento, vencimento, valor original, saldo, parcela, banco, forma de pagamento e informações de cobrança.

É necessário evitar títulos já liquidados, duplicidades e divergências entre o valor total e o saldo restante.

Quando existem boletos, remessas ou integrações bancárias, a estratégia também precisa considerar identificadores e dados utilizados pelos bancos.

Migração contábil

A contabilidade pode ser tratada de diferentes formas, conforme o projeto.

Algumas empresas iniciam com saldos de abertura. Outras precisam migrar lançamentos detalhados de determinados períodos.

A decisão deve envolver os responsáveis contábeis e considerar:

Plano de contas, diários, parceiros, centros de custo, contas analíticas, períodos, documentos e obrigações de auditoria.

Quanto maior o detalhamento histórico, maior será o esforço de mapeamento e conciliação.

Anexos e documentos históricos

Arquivos podem representar uma parte significativa da migração.

Contratos, XML, PDFs, imagens, propostas e comprovantes precisam ser classificados.

Para cada grupo, avalie:

Necessidade de consulta, vínculo com registros, volume, formato, duplicidades, retenção legal e custo de armazenamento.

Nem todo arquivo precisa ser anexado ao Odoo. Um repositório documental integrado ou uma base histórica pode ser mais apropriado.

O plano de corte

O plano de corte define como a empresa interromperá o uso do sistema antigo e começará a operar no Odoo.

Ele deve responder:

Quando o sistema antigo será congelado? Quem fará a extração final? Quanto tempo a carga levará? Quem validará os saldos? Quando os usuários serão liberados? O que acontece se a validação falhar?

Também é importante definir o tratamento das operações que surgirem durante a janela de migração.

Em alguns projetos, a carga final acontece durante um fim de semana. Em outros, existe uma transição por áreas ou empresas.

O go-live não é o momento de descobrir quanto tempo a carga demora. Esse tempo deve ter sido medido nos ensaios anteriores.

É possível operar os dois sistemas ao mesmo tempo?

Sim, mas a operação paralela precisa ser cuidadosamente planejada.

Quando os dois sistemas permitem criar ou alterar os mesmos dados, surgem dúvidas sobre qual deles é a fonte oficial.

Se o paralelo for necessário, defina:

Quais processos ficam em cada sistema, por quanto tempo, como os dados serão sincronizados, quem resolve divergências e qual evento encerra a transição.

Manter dois ERPs ativos sem essas regras costuma duplicar trabalho e gerar versões diferentes da realidade.

Erros comuns na migração

Deixar a migração para o final

O desenho dos dados influencia configurações, processos e relatórios. Ele precisa começar cedo.

Querer migrar tudo

Volume não é sinônimo de valor. Dados sem uso claro aumentam custo e risco.

Não definir responsáveis funcionais

A consultoria não pode decidir sozinha quais clientes estão duplicados ou quais saldos são corretos.

Realizar apenas uma carga

Sem ensaios, erros de mapeamento aparecem na carga definitiva.

Não preservar referências da origem

Sem códigos legados ou identificadores, investigar divergências fica muito mais difícil.

Validar apenas a quantidade

Ter mil clientes nos dois sistemas não garante que sejam os mesmos clientes com os mesmos dados.

Inserir diretamente no banco

Ignorar as regras do Odoo pode criar inconsistências sem sinais imediatos.

Não documentar as transformações

Sem documentação, cada nova carga se transforma em uma interpretação diferente.

Como a Escodoo conduz a migração

Na Escodoo, a migração é planejada junto com a implantação, e não tratada como uma tarefa isolada próxima ao go-live.

Nossa abordagem normalmente envolve:

Inventário das fontes, definição de escopo, layouts de migração, saneamento pelo cliente, scripts ou importações controladas, cargas de teste, relatórios de divergência, validação funcional e ensaio do corte final.

Quando necessário, desenvolvemos rotinas em Python para transformar e carregar dados de forma repetível.

Também procuramos preservar identificadores da origem, facilitando rastreabilidade, conciliação e eventuais correções.

Perguntas frequentes

O Odoo importa arquivos Excel?

O Odoo possui ferramentas de importação para arquivos estruturados, que podem ser utilizados em cargas de cadastros e atualizações em massa. O layout precisa respeitar os campos e relacionamentos do modelo.

Uma importação pode ser desfeita?

As importações alteram permanentemente os registros. Por isso, devem ser testadas em ambiente de homologação e executadas com backup e critérios de controle.

Posso migrar todos os documentos do ERP antigo?

É tecnicamente possível em muitos cenários, mas o custo e a complexidade podem não compensar. Avalie a necessidade operacional, legal e gerencial de cada histórico.

Quanto tempo leva uma migração?

O prazo depende do número de fontes, volume, qualidade, quantidade de relacionamentos, transformações e ciclos de validação. Dados organizados podem reduzir o esforço; dados inconsistentes podem consumir grande parte do cronograma.

Quem deve limpar os dados?

A consultoria pode identificar problemas e criar regras de transformação, mas a empresa precisa decidir quais informações são corretas, duplicadas ou dispensáveis.

É melhor migrar histórico ou manter o sistema antigo?

Depende da frequência de consulta, do custo de manutenção, das obrigações e da facilidade de acesso. Uma solução híbrida pode ser mais eficiente.

Posso alterar dados importados depois?

Sim, mas correções em massa precisam preservar identificadores e evitar a criação de duplicidades.

OpenUpgrade migra qualquer ERP para o Odoo?

Não. O OpenUpgrade é voltado à migração entre versões do próprio Odoo. Dados de outro ERP exigem extração, transformação e carga específicas.

Conclusão: migrar dados é escolher o que levar para o futuro

A migração de dados é uma das etapas mais sensíveis de uma implantação do Odoo.

Ela envolve tecnologia, mas também decisões sobre qualidade, histórico, responsabilidade e continuidade operacional.

O caminho mais seguro é definir o escopo cedo, sanear os dados, preservar referências, realizar cargas de teste e conciliar resultados antes da entrada em produção.

Nem todo dado antigo precisa ser descartado. Da mesma forma, nem todo dado antigo precisa ser incorporado ao novo ERP.