Limpeza de Dados de Produto Antes da Migração

Exporte a lista completa de produtos e verifique primeiro duplicados exatos de SKU — costumam ser um erro de introdução de dados ou de importação e são simples de fundir depois de encontrados. Depois procure quase duplicados: o mesmo produto recriado sob um SKU diferente, muitas vezes resultado de uma reimportação de feed de fornecedor que não correspondeu aos registos existentes, ou um produto recriado manualmente em vez de editado depois de uma mudança de sistema.

Para cada par de duplicados, decida qual registo é o "real" — normalmente o que tem dados mais completos, mais histórico de encomendas ou melhores sinais de SEO, como ligações recebidas ou avaliações — e funda ou redirecione o outro para esse, em vez de migrar ambos e resolver a situação depois na plataforma nova.

Media órfão — imagens e ficheiros carregados para a sua biblioteca de media que já não são referenciados por nenhum produto, categoria ou página de conteúdo — acumula-se naturalmente ao longo de anos de atualizações de produtos, campanhas sazonais e mudanças de plataforma. Não acrescenta valor nenhum na plataforma nova e apenas aumenta o tempo de migração e o armazenamento, por isso vale a pena identificá-lo e excluí-lo.

Tenha também cuidado com o caso inverso: imagens que são referenciadas mas estão quebradas (um ficheiro em falta, um URL externo inativo) valem a pena apanhar agora, já que uma imagem quebrada numa página de produto é um pequeno mas real problema de confiança, muito mais fácil de corrigir nos seus dados atuais e familiares do que depois da mudança.

Anos de acréscimos ad hoc tendem a deixar categorias e atributos inconsistentes: o mesmo conceito escrito ou capitalizado de forma diferente entre produtos, categorias que se sobrepõem ou duplicam entre si, atributos usados para um propósito numa linha de produtos e para um propósito diferente noutra. Esta inconsistência normalmente não causa problemas visíveis na plataforma antiga, onde a equipa já aprendeu a contorná-la, mas torna-se um verdadeiro risco assim que é mapeada mecanicamente para o modelo de dados de uma plataforma nova.

Construa (ou confirme) uma taxonomia limpa e acordada antes da migração — uma árvore de categorias definida e uma lista de atributos definida, com nomenclatura consistente — e reconcilie os seus dados reais com ela. É também o momento de perguntar quais atributos ainda são relevantes para os clientes ou para as operações internas e quais existem apenas porque ninguém os removeu.

As estruturas de variantes (tamanho, cor, material, e como se combinam em SKUs específicos vendáveis) são tratadas de forma diferente entre plataformas, e dados de origem inconsistentes tornam isto pior. Procure produtos onde as opções de variante não seguem um padrão consistente — algumas variantes de tamanho chamadas "S/M/L" e outras "Pequeno/Médio/Grande" para a mesma linha de produtos, ou produtos onde existe uma combinação de variantes no seu sistema mas sem preço ou stock válido por trás.

Decida o seu modelo de variantes alvo antes da migração, não durante. Saber antecipadamente se a plataforma nova trata as combinações de variantes da mesma forma que a antiga — e onde não trata — determina se os seus dados de variantes existentes se conseguem mapear diretamente ou precisam de ser reestruturados primeiro.

Nem tudo no seu catálogo atual merece um lugar na plataforma nova. Produtos descontinuados sem stock remanescente, entradas de teste ou placeholder, e campos antigos cujo propósito original já ninguém consegue explicar são todos candidatos a ficar para trás — com uma decisão documentada, e não um abandono silencioso. Migrar menos, deliberadamente, costuma ser melhor do que migrar tudo e resolver a situação depois num sistema novo e pouco familiar.

Para tudo o que decidir não migrar mas que ainda tenha um URL indexado, certifique-se de que fica contemplado no seu plano de redirecionamentos (ver o guia de mapeamento de redirecionamentos) em vez de deixá-lo cair para 404 por acidente.