Migração de Dados para ERP: Guia Estratégico

Oitenta e três por cento dos projetos de migração de dados falham, estouram o orçamento ou perdem o prazo — um número que o Gartner rastreia há anos e que não melhorou significativamente. Mesmo assim, quando empresas de médio porte planejam uma troca de ERP, a migração de dados fica consistentemente por último. É espremida nas semanas finais antes do go-live, delegada sem dono claro e tratada como tarefa técnica — não como o risco estratégico que realmente é.

Sua estratégia de migração de dados para ERP não deve começar quando a implantação começa. Deve começar antes de assinar o contrato.

Por Que a Maioria das Migrações de Dados Falha

As causas são conhecidas. Três causas-raiz aparecem em praticamente toda análise pós-mortem: gestão de mudança inadequada, execução ruim da migração de dados e equipes sem experiência. Segundo a análise da Curiosity Software sobre falhas de migração, esses três fatores são responsáveis pela maioria das falhas — e se potencializam mutuamente.

Essas categorias se desdobram em padrões que líderes de TI reconhecem de imediato.

Dados sujos tratados como problema de go-live. As equipes descobrem problemas de qualidade durante a migração — duplicatas, campos faltando, formatos inconsistentes — e tentam consertar sob pressão de prazo. A correção sai apressada e incompleta. O saneamento de dados precisa acontecer meses antes do go-live, não dias antes.

Ninguém é dono. TI assume que o negócio é responsável pelas decisões de qualidade dos dados. As áreas de negócio assumem que TI cuida do mapeamento técnico. O fornecedor da implantação assume que ambos os lados resolveram. Ninguém assina o que será migrado, o que será arquivado e o que ficará para trás.

Prazos comprimidos que geram atalhos em cascata. A diretoria define a data de go-live antes de qualquer avaliação dos dados. Quando o prazo aperta, as rodadas de validação são cortadas, os testes rodam com dados incompletos e a limpeza é adiada para “depois do go-live” — onde raramente acontece.

Segundo a McKinsey, ineficiências em migração representarão mais de US$ 100 bilhões em desperdício nos próximos três anos. A maior parte desse desperdício se concentra no mid-market, onde equipes de TI são menores e a margem para erro é mais estreita.

Os Dados Invisíveis que Ninguém Inventaria

Os dados mais perigosos em qualquer migração não estão no seu ERP. Estão nas planilhas, bancos Access, pastas do SharePoint e arquivos do FileMaker que orbitam ao redor dele.

Esses dados-sombra costumam ser as informações mais críticas da operação: tabelas de preço por cliente, tabelas de frete por transportadora, configurações de produto, fluxos de aprovação, regras de exceção. Vivem em arquivos que uma ou duas pessoas mantêm, e nunca aparecem em nenhum inventário formal.

No planejamento da migração, as equipes focam nos sistemas visíveis — o ERP, o CRM, o sistema contábil. Os dados-sombra aparecem tarde, geralmente quando alguém pergunta “cadê a tabela de preços?” duas semanas depois do cutover.

Por que isso é um problema específico do mid-market:

Equipes enxutas criam gambiarras. Quando o sistema não faz exatamente o que é preciso, alguém cria uma planilha para cobrir a lacuna. Com o tempo, essa planilha vira missão crítica.
Sem governança formal de dados. Empresas grandes têm stewards de dados e frameworks de governança. Empresas de médio porte têm “a pessoa que sabe onde está aquele arquivo.” Já escrevemos sobre dependência de pessoa-chave como risco de negócio — dados-sombra são onde esse risco se concentra durante migrações.
A troca de sistema expõe a dependência. O ERP antigo e seus arquivos satélites formavam um sistema informal. Substituir apenas o ERP sem considerar os satélites quebra fluxos que ninguém documentou.

Antes de iniciar qualquer migração, faça uma auditoria de dados-sombra. Entreviste todos os departamentos — não apenas os gestores, mas as pessoas que fazem o trabalho diário. Pergunte: “Quais arquivos vocês usam todo dia que não estão no sistema principal?” As respostas vão redefinir o escopo da sua migração.

Se você já trabalhou com mapeamento de processos, essa auditoria é a contraparte de dados — e igualmente crítica.

Quem Deve Ser o Dono da Migração de Dados?

Essa pergunta aparece em toda implantação de médio porte, e a resposta errada é a mais comum: “todo mundo.”

Responsabilidade compartilhada na prática significa nenhuma responsabilidade. A migração de dados precisa de uma única pessoa responsável — um Líder de Migração de Dados — com autoridade para tomar decisões cross-funcionais sobre o que será migrado, limpo e arquivado.

