Encuentra y resuelve SKU duplicados y productos casi duplicados
Exporta tu lista completa de productos y busca primero duplicados exactos de SKU — suelen ser un error de entrada de datos o de importación y son sencillos de fusionar una vez localizados. Después busca casi duplicados: el mismo producto recreado bajo un SKU distinto, a menudo resultado de una reimportación de un feed de proveedor que no coincidió con los registros existentes, o un producto que se recreó manualmente en lugar de editarse tras un cambio de sistema.
Para cada pareja de duplicados, decide qué registro es el "real" — normalmente el que tiene datos más completos, más historial de pedidos o mejores señales de SEO, como enlaces entrantes o reseñas — y fusiona o redirige el otro hacia él, en lugar de migrar ambos y resolverlo más tarde en la nueva plataforma.
Localiza imágenes y contenido multimedia huérfano
El contenido multimedia huérfano — imágenes y archivos subidos a tu biblioteca de medios que ya no referencia ningún producto, categoría o página de contenido — se acumula de forma natural a lo largo de años de actualizaciones de producto, campañas estacionales y cambios de plataforma. No aportan ningún valor en la nueva plataforma y solo aumentan el tiempo de migración y el almacenamiento, así que merece la pena identificarlos y excluirlos.
Ten cuidado también con el caso contrario: las imágenes que están referenciadas pero rotas (un archivo que falta, una URL externa muerta) merece la pena detectarlas ahora, ya que una imagen rota en una página de producto es un problema de confianza pequeño pero real, mucho más fácil de arreglar sobre tus datos actuales y conocidos que después del traslado.
Estandariza categorías y atributos
Años de añadidos improvisados suelen dejar categorías y atributos inconsistentes: el mismo concepto escrito o capitalizado de forma distinta según el producto, categorías que se solapan o se duplican entre sí, atributos usados para un propósito en una línea de producto y para otro distinto en otra. Esta inconsistencia normalmente no causa problemas visibles en la plataforma antigua, donde el equipo ha aprendido a convivir con ella, pero se convierte en un problema real en cuanto se mapea de forma mecánica al modelo de datos de una nueva plataforma.
Construye (o confirma) una taxonomía limpia y consensuada antes de la migración — un árbol de categorías definido y una lista de atributos definida con nomenclatura consistente — y concilia tus datos reales con ella. Este es también el momento de preguntarse qué atributos siguen siendo relevantes para los clientes o la operativa interna y cuáles existen solo porque nadie los ha eliminado.
Concilia los desajustes en la estructura de variantes
Las estructuras de variantes (talla, color, material y cómo se combinan en SKU concretos y vendibles) se gestionan de forma distinta en cada plataforma, y unos datos de origen inconsistentes empeoran esto. Busca productos donde las opciones de variante no sigan un patrón consistente — algunas variantes de talla llamadas "S/M/L" y otras "Small/Medium/Large" para la misma línea de producto, o productos donde existe una combinación de variante en tu sistema pero sin un precio o stock válido detrás.
Decide tu modelo de variantes objetivo antes de la migración, no durante ella. Saber de antemano si la nueva plataforma gestiona las combinaciones de variantes igual que la antigua — y dónde no lo hace — determina si tus datos de variantes actuales pueden mapearse directamente o necesitan reestructurarse antes.
Decide qué necesita trasladarse realmente
No todo lo que hay en tu catálogo actual merece un lugar en la nueva plataforma. Los productos descatalogados sin stock restante, las entradas de prueba o marcador de posición, y los campos heredados cuyo propósito original nadie recuerda son candidatos a quedarse atrás — con una decisión documentada, no con una omisión silenciosa. Migrar menos, de forma deliberada, suele ser mejor que migrarlo todo y resolverlo después en un sistema nuevo y poco familiar.
Para cualquier elemento que decidas no migrar pero que todavía tenga una URL indexada, asegúrate de que quede contemplado en tu plan de redirecciones (ver la guía de mapeo de redirecciones) en lugar de dejarlo dar un 404 por accidente.
Preguntas frecuentes
¿Cuánto tiempo hay que presupuestar para la limpieza de datos antes de una migración?
Depende en gran medida del tamaño del catálogo y de lo desordenados que estén realmente los datos — un catálogo pequeño y bien mantenido necesita mucho menos tiempo que uno con decenas de miles de SKU y años de importaciones de feeds de proveedores. Auditar los datos primero es lo que revela el alcance real; saltarse la auditoría y adivinar es lo que hace que el tiempo de limpieza se subestime.
¿Debemos limpiar los datos antes o durante el proyecto de migración?
Antes, o como mínimo como una fase inicial explícita con su propia revisión — no mezclada con el traslado técnico de datos. Las decisiones de limpieza (qué es un duplicado, qué se puede eliminar con seguridad, para qué servía un campo personalizado misterioso) suelen necesitar la aportación de alguien que conozca el historial del catálogo, y eso es un tipo de trabajo distinto del mapeo y el traslado técnico en sí.
¿Y si no estamos seguros de si un duplicado lo es realmente?
Márcalo en lugar de adivinar en un sentido u otro. Un casi duplicado con precios distintos, opciones de variante distintas o un historial de pedidos distinto podría ser un producto independiente legítimo que simplemente se parece a otro. En caso de duda, conserva ambos y revísalo cuando termine la auditoría, en lugar de fusionar por suposición.
¿Se puede hacer la limpieza de datos mientras la tienda antigua sigue activa y recibiendo pedidos?
Sí, para la mayor parte del trabajo de auditoría y planificación — revisar exportaciones, decidir fusiones y construir la taxonomía objetivo no requiere tocar la tienda en producción. La aplicación real de los cambios (fusionar registros, eliminar contenido multimedia huérfano) suele ser más segura sobre una copia o exportación, para después incorporar el conjunto de datos ya limpio a la migración, en lugar de editar el catálogo en producción en mitad de la auditoría.