Migrar a Shopify implica traducir la información y las relaciones de la plataforma de origen a un modelo de comercio electrónico alojado con funciones explícitas para Products, variantes, colecciones, menús, Customers, Orders, contenido, metafields, metaobjects, aplicaciones e integraciones. Las estructuras de origen rara vez coinciden uno a uno. Una Category de origen puede convertirse en una colección, una entrada de menú, una página, un filtro, una redirección o una clasificación interna; un campo personalizado puede convertirse en un campo nativo, un metafield, una referencia a un metaobject, un valor administrado por una aplicación o una exclusión deliberada.
La plataforma de destino debe preservar el significado empresarial necesario después del lanzamiento, no la estructura accidental creada durante años de soluciones heredadas. Para ello hay que mapear relaciones: Product con variante, colección con ruta de descubrimiento, Customer con Order, contenido con destino URL e identificador externo con el sistema que seguirá utilizándolo.
Por qué importan las diferencias del modelo de datos
Shopify es una plataforma SaaS alojada con estructuras definidas por la propia plataforma para catálogo, experiencia de tienda, Customers, Orders, contenido y configuración. Ese modelo puede facilitar la operación de la tienda de destino, pero también significa que la plataforma de origen no debe copiarse mecánicamente.
Una plataforma de origen puede usar Categories, atributos de base de datos, extensiones, módulos, campos personalizados, tipos de producto específicos, lógica multitienda o datos propios del tema para sostener funciones de negocio. Shopify puede representar el mismo propósito mediante Products, opciones, variantes, colecciones, product category, tipo de producto, tags, metafields, metaobjects, aplicaciones, temas, Markets, redirecciones URL o configuración independiente de la tienda de destino.
El objetivo no es conseguir igualdad estructural, sino una tienda de destino utilizable. Un buen modelo de datos de Shopify conserva el significado comercial y operativo que realmente importa: los clientes pueden elegir Products correctamente, navegar por los grupos adecuados, leer el contenido correcto, acceder a contexto útil de cuentas y Orders, seguir URL importantes y utilizar funciones respaldadas por aplicaciones cuando formen parte de las expectativas de lanzamiento.
| Significado en la plataforma de origen | Posible destino en Shopify | Pregunta de planificación |
|---|---|---|
| Diferencia entre Products vendibles | Opción de Product, variante, SKU, precio, inventario, contenido multimedia o función soportada por una aplicación | ¿La diferencia representa una elección real de compra o solo información descriptiva? |
| Category o departamento | Colección, menú, filtro, product category, tipo de producto, tag, página o redirección | ¿La estructura ayuda al cliente a descubrir Products o solo conserva organización heredada? |
| Campo personalizado | Campo nativo, metafield, metaobject, campo de una aplicación, referencia de integración o exclusión deliberada | ¿Quién utilizará el valor después del lanzamiento y dónde debe mostrarse o procesarse? |
| Datos de extensión, módulo o aplicación | Configuración de aplicación de Shopify, metafields, planificación de integración, configuración manual o trabajo independiente de aplicación | ¿El dato sigue siendo útil sin el comportamiento que lo utilizaba en origen? |
| Estructura internacional o multitienda | Markets, dominios, idiomas, monedas, catálogos, redirecciones o planificación de tiendas separadas | ¿Qué diferencias regionales deben seguir visibles y utilizables después del lanzamiento? |
| URL sensible para SEO | Handle, ruta, redirección, ruta de colección, página, Blog Post o decisión de limpieza | ¿Qué rutas de origen merecen prioridad en la revisión de redirecciones y destinos? |
Diferencias en la estructura de catálogo y Product
La planificación del catálogo de Shopify parte de la relación entre Products, opciones, variantes, product category, tipo de producto, tags, metafields, contenido multimedia e inventario. Las tiendas de origen suelen usar estructuras más variadas, especialmente cuando proceden de plataformas autoalojadas, con muchas extensiones o con catálogos personalizados.
Un Product debe representar el artículo que se vende. Las opciones deben representar dimensiones de elección visibles para el cliente, como talla, color, material, tamaño de paquete, acabado o configuración. Las variantes deben representar las combinaciones comprables generadas a partir de esas opciones. Esta lógica es sencilla cuando el catálogo de origen ya separa las verdaderas decisiones de compra de los detalles descriptivos. Requiere más cuidado cuando la plataforma de origen usa Products configurables o agrupados, opciones personalizadas, bundles, kits, campos de personalización, extras opcionales o lógica de extensiones.
Las diferencias entre Products deberían clasificarse por su función comercial:
- elecciones reales de compra visibles para el cliente;
- diferencias de SKU, inventario, precio, código de barras, procesamiento de pedidos o impuestos;
- especificaciones o información de compatibilidad;
- imágenes específicas de una variante u orden del contenido multimedia;
- entradas de personalización o comportamiento de opciones personalizadas;
- lógica de bundles, kits, suscripciones o complementos;
- identificadores operativos utilizados por ERP, canales de venta externos, sistemas de procesamiento de pedidos, analítica o informes;
- campos obsoletos o residuos de extensiones que no deberían trasladarse a Shopify.
No todas las opciones de origen deberían convertirse en variantes de Shopify. Algunos valores pueden representarse mejor como contenido de Product, metafields, metaobjects, tags, configuración de aplicaciones, visualización en el tema, datos de integración o un camino definido de aplicación o diseño de datos. La prueba práctica es si la estructura elegida en Shopify conserva claridad para la compra y utilidad operativa.
También deben distinguirse product category y tipo de producto. Product category alinea el Product con la taxonomía estándar de Shopify y puede influir en atributos, canales de venta, impuestos, descubrimiento y organización. Product type es un campo organizativo personalizado. Tags y metafields pueden ampliar la organización, el filtrado o la visualización, pero no deberían convertirse en un depósito indiscriminado de atributos de origen.
Diferencias entre Category, colección, navegación y estructura de tienda
Las Categories de origen suelen concentrar varios significados a la vez. Pueden definir jerarquía, navegación, páginas de destino, filtros de Product, agrupaciones de merchandising, rutas SEO, clasificación interna, campañas o hábitos de navegación del cliente. Las colecciones de Shopify pueden preservar parte de ese significado, pero no siempre sustituyen a las Categories una a una.
Una Category de origen puede convertirse en:
| Función de la Category de origen | Tratamiento que debe considerarse en Shopify |
|---|---|
| Grupo de Products visible para el cliente | Colección, elemento de menú, grupo de filtros o página de destino |
| Landing page SEO | Colección con contenido, página, destino de redirección o decisión de limpieza |
| Clasificación interna | Product type, tag, metafield o ninguna estructura visible migrada |
| Contexto de filtro o navegación por capas | Configuración de búsqueda y descubrimiento, tags, metafields, atributos de product category o filtrado soportado por una aplicación |
| Agrupación de campaña o temporada | Colección manual o automatizada, página, ubicación en menú o redirección archivada |
| Taxonomía heredada profunda | Modelo de colecciones simplificado más redirecciones para rutas prioritarias |
El plan de colecciones debe evaluarse por cómo permite descubrir Products, no por conservar el mismo número de Categories. El cliente debería seguir encontrando los Products previstos mediante colecciones, menús, búsqueda, filtros, recomendaciones y páginas de destino prioritarias. Una estructura de colecciones más pequeña puede ser mejor que una jerarquía heredada copiada si ofrece navegación más clara y merchandising más limpio.
El tema también influye. El diseño de las colecciones, las tarjetas de Product, la profundidad del menú, los filtros, badges, recomendaciones y visualizaciones personalizadas pueden depender del tema seleccionado y de la configuración de aplicaciones. Migrar datos de Category o colección no recrea automáticamente toda la experiencia de navegación de la tienda.
Diferencias en Customers, cuentas y Orders
La migración de Customers y Orders debe evaluarse por su utilidad posterior. Un registro Customer puede existir en Shopify mientras la experiencia de cuenta, las expectativas sobre contraseñas, el contexto de fidelización, la lógica de grupos, los guiones de soporte o la experiencia B2B difieren de la plataforma de origen.
Conviene separar los datos de Customer según su función:
- datos de perfil y contacto;
- direcciones de facturación y envío;
- tags, notas y señales de segmentación;
- estado de marketing y expectativas de comunicación;
- relación con el historial de Orders;
- fidelización, recompensas, membresías, condición mayorista o niveles de cuenta;
- identificadores específicos del Customer utilizados por sistemas externos;
- expectativas de contraseña, inicio de sesión o activación.
Los registros Customer y las cuentas de cliente no son el mismo ámbito de planificación. La migración puede conservar contexto útil, pero el acceso de clientes recurrentes puede requerir comunicación, activación de cuenta, configuración de la tienda de destino, revisión de aplicaciones o planificación de procesos de soporte.
Los Orders también deben tratarse como contexto operativo, no solo como registros históricos. Una migración de Orders útil suele depender de líneas de pedido, asociación con Customer, totales, impuestos, envío, descuentos, estado de pago, estado de procesamiento, notas, referencias de origen y contexto para atención al cliente. Parte del comportamiento asociado al Order puede pertenecer a sistemas de pago, herramientas de procesamiento de pedidos, facturación, suscripciones, extensiones de fidelización, herramientas antifraude o sistemas externos. Ese comportamiento debe separarse de los registros históricos.
El objetivo práctico es un historial de Orders en Shopify que sirva para atención al cliente, referencia operativa, revisión de informes y confianza del cliente cuando el historial sea visible. No debe asumirse que el comportamiento exacto del sistema de origen continuará si no existe un destino claro en Shopify.
Diferencias en contenido, URL y datos SEO
La migración de contenido a Shopify puede abarcar CMS Pages, Blog Posts, descripciones de Product y colecciones, contenido multimedia, enlaces internos, metadatos, handles, menús y redirecciones. El significado de ese contenido va más allá de transferir texto. Puede sostener confianza, cumplimiento de políticas, información de envíos y devoluciones, guías de talla, SEO, campañas, ayuda de compra, formación del cliente o credibilidad de marca.
El contenido debe revisarse por su propósito:
| Área de contenido o URL | Implicación para el modelo de datos de Shopify |
|---|---|
| CMS Pages | Pueden requerir migración de página, ubicación en navegación, revisión de enlaces internos, revisión multimedia y decisiones de metadatos. |
| Blog Posts | Pueden requerir estructura de blog, rutas de artículos, contenido multimedia, metadatos, expectativas de autor/fecha y revisión de enlaces internos. |
| Descripciones de Product y colección | Deben respaldar la lógica comercial y la visualización del tema de destino, no limitarse a conservar texto antiguo. |
| URL de Categories de origen | Pueden necesitar destinos de colección o página, redirecciones o decisiones de limpieza. |
| URL de Product | Requieren revisión de handles y planificación de redirecciones para rutas prioritarias. |
| URL filtradas, de búsqueda o con parámetros | Requieren revisión especial porque pueden no comportarse como rutas ordinarias de Product, colección, página o Blog Post. |
| URL internacionales o localizadas | Requieren planificación de Market, idioma, dominio, subcarpeta y redirección cuando la venta regional sea relevante. |
La estructura URL de Shopify está controlada por su modelo de tienda. Las rutas exactas de origen pueden no conservarse, especialmente para Products, colecciones, CMS Pages, Blog Posts, rutas filtradas y rutas personalizadas. Por ello, las redirecciones forman parte de la traducción del modelo de datos y no solo de una tarea SEO final.
Las URL prioritarias contienen una identidad de ruta que el destino debe preservar de forma deliberada. Suelen incluir rutas con tráfico orgánico, valor de campañas de pago, backlinks, marcadores de clientes, Products de alta facturación, Categories importantes, páginas de políticas, Blog Posts y páginas de destino regionales. Cada ruta prioritaria necesita un destino explícito en Shopify y una relación de redirección definida.
Diferencias en aplicaciones, extensiones, integraciones y datos personalizados
Las tiendas Shopify suelen depender de aplicaciones, temas e integraciones. Es normal, pero el comportamiento respaldado por una aplicación no debe confundirse con datos migrados ordinarios. Una extensión de la plataforma de origen puede almacenar datos que solo tienen sentido si una aplicación, tema o integración de Shopify puede utilizarlos.
Entre los ámbitos más sensibles a aplicaciones e integraciones se encuentran:
- reseñas y valoraciones de Products;
- suscripciones, bundles, kits, extras opcionales o lógica de personalización;
- fidelización, recompensas, membresías y niveles de Customer;
- búsqueda avanzada, filtrado, recomendaciones o reglas de merchandising;
- venta mayorista, B2B, precios específicos por Customer o contenido restringido;
- identificadores de ERP, procesamiento de pedidos, canales de venta externos, PIM, CRM, analítica, contabilidad o soporte;
- reglas de entrega, lógica de envío, supuestos fiscales, facturas y contexto relacionado con pagos;
- visualizaciones personalizadas controladas por código del tema o bloques de aplicaciones.
Para cada dependencia, el plan de migración debe identificar el resultado empresarial, los datos de origen implicados, el destino en Shopify y el comportamiento necesario después del lanzamiento. Algunos datos pueden migrarse a metafields o metaobjects. Otros pueden necesitar importación mediante una aplicación, configuración manual, relación explícita entre campos, configuración en destino, trabajo de integración o reestructuración de datos. Algunos no merecen ser trasladados.
Los metafields y metaobjects son útiles cuando la información personalizada tiene un propósito en destino. Los metafields pueden ampliar recursos de Shopify como Products, Customers y Orders. Los metaobjects pueden modelar contenido estructurado con varios campos y entradas reutilizables. Ninguno recrea automáticamente la lógica de negocio de origen. Un valor puede estar presente en Shopify y seguir siendo invisible, no utilizado o irrelevante operativamente hasta que un tema, aplicación, flujo o integración lo consuma.
Cómo afectan las diferencias del modelo de datos al alcance de la migración
Las decisiones sobre el modelo de datos de Shopify deben hacer más preciso el alcance de la migración. El objetivo no es reproducir cada campo de origen, sino identificar los significados que deben seguir siendo útiles en Shopify y asignarlos al propietario correcto en destino.
Un alcance práctico separa cuatro resultados:
| Resultado de representación | Significado en Shopify |
|---|---|
| Registro nativo de Shopify | El significado de origen encaja en un Product, variante, Customer, Order, registro relacionado con colecciones, CMS Page, Blog Post, redirección u otro destino nativo compatible. |
| Configuración de Shopify o responsabilidad de la tienda | El registro puede existir, pero su utilidad depende de colecciones, menús, Search & Discovery, secciones de tema, Markets, cuentas de cliente u otra configuración de la tienda de destino. |
| Datos personalizados estructurados | El significado pertenece a un metafield, category metafield, metaobject, campo de una aplicación o referencia de integración con un consumidor definido. |
| Excluir, archivar o rediseñar | El valor es obsoleto, duplicado, dependiente de lógica de extensión retirada o carece de propósito operativo o de tienda después del lanzamiento. |
Esta separación evita una falsa sensación de completitud. Una colección puede existir sin conservar la antigua ruta de descubrimiento. Un metafield puede contener el valor correcto mientras ningún tema, aplicación o integración lo utiliza. Un Customer puede existir sin reproducir el modelo de inicio de sesión de origen. Un Order puede preservar datos históricos sin recrear pagos, procesamiento de pedidos o suscripciones activos.
El principal artefacto de planificación debería ser un mapa de traducción de datos. Para cada significado importante del origen, debe nombrar el destino en Shopify, la relación que debe conservarse, el sistema o equipo que lo utilizará y cualquier configuración necesaria en la tienda de destino para que resulte útil. Ese mapa proporciona una base estable para decisiones posteriores sin confundir transferencia de registros con configuración de tienda, comportamiento de aplicaciones o propiedad de sistemas externos.
Matriz de traducción de relaciones para Shopify
La representación en Shopify resulta más clara cuando cada significado de origen se asigna a un registro de destino, una configuración, una aplicación conectada o una exclusión deliberada. La siguiente matriz mantiene esa decisión separada de la mera disponibilidad de campos.
| Significado de origen | Pregunta de representación en Shopify | Significado que debe conservarse en destino |
|---|---|---|
| Familia de Products vendibles | ¿Qué datos pertenecen al Product, sus variantes, contenido multimedia, elementos de inventario y ubicaciones? | Cada combinación vendible conserva SKU, precio, valores de opción, imagen y relación de inventario correctos. |
| Jerarquía de navegación | ¿Qué Categories de origen se convierten en colecciones, menús, filtros, páginas, redirecciones o solo organización interna? | Las rutas prioritarias llevan al comprador al conjunto correcto de Products sin destinos duplicados ni huérfanos. |
| Enriquecimiento estructurado | ¿El valor debe ser un campo nativo, metafield, referencia a metaobject, tag, valor de taxonomía o atributo de sistema externo? | El valor puede ser mostrado o consumido por el tema, aplicación, flujo o integración que lo necesita. |
| Identidad de Customer | ¿Qué valores pertenecen al perfil de Customer, direcciones, tags, notas, estado de marketing, contexto B2B o únicamente al Order histórico? | El personal puede identificar al comprador e interpretar su historial sin inventar comportamientos de cuenta no respaldados. |
| Transacción histórica | ¿Qué detalles de Order, pago, procesamiento, reembolso, descuento, impuesto y referencia externa siguen siendo útiles? | Atención al cliente y reconciliación pueden comprender la transacción sin tratar el historial como configuración activa. |
| Valor de contenido y URL | ¿Qué páginas, Blog Posts, handles, contenido multimedia, metadatos, menús y redirecciones necesitan un destino en Shopify? | Las URL prioritarias resuelven de forma deliberada y el contenido importante sigue siendo descubrible. |
| Estado de aplicación o integración | ¿Qué sistema será responsable del dato después del lanzamiento y qué identificador conecta ambos sistemas? | El propietario que continúa puede encontrar y utilizar el registro migrado sin crear fuentes de verdad duplicadas. |
El modelo de datos de Shopify debe evaluarse por sus relaciones, no por el recuento de registros. El número de variantes puede coincidir y, aun así, los valores de opción representar dimensiones de compra equivocadas; un metafield puede existir sin que ningún tema o aplicación lo consuma; un Customer puede existir mientras sus Orders históricos no quedan asociados correctamente; una colección puede existir mientras los menús siguen apuntando a rutas obsoletas. Por eso, el mapa de traducción debe documentar tanto el registro de destino como la relación que le da significado empresarial.
Los ejemplos representativos hacen ese mapa más sólido. Una familia compleja de Product puede mostrar cómo se relacionan opciones, variantes, contenido multimedia, inventario e identificadores. Una ruta de Category de alto valor puede mostrar cómo colecciones, menús, filtros y redirecciones reparten responsabilidades. Un Customer con varios Orders puede mostrar cómo permanecen conectadas identidad y transacciones. Un identificador controlado por una aplicación puede demostrar qué sistema seguirá siendo responsable después del lanzamiento.
Conclusión
Las diferencias del modelo de datos de Shopify importan porque la plataforma traduce el significado de la plataforma de origen a un modelo alojado. Products, variantes, colecciones, product category, tipo de producto, tags, metafields, metaobjects, Customers, Orders, CMS Pages, Blog Posts, aplicaciones, temas, Markets, redirecciones e integraciones tienen funciones específicas en la plataforma de destino.
Una migración fiable a Shopify no intenta conservar cada estructura de origen exactamente. Conserva el significado empresarial que debe sobrevivir después del lanzamiento. Cuando la lógica del catálogo, el significado de las colecciones, el contexto de Customers y Orders, el contenido, las URL, los campos personalizados, el comportamiento soportado por aplicaciones y los identificadores de integración se traducen deliberadamente, la tienda Shopify resulta más fácil de operar y gobernar.
Preguntas frecuentes
¿Las colecciones de Shopify son equivalentes a las Categories de origen?
No. Las colecciones pueden sustituir algunas funciones de Category, pero una Category también puede representar navegación, filtros, páginas de destino, valor SEO, agrupación interna o reglas de merchandising. Las rutas prioritarias de navegación deben traducirse a un modelo de descubrimiento de Shopify en lugar de copiarse uno a uno.
¿Cada campo personalizado de origen debería convertirse en un metafield de Shopify?
No. Los metafields son útiles cuando el campo tiene un propósito claro en destino. Campos obsoletos o duplicados, residuos de extensiones o valores sin finalidad de tienda, operación, integración o informes pueden hacer que la tienda de destino sea más difícil de mantener.
¿Las aplicaciones de Shopify se migran automáticamente desde la plataforma de origen?
No. Apps, extensiones, módulos y comportamiento de temas no son registros migrados ordinarios. El plan debe identificar qué comportamientos de origen requieren configuración de aplicaciones en Shopify, configuración de la tienda de destino, relación directa de campos, trabajo de integración o reestructuración de datos en destino.
¿Puede Shopify conservar exactamente la misma experiencia de cuenta de cliente que la plataforma de origen?
Los registros Customer y la experiencia de cuenta deben planificarse por separado. Los Customers migrados pueden conservar contexto útil de perfil e historial de Orders, pero el inicio de sesión, la activación, las expectativas sobre contraseñas, la fidelización y la comunicación con clientes pueden requerir planificación específica en destino.
¿Cómo deben repartirse metafields y metaobjects en Shopify?
Utiliza un metafield cuando los datos personalizados amplían un recurso concreto de Shopify, como Product, variante, Customer u Order. Utiliza un metaobject cuando la información sea un objeto estructurado reutilizable con varios campos, por ejemplo un bloque de especificaciones, perfil de autor, registro de ingredientes, guía de tallas o historia de marca. En ambos casos, define quién consume los datos y cómo se muestran o funcionan en la tienda de destino.
¿Cómo deben conservarse en Shopify los identificadores de sistemas externos?
Conserva un identificador externo solo cuando un ERP, PIM, CRM, sistema de procesamiento de pedidos, canal de venta externo o proceso de informes activo siga dependiendo de él. Guárdalo en el recurso de Shopify o registro de integración que espera el sistema que continuará utilizándolo; su unicidad, formato y comportamiento de búsqueda deben seguir siendo coherentes con ese sistema. Un identificador sin uso no debería convertirse en metadato permanente de la tienda.