O papel de cada grupo:

TI gerencia a execução técnica: extração, transformação, carga e configuração do sistema. Cuida do como.
Áreas de negócio decidem sobre qualidade dos dados: quais registros são precisos, quais são obsoletos, quais precisam de correção. Cuidam do quê.
O fornecedor da implantação traz a expertise do sistema-alvo: mapeamento de esquema, requisitos de campos, especificações de formato. Cuida do onde.
O Líder de Migração orquestra os três, resolve conflitos e segura o cronograma. Cuida do resultado.

Essa função não exige uma nova contratação. Na nossa experiência com empresas de médio porte, os líderes de migração mais eficazes são profissionais seniores de TI ou gestores de operações que entendem tanto a tecnologia quanto os processos de negócio. A qualificação principal não é profundidade técnica — é autoridade cross-funcional e disposição para tomar decisões impopulares sobre qualidade de dados.

Estratégia de Migração em Fases para o Mid-Market

A abordagem “big bang” — migrar todos os dados de uma vez no fim de semana do go-live — funciona para volumes pequenos e esquemas simples. Para empresas de médio porte em transição de ERP, uma abordagem faseada reduz riscos ao expor problemas cedo, quando ainda há tempo de corrigir.

Fase 1: Avaliar e inventariar (semanas 1–4).

Mapeie cada fonte de dados, incluindo os dados-sombra. Para cada fonte, documente:

Quais dados contém e qual o volume
Quem é o dono e quem usa no dia a dia
Como se conecta a outros sistemas — de forma automática ou manual
Qual percentual é corrente, histórico ou obsoleto

A maioria das empresas de médio porte descobre que só precisa migrar ativamente 40–60% dos dados. O restante são registros históricos que pertencem a um arquivo, não ao sistema novo.

Fase 2: Sanear antes de mover (semanas 4–10).

Migrar dados sujos para um sistema limpo contamina o ambiente novo. O saneamento inclui:

Deduplicação. Unificar registros de clientes que existem em três versões levemente diferentes entre os sistemas.
Padronização. Formatos de telefone, endereços, convenções de nome, formatos de data — escolha um padrão e aplique. No Brasil, isso inclui padronizar CNPJ, Inscrição Estadual e dados de NF-e.
Validação. Verificar que campos obrigatórios têm valores reais, não placeholders. Confirmar que relacionamentos entre registros estão intactos.
Decisões de arquivamento. Negócios fechados de 2015, fornecedores inativos, códigos de produto obsoletos — defina o que migra e o que fica. Para empresas brasileiras, atenção especial à retenção exigida pelo SPED Fiscal e obrigações acessórias.

Se seus dados vivem em silos entre sistemas desconectados, espere que essa fase leve mais tempo do que o planejado. Conciliar registros que nunca foram feitos para coexistir é um trabalho lento e detalhado.

Fase 3: Mapear e fazer carga de teste (semanas 8–14).

Mapeie campos de origem para campos de destino no sistema novo. É aqui que as diferenças de estrutura aparecem — o sistema antigo armazena “cliente” como um registro único, o novo separa em “empresa” e “contato.”

Faça cargas de teste com dados reais cedo. Carregar dados de produção reais em um ambiente de teste meses antes do go-live expõe erros de mapeamento, problemas de performance e dados faltantes quando ainda dá para corrigir. Isso é fundamentalmente diferente de testar com dados sanitizados, que escondem os casos de borda que quebram em produção.

Fase 4: Validar e fazer cutover (semanas 12–16).

Validação é a etapa que é cortada quando o prazo aperta. Não deixe isso acontecer.

Validação de contagem. O sistema-alvo tem o mesmo número de registros que a origem?
Verificação pontual por campo. Amostrar registros entre tipos de dados e verificar cada campo.
Validação de lógica de negócio. Totais calculados, relacionamentos e relatórios produzem os resultados esperados?
Teste de aceitação do usuário. As pessoas que usam os dados no dia a dia verificam que seus fluxos de trabalho funcionam com os dados migrados.

Defina uma data de cutover firme com critérios de rollback. Se a validação revelar problemas críticos, você precisa de um framework de decisão claro: adiar o go-live, remediar no lugar ou reverter.

O Que Acontece Depois do Go-Live

A maioria dos guias de migração para no cutover. A realidade é que o primeiro mês pós-migração é uma fase legítima do projeto — não uma limpeza.

Nas duas primeiras semanas, os usuários vão encontrar erros que os testes não pegaram. Um preço que migrou errado. Um cadastro de cliente que fundiu duas empresas diferentes. Um relatório histórico mostrando números diferentes dos anteriores.

Planeje isso antes do cutover:

Estabeleça um processo de triagem de problemas. Defina como usuários reportam problemas, quem investiga e qual o caminho de escalação. Uma planilha compartilhada e uma daily de 15 minutos funcionam melhor que um sistema de chamados que ninguém verifica.
Mantenha o sistema antigo acessível em modo somente leitura por um período definido. Os usuários vão precisar consultar dados históricos, e ter o sistema antigo disponível reduz o pânico.
Agende uma revisão de qualidade de dados em 30 dias. Compare relatórios e métricas-chave entre os sistemas antigo e novo. Investigue divergências — especialmente totais que estão próximos mas não exatos, e registros que migraram mas perderam seus relacionamentos.
Registre o que aprender. Cada problema encontrado pós-go-live é uma lição para a próxima fase de migração ou a próxima troca de sistema.

Cobrimos o cenário mais amplo de pós-implantação no nosso guia de pós-implantação de ERP. A validação de dados é uma peça crítica desse panorama maior.

Perguntas Frequentes

Quanto tempo leva uma migração de dados para ERP?

Para empresas de médio porte, uma migração completa — da avaliação até a validação pós-go-live — leva tipicamente de 12 a 16 semanas. Migrações complexas envolvendo múltiplos sistemas de origem ou saneamento pesado podem se estender a 6 meses. A fase de saneamento sozinha costuma levar de 4 a 6 semanas, e comprimi-la é a fonte mais comum de problemas a jusante.

Qual a diferença entre migração big bang e migração faseada?

A migração big bang move todos os dados de uma vez em um único evento de cutover, tipicamente em um fim de semana. A migração faseada move dados em etapas, começando pelos datasets menos críticos. Big bang é mais rápida, mas mais arriscada — se algo der errado, tudo é afetado. A faseada leva mais tempo, mas permite validar cada etapa independentemente, reduzindo o raio de impacto dos erros.

Como decidir quais dados migrar e quais arquivar?

Se os dados sustentam um processo de negócio ativo — pedidos abertos, clientes ativos, produtos vigentes, registros financeiros recentes — eles migram. Dados históricos que ninguém consulta regularmente pertencem a um arquivo somente leitura. Requisitos regulatórios como SPED Fiscal podem ditar períodos de retenção, mas dados retidos não precisam viver no sistema de produção novo.

Quem deve ser o responsável pela migração de dados?

Um Líder de Migração dedicado deve coordenar o esforço, com TI cuidando da execução técnica, áreas de negócio decidindo sobre qualidade dos dados e o fornecedor trazendo expertise do sistema-alvo. O líder de migração orquestra os três grupos e é responsável pelo cronograma e resultado. A função exige mais autoridade cross-funcional do que profundidade técnica.

Como validar a precisão dos dados após a migração?

Valide em três níveis: contagem de registros (mesmos totais na origem e no destino), verificação pontual por campo (amostrar registros entre tipos de dados) e validação de lógica de negócio (totais calculados e relatórios produzem resultados esperados). Agende uma revisão pós-go-live de 30 dias para pegar problemas sutis que passam nas verificações automatizadas mas aparecem quando usuários reais rodam fluxos reais.

Como a Tier2 Aborda a Migração de Dados

A Tier2 tem mais de 11 anos implantando e migrando dados entre ERPs corporativos — Dynamics, SAP Business One, Totvs, Baan. Essa experiência em consultoria moldou como construímos nossas próprias plataformas.

Tanto o Tier2 Cargo quanto o Tier2 Keel foram projetados com a realidade da migração em mente. Esquemas de dados padronizados, documentação clara de mapeamento de campos e ferramentas de importação integradas fazem com que a fase de mapeamento descrita acima seja estruturada, não exploratória. Quando integramos uma empresa vindo de outro sistema, as fases de avaliação e saneamento recebem o tempo que precisam — porque aprendemos que apressá-las é como as migrações acabam nos 83%.

Se você está planejando uma troca de sistema e quer conversar sobre o escopo da sua migração, teremos prazer em fazer essa análise com você.

Antes de avaliar um fornecedor sequer ou assistir a mais uma demonstração, puxe um relatório do seu sistema atual e rastreie de onde os dados realmente vêm. Se a resposta envolver mais de um sistema e uma planilha, você encontrou o primeiro item do seu plano de migração.