Mapeo de datos en una migración eCommerce: cómo mantener conectados los campos personalizados, las variantes y los SKU

El mapeo de datos en una migración eCommerce define dónde debe ir cada dato de origen en la nueva plataforma, cómo se conserva su significado y qué registros deben seguir conectados. Bien planteado, mantiene cada variante asociada al producto correcto, cada SKU vinculado al artículo vendible adecuado y cada pedido conectado con el cliente correspondiente.

Para quien gestiona una tienda, eso se traduce en tranquilidad práctica: el comprador puede elegir la talla que quiere, el almacén recibe el código de artículo correcto y atención al cliente puede entender un pedido antiguo. Un catálogo puede parecer completo aunque una de esas conexiones esté mal. Por eso conviene revisar el mapeo antes de la Full Migration.

¿Qué conecta realmente el mapeo de datos?

Cada plataforma tiene un schema: la estructura con la que organiza productos, clientes, pedidos y sus campos. Dos tiendas pueden mostrar una página de producto idéntica y, aun así, guardar la información de forma distinta por debajo. El mapeo conecta esas estructuras según el resultado que se quiere conseguir.

Tres términos ayudan a entender mejor el proceso:

Mapeo de campos: elegir dónde debe guardarse un valor en el destino, como una referencia de proveedor o el identificador fiscal de un cliente.

Mapeo de relaciones: conservar las conexiones entre registros, por ejemplo entre un producto y sus variantes o entre un cliente y sus pedidos.

Transformación de datos: cambiar un valor según una regla acordada, como convertir un peso de gramos a kilogramos.

Estas decisiones forman parte del mismo plan de migración, pero cumplen funciones distintas. Mover “500” a un campo de peso no lo convierte automáticamente en 0,5 kilogramos. Del mismo modo, copiar un ID de producto dentro de un pedido no crea una relación válida si el destino asigna IDs diferentes.

Sigue un producto durante toda la migración

Imagina una tienda de outdoor que vende una Trail Jacket en dos colores y tres tallas. La chaqueta azul marino, talla M, tiene el SKU TJ-NV-M, su propio stock y un código de barras. El producto también incluye un campo con instrucciones de cuidado, mientras que cada variante tiene un código de proveedor independiente.

La migración debe conservar qué información pertenece a la chaqueta completa y cuál corresponde solo a una combinación concreta. Si un código de proveedor específico de variante se mueve al producto padre, todas las tallas podrían terminar apuntando al mismo artículo del proveedor.

Este es un plan de mapeo ilustrativo. Las etiquetas describen el resultado esperado, no garantizan que estos campos estén disponibles en todas las rutas de migración.

En una migración de WooCommerce a Shopify, empieza por los datos compatibles de esa ruta concreta. WooCommerce documenta variaciones con sus propios ajustes de precio, stock e imagen; el modelo de variantes de Shopify también conecta una combinación vendible con la información del producto y del inventario. Aunque el comportamiento en tienda parezca similar, sigue siendo necesario revisar campos y relaciones con cuidado.

¿Cómo se mantienen conectados las variantes y los SKU?

Una variante representa una combinación vendible. Un SKU es un identificador de negocio asociado a un artículo. Un internal ID identifica un registro dentro de un sistema concreto. Tratar estos conceptos como si fueran intercambiables provoca errores de coincidencia evitables.

Mantén separados el producto padre y cada combinación vendible

En la Trail Jacket, “Navy / Medium” debe seguir vinculada al producto padre correcto, con el precio, stock, imagen y código de barras adecuados. Una buena validación sigue esa combinación seleccionada desde la tienda hasta el pedido. Contar seis variantes importadas no demuestra por sí solo que sus atributos sean correctos.

También conviene distinguir las variantes de los campos de personalización. Un texto para grabado o una nota de entrega puede describir una compra sin representar un artículo con stock independiente. Convertir cada opción en una variante puede cambiar la estructura del catálogo y crear combinaciones que la tienda nunca vendió.

Comprueba si tus SKU son claves de coincidencia fiables

Los SKU pueden ayudar a relacionar registros cuando están completos, son únicos dentro del alcance acordado y se mantienen estables. Son menos fiables cuando un producto padre y sus hijos comparten el mismo SKU, dos tiendas de origen reutilizan códigos o algunos productos antiguos no tienen valor.

• Detecta SKU ausentes o duplicados tanto a nivel de producto como de variante.
• Conserva el formato significativo, incluidos ceros iniciales, signos de puntuación y mayúsculas/minúsculas.
• Acordad cómo deben coincidir los registros de origen con artículos que ya existen en el destino.
• Documenta las excepciones en lugar de renombrar automáticamente códigos que utilizan los sistemas de inventario o fulfillment.

Cuando un SKU no es una clave segura, la migración necesita otro método de coincidencia compatible o una regla personalizada acordada. Una referencia cruzada entre IDs de origen y destino puede conservar la relación aunque la plataforma de destino genere nuevos internal IDs.

Importante: Conservar un SKU no vuelve a conectar automáticamente un ERP, un sistema de almacén o un feed de marketplace. Comprueba qué identificador usa cada integración y prueba la conexión por separado.

¿Dónde deben ir los campos personalizados?

Empieza por la finalidad del campo y después elige el destino. Una instrucción de cuidado es texto legible. Un código de proveedor es un identificador. Un número fiscal de cliente puede formar parte de un flujo de trabajo empresarial. Colocar los tres en un campo de descripción puede conservar los caracteres, pero dificultar el uso posterior de los datos.

Para cada campo personalizado, confirma cuatro aspectos:

• Propiedad: ¿pertenece a un producto, variante, cliente, pedido o línea de pedido?
• Tipo: ¿el destino debe guardarlo como texto, número, fecha, valor verdadero/falso o referencia?
• Significado: ¿se interpretan de forma coherente las unidades, los valores permitidos, los vacíos y el formato?
• Uso: ¿qué theme, app, filtro o integración necesita leerlo?

Por ejemplo, guarda un código de proveedor como 00127 como identificador, no como una cantidad. De lo contrario, una conversión numérica puede eliminar los ceros iniciales. Si un campo de origen contiene varios valores, confirma si el destino acepta una lista o necesita otra estructura compatible.

Un campo también puede migrarse correctamente sin aparecer en el storefront. El almacenamiento, la visualización, el filtrado y el comportamiento de las apps necesitan comprobaciones separadas. Nuestra guía sobre metadata, campos personalizados y extensiones explica estas diferencias, mientras que el artículo sobre cómo estructurar campos personalizados y flujos de cuentas muestra su importancia en tiendas mayoristas.

Antes de cerrar el diseño de un campo, comparte con Next-Cart un registro normal y un caso difícil. Mostrar el valor de origen junto al resultado que necesitas es mucho más útil que pedir simplemente “migrar todos los campos personalizados”.

Las categorías, los clientes y los pedidos también necesitan mapeo

Categorías: conserva la ubicación y la navegación previstas

Una chaqueta puede pertenecer tanto a Outerwear como a Winter Essentials. Decide cómo deben aparecer esas pertenencias y cualquier estructura padre-hijo de categorías en el destino. Comprueba tanto la ubicación del producto como la existencia de cada categoría. Si la plataforma de destino organiza las colecciones de otra forma, una regla explícita es más útil que hacer coincidir solo los nombres.

Clientes: protege la identidad y el contexto del negocio

El email, la dirección de facturación, el identificador fiscal y la clasificación de cuenta de un cliente cumplen funciones distintas. Acordad la política de coincidencia antes de combinar registros. Compartir una misma dirección de email entre varias tiendas no autoriza por sí solo a fusionar sus cuentas empresariales.

Para clientes mayoristas, una etiqueta de grupo o un campo fiscal migrado también debe validarse frente a la configuración de cuentas y precios del destino. Guardar el valor no recrea automáticamente el flujo de trabajo que lo utilizaba.

Pedidos: conserva el significado de la transacción original

Un pedido conecta al cliente con los artículos comprados, cantidades, precios, impuestos, descuentos y datos de envío. Sus valores históricos deben reflejar la transacción original, no recalcularse de forma silenciosa con el catálogo actual.

Planifica también los pedidos de invitados, productos eliminados y variantes descatalogadas. Cuando no sea posible recrear una relación con un producto activo, define cómo se conservarán los detalles históricos compatibles de la línea de pedido. Prueba el pedido como lo haría alguien de atención al cliente: ¿puedes saber qué se compró y entender el total?

¿Cómo validar el mapeo antes del go-live?

Utiliza Demo Migration para revisar registros representativos y repite después las comprobaciones relevantes tras Full Migration y cualquier ejecución adicional aprobada. Si la muestra de la demo no incluye un edge case crítico, organiza una validación adicional antes de considerar demostrado ese requisito.

Prepara un pequeño conjunto de pruebas que incluya deliberadamente casos difíciles:

• Un producto con varias variantes, imágenes distintas y campos personalizados específicos de cada variante.
• Un SKU ausente o duplicado y un identificador con ceros iniciales.
• Un producto asignado a varias categorías y un cliente con campos empresariales.
• Un pedido con descuento, un pedido de invitado y un pedido que incluya un artículo descatalogado.

Para cada ejemplo, registra el valor de origen, el resultado esperado en el destino, el resultado real y cualquier discrepancia. Compara tres capas: recuento de registros, valores de campos y relaciones. Explica diferencias de recuento causadas por filtrado, fusión o reestructuración aprobados; no des por hecho que tener los mismos totales demuestra que todo es correcto.

Termina con pruebas de comportamiento. Selecciona una variante, revisa la información mostrada, añádela al carrito y verifica el artículo resultante. Comprueba el historial de pedidos del cliente cuando corresponda y prueba las integraciones que consumen identificadores migrados. Estas comprobaciones conectan la precisión de la base de datos con el funcionamiento diario de la tienda.

Antes de aprobar: resuelve las discrepancias críticas, vuelve a probar los registros afectados y conserva las reglas de mapeo aprobadas con las notas del proyecto. Si las reglas cambian más adelante, revisa su efecto sobre los datos ya migrados antes de ejecutar de nuevo la migración.

¿Cuándo necesita el mapeo una Custom Migration?

Tener campos personalizados no significa automáticamente que todos los proyectos necesiten desarrollo a medida. La pregunta clave es si el resultado que necesitas encaja en el comportamiento compatible de la Migration Path seleccionada y los Add-ons aplicables.

Advanced Data Mapping de Next-Cart dirige los campos de origen compatibles a destinos compatibles. Data Transformation gestiona cambios de valores admitidos. Los campos y operaciones disponibles dependen de la migración activa, así que confirma el requisito exacto antes de elegir un Add-on.

Standard Migration es adecuada para trabajo compatible que quieres gestionar por tu cuenta. Managed Migration añade ejecución dirigida por Next-Cart dentro de su alcance compatible. Ninguna debe interpretarse como una promesa de reproducir cualquier comportamiento personalizado de una app o base de datos.

Custom Migration merece revisión cuando el proyecto necesita extracción no compatible, coincidencias a medida, relaciones poco habituales o lógica personalizada. Algunos ejemplos son fusionar varios catálogos de origen con reglas propias del negocio o mover datos gestionados por una app a una estructura de destino diferente.

Prepara registros de muestra, el resultado esperado en el destino, las reglas de coincidencia y transformación, los sistemas relacionados y comprobaciones de aceptación claras. Así el equipo tendrá una base concreta para evaluar viabilidad y definir el trabajo.

Dale a tu nueva tienda una base de datos clara

Un buen mapeo conserva el significado de tu catálogo y del historial de clientes durante el cambio de plataforma. Cuando se revisan juntos la estructura de productos, los identificadores, los campos personalizados y las relaciones de transacciones, el equipo dispone de una forma más clara de detectar problemas y aprobar el resultado.

¿Listo para revisar los datos de tu tienda? Solicita una Demo con Next-Cart y trae registros representativos para revisarlos. Para entender mejor los sistemas que hay detrás de una migración, explora nuestros artículos de Tecnología eCommerce.