Migração de dados para ERP: o que limpar e o que arquivar

Peça para ver o plano de uma implementação de ERP e a migração de dados aparecerá como uma fase — normalmente algumas semanas, encaixada entre a configuração e os testes, dimensionada como se mover dados fosse um exercício mecânico de exportar e importar. Não é. A migração é o momento em que cada pressuposto assumido durante a conceção se encontra com o histórico real e não tratado de como o negócio funcionou de facto, e é, com uma frequência desproporcionada, a razão pela qual as implementações derrapam, por motivos já discutidos no artigo desta série sobre padrões de falha em implementações de NetSuite.

O plano trata a migração como uma tarefa técnica: extrair, transformar, carregar. A realidade é que a migração é um exercício de tomada de decisão disfarçado de tarefa técnica — o que transportar, o que limpar primeiro, o que arquivar em vez de migrar e o que deixar para trás por completo — e cada uma dessas decisões tem consequências para o custo, o calendário e o grau em que o novo sistema é realmente utilizável no primeiro dia.

Por que é que isto importa

Subestimar a migração tem uma assinatura de falha específica e repetível. O perfilamento é omitido ou feito a correr, o verdadeiro estado dos dados é descoberto durante a própria fase de migração em vez de antes dela, e essa descoberta força uma renegociação de âmbito e calendário no ponto do projeto com menos folga disponível — porque o go-live já foi normalmente comunicado ao negócio e não pode ser deslocado com facilidade.

O custo de errar aqui também se acumula depois do go-live. Os dados migrados sem uma limpeza adequada transportam os seus problemas para o novo sistema, exceto que agora são mais difíceis de corrigir, porque estão embebidos num sistema de que todos passaram a depender e estão misturados com transações genuinamente novas. Um registo de cliente duplicado que existia há anos no sistema antigo é um incómodo; o mesmo duplicado, recém-migrado para um sistema em que todos confiam agora como fonte de verdade, induz ativamente decisões erradas.

Há ainda uma questão de âmbito que a migração força como nada mais no projeto força de forma tão direta: não é tudo o que existe no seu sistema atual que merece existir no novo. Clientes antigos inativos, artigos descontinuados, transações históricas além do que é legalmente exigido — migrar tudo por omissão, porque ninguém decidiu explicitamente o contrário, inflaciona o custo, degrada o desempenho e polui o novo sistema com irrelevâncias desde o primeiro dia.

Num relance: as categorias de decisão da migração

As categorias que mais frequentemente colapsam em "migrar tudo" por omissão são a segunda e a terceira. O histórico transacional completo é caro de migrar e raramente é necessário com esse grau de granularidade — um saldo de abertura, corretamente apurado, serve normalmente melhor o negócio do que anos de histórico granular que ninguém irá consultar, e os requisitos legais de conservação são normalmente satisfeitos por um arquivo acessível em vez de por presença viva no novo ERP.

O que funciona e sobre o que ser honesto

O que funciona:

Perfilar antes de dimensionar, não durante a migração. Estabeleça contagens de registos, taxas de duplicados, grau de preenchimento dos campos obrigatórios e integridade referencial no primeiro mês do projeto, não na fase de migração. É o passo com maior alavancagem de toda a migração e é o que mais frequentemente é omitido sob pressão de tempo, exatamente porque parece que pode esperar.

Decidir a conservação por categoria, deliberadamente, com o contributo das finanças e da área jurídica. Os requisitos legais de conservação na Ibéria diferem por tipo de documento e de registo, e "quanto tempo precisamos de guardar isto" é uma questão de conformidade, não uma questão de IT. Obtenha a resposta para cada categoria antes de decidir o que migrar e o que arquivar.

Limpar antes de migrar, nunca depois. Um duplicado conhecido ou um registo malformado deve ser corrigido antes de se mover, não migrado com a intenção de o limpar depois da entrada em produção. Uma vez em produção, fica misturado com atividade nova genuína e é consideravelmente mais difícil de isolar e corrigir.

Migrar saldos de abertura em vez do histórico completo de transações sempre que o negócio não precise de consulta ao nível da transação. Esta opção é sistematicamente subutilizada porque dá a sensação de se perder algo, mas na maioria das empresas mid-market o detalhe histórico das transações é raramente consultado depois dos primeiros meses, e um saldo de abertura corretamente apurado preserva tudo aquilo de que o negócio realmente precisa.

Um passo definido e testado de rollback e reconciliação. Toda a migração precisa de uma forma de provar que os dados do novo sistema correspondem aos do antigo, categoria por categoria, antes de o sistema antigo ser desativado. Omitir isto é a via pela qual as empresas descobrem um erro de migração meses mais tarde, quando a comparação já não é simples.

Sobre o que ser honesto:

O perfilamento vai encontrar coisas que ninguém quer ouvir. As taxas de duplicados e os problemas de qualidade dos dados descobertos durante o perfilamento são frequentemente mais elevados do que qualquer pessoa espera, e a tentação é tratar o achado como um exagero em vez de como um facto. Orce com honestidade o tempo que essa correção vai levar, porque descobrir o âmbito verdadeiro tarde é pior do que descobri-lo cedo e não gostar do número.

"Podemos vir a precisar" não é um critério de migração. Quase tudo poderia concebivelmente ser necessário algum dia. A disciplina consiste em perguntar o que seria concretamente necessário, por quem, em que circunstância, e se um arquivo em vez de uma migração viva satisfaz essa necessidade. A maioria dos casos passa este teste como "arquivar", não como "migrar".

A limpeza leva mais tempo do que o plano permite, quase sempre. Não é uma crítica a nenhuma equipa em particular — é uma característica estrutural do trabalho, porque a limpeza traz à superfície juízos de valor (isto é um duplicado, ou são duas entidades genuinamente diferentes com o mesmo nome?) que não podem ser totalmente automatizados e que se multiplicam com o volume de dados.

O histórico migrado tem de reconciliar de facto, e a reconciliação é em si mesma uma tarefa significativa. Comparar saldos, contagens e amostras entre o sistema antigo e o novo, categoria por categoria, é trabalho real que tem de ser planeado e dotado de recursos, não algo que se assuma acontecer automaticamente como efeito secundário de os scripts de migração terem corrido com sucesso.

O negócio vai pedir coisas de volta depois do go-live. Alguns dados arquivados ou excluídos vão acabar por ser desejados, normalmente por causa de um litígio concreto com um cliente ou de um pedido de auditoria invulgar. Isto é gerível se o arquivo for genuinamente acessível, e é uma crise se "arquivado" acabar por significar "eliminado".

Quadro de decisão: dimensionar e executar a migração

Percorra por ordem. Pare na primeira correspondência.

1. Os dados foram perfilados — contagens de registos, taxas de duplicados, preenchimento, integridade referencial — independentemente do calendário de migração?
Se não, faça-o agora, no primeiro mês do projeto, independentemente da fase em que o plano coloca a migração. Este achado reavalia tudo o que vem depois e é muito mais barato tê-lo cedo.

2. Cada categoria de dados foi explicitamente atribuída a migrar, resumir, arquivar ou descartar — com o contributo das finanças e da área jurídica sobre conservação?
Se não, faça-o antes de começar qualquer trabalho técnico de migração. Optar por omissão por "migrar tudo" é uma decisão por omissão, e é normalmente a errada.

3. Os problemas conhecidos de qualidade dos dados estão a ser limpos antes da migração, ou adiados para um "corrigimos depois"?
Se forem adiados, pare e reconsidere. Migrar dados que se sabe estarem defeituosos com a intenção de os corrigir depois falha de forma fiável, porque a correção torna-se mais difícil depois de misturada com atividade viva e menos urgente depois de passada a pressão imediata do go-live.

4. Existe um processo de reconciliação definido que compare os dados do sistema antigo e do novo antes de o sistema antigo ser desativado?
Se não, construa um agora. Não é um seguro opcional — é o único mecanismo que deteta erros de migração enquanto ainda são baratos de corrigir.

5. As decisões de conservação foram documentadas com um responsável nomeado e prestação de contas, em particular para tudo o que não vai ser migrado?
Se não, documente-o antes do go-live. "Decidimos não migrar X" tem de ser rastreável até uma decisão e uma razão, não reconstruído meses mais tarde quando alguém perguntar para onde foi algo.

6. Tudo o anterior concluído — o calendário de migração continua realista?
Reveja a estimativa com honestidade à luz do que o perfilamento encontrou. Um calendário de migração fixado antes do perfilamento era um palpite; um fixado depois é uma estimativa, e raramente são o mesmo número.

7. Migrado e em produção — a reconciliação foi efetivamente concluída e aprovada formalmente?
Não desative o sistema antigo até isto estar feito e documentado. O sistema antigo é o seu único ponto de referência para detetar um erro de migração e, uma vez desaparecido, esse ponto de referência desaparece com ele.

Custo e esforço indicativos

O esforço de migração escala muito mais com a qualidade dos dados do que com o volume de dados — um conjunto de dados menor e mais desarrumado pode facilmente custar mais a migrar bem do que um maior e mais limpo. Peça um orçamento para um perfilamento e uma estimativa com âmbito definido.

Perguntas frequentes

Quantos dados históricos precisamos realmente de migrar?
Menos do que a maioria das empresas assume. Os requisitos legais de conservação estabelecem um mínimo, mas esse mínimo é normalmente satisfeito por um arquivo acessível em vez de por presença viva no novo ERP, e a maioria das consultas operacionais não recua mais de um ou dois anos. Estabeleça a necessidade operacional genuína separadamente da necessidade legal de conservação — normalmente apontam para respostas diferentes.

Qual é a maior causa isolada de derrapagem numa migração?
Omitir o perfilamento ou fazê-lo a correr. Quase todas as derrapagens de migração que herdámos de outro partner remontam ao facto de a qualidade dos dados ter sido descoberta durante a fase de migração em vez de antes dela, ponto a partir do qual se torna uma renegociação de calendário e orçamento em vez de um dado de entrada do planeamento.

Devemos limpar o sistema antigo, ou limpar durante a migração?
Limpe antes, sempre que possível. Limpar no sistema antigo é normalmente mais fácil, porque a equipa compreende as particularidades e o histórico desse sistema, e significa que o novo sistema arranca genuinamente limpo em vez de herdar uma promessa de limpar mais tarde que compete com todas as outras prioridades posteriores ao go-live.

Durante quanto tempo devemos manter o sistema antigo acessível depois do go-live?
O suficiente para concluir a reconciliação com confiança e para lidar com a primeira vaga de pedidos do tipo "precisamos de algo que não migrámos" — pela nossa experiência, um mínimo de vários meses, e mais para os dados financeiros dados os ciclos legais de auditoria e de reporte. Desativar demasiado cedo para poupar no custo de licenças é uma falsa economia comum e lamentável.

Isto aplica-se da mesma forma a uma migração de CRM ou de plataforma de ecommerce, e não apenas de ERP?
Os princípios são idênticos — perfilar primeiro, decidir categorias deliberadamente, limpar antes de mover, reconciliar antes de desativar — embora os tipos de dados concretos e as regras de conservação difiram. A disciplina transfere-se independentemente de qual seja o sistema que está a ser migrado.

Fecho — Próximos passos

A migração de dados falha como linha de um plano porque não é na verdade uma tarefa técnica com uma duração previsível — é uma série de juízos de valor sobre aquilo em que o histórico do seu negócio precisa realmente de se tornar, tomados sob a pressão específica de uma data de go-live que se aproxima. Tratá-la como uma fase de execução em vez de como um projeto de tomada de decisão é a razão mais comum para derrapar.

O corretivo está disponível em praticamente qualquer fase: perfile os dados com honestidade, por incómodo que seja o achado, e tome a decisão de migrar, arquivar ou descartar deliberadamente para cada categoria em vez de por omissão. Os projetos que fazem isto no primeiro mês em vez do quarto são os que não renegoceiam o seu calendário no pior momento possível.

Sobre o autor

Bruno Galo é o fundador da Atypical Tech, uma consultora de NetSuite que serve clientes mid-market em toda a Ibéria. Especializa-se em ligar sistemas CRM e ERP para fluxos order-to-cash sem atritos, construindo pipelines automatizados de gestão de encomendas que eliminam a introdução manual de dados entre as equipas comerciais e financeiras. Como partner oficial de implementação da Stacksync, Bruno concebe e implementa agentes de IA em plataformas de integração para tratar do encaminhamento de exceções, do processamento de documentos e da reconciliação — transformando fluxos de encomendas fragmentados em sistemas fiáveis e com automonitorização.

LinkedIn: https://www.linkedin.com/in/brunogd

Fontes

Os URL são ao nível do editor e devem ser verificados antes da publicação.

• Oracle NetSuite, documentação de migração de dados e importação CSV — https://docs.oracle.com/en/cloud/saas/netsuite/
• Agencia Tributaria (Espanha), requisitos de conservação de registos — https://sede.agenciatributaria.gob.es
• Autoridade Tributária e Aduaneira (Portugal), requisitos de conservação de registos — https://info.portaldasfinancas.gov.pt
• DAMA International, Data Management Body of Knowledge (DMBOK) — dimensões de qualidade dos dados — https://www.dama.org
• Experiência da Atypical Tech em projetos de migração de ERP mid-market na Ibéria