El modelado de datos en Shopify Plus parte de la base de datos de Shopify y añade significado operativo empresarial relacionado con la estructura de la organización, B2B, Markets, varias tiendas, integraciones, permisos y responsabilidad sobre los flujos de trabajo. Products, variantes, colecciones, Customers, Orders, páginas, Blog Posts, redirecciones, metafields y aplicaciones siguen siendo elementos centrales. La diferencia a nivel Plus es que muchos de esos registros pueden tener un significado empresarial mayor que en una migración de una única tienda Shopify.
Esta distinción importa porque las plataformas de origen empresariales suelen almacenar lógica de comercio en estructuras que no se trasladan limpiamente a registros ordinarios de Shopify. Un origen Magento o Adobe Commerce puede utilizar grupos de Customers, websites, stores, store views, atributos de Products, reglas de precios, shared catalogs, cuentas B2B y datos propiedad de extensiones. Una plataforma personalizada puede utilizar tablas propias, identificadores de ERP, reglas de proceso de compra personalizadas, permisos de compradores basados en roles o catálogos regionales. Shopify Plus puede admitir muchos resultados empresariales, pero la planificación de la migración debe decidir si cada estructura de origen debe convertirse en datos de Shopify, configuración de Shopify Plus, configuración de una aplicación, correspondencia directa de campos, diseño de datos en destino, trabajo de integración o un flujo rediseñado.
Shopify Plus utiliza datos de Shopify con gobierno empresarial
Shopify Plus no es una plataforma de datos separada de Shopify. Los datos principales siguen los conceptos de Shopify: Products contienen variantes, las colecciones agrupan Products, Customers y Orders conservan el historial de compradores y transacciones, las páginas y Blog Posts sostienen el contenido, las redirecciones ayudan a mantener la continuidad del tráfico y los metafields o metaobjects amplían la información estructurada. Por ello, la planificación de la migración debe respetar el modelo de Shopify en lugar de inventar un modelo empresarial personalizado dentro de Shopify Plus.
La capa empresarial cambia cómo se gobierna ese modelo. Un Product puede tener que funcionar en varios mercados, varias tiendas, disponibilidad B2B, continuidad de SKU con el ERP, metafields personalizados o presentación comercial gestionada por aplicaciones. Un Customer puede tener que distinguirse de una cuenta de empresa, un rol de comprador, una ubicación, una condición de pago o una estructura comercial regional. Una experiencia de tienda puede pertenecer a una tienda que utiliza Markets o a una de varias expansion stores bajo una organización. Estas decisiones no son cosméticas: determinan cómo se utilizarán los datos migrados después del lanzamiento.
| Área de datos | Significado principal en Shopify | Significado para una migración a Shopify Plus |
|---|---|---|
| Products y variantes | Estructura de catálogo vendible. | Lógica empresarial de SKU, disponibilidad B2B, presentación comercial específica por mercado, referencias de ERP y gobierno de datos de Products. |
| Colecciones | Agrupación de Products para navegación y presentación del catálogo. | Decisiones de segmentación por región, marca, canal, B2B y campaña. |
| Customers | Perfiles de compradores e historial de Orders. | Compradores D2C, contactos B2B, relaciones con empresas, roles de compradores y responsabilidad sobre cuentas. |
| Orders | Contexto histórico de transacciones. | Soporte, reconciliación, revisión de Orders B2B, condiciones de pago, evidencia de procesamiento de pedidos y valor de referencia para integraciones. |
| Metafields y metaobjects | Extensiones estructuradas de datos personalizados. | Enriquecimiento de Products, modelos de contenido, identificadores de integración, atributos B2B y contexto operativo empresarial. |
| Tiendas y organización | Entornos de administración y tienda. | Varias tiendas, gobierno, permisos, seguridad, facturación y responsabilidad operativa. |
La migración no debe reducir estas diferencias a una simple transferencia de registros. Debe definir el significado en destino de cada estructura crítica para la empresa.
Products, variantes y significado del catálogo empresarial
Los Products y variantes de Shopify siguen siendo la primera capa de revisión del catálogo. Los Products de origen con tallas, colores, unidades, paquetes, kits, opciones configurables, opciones de suscripción o SKU controlados por ERP deben interpretarse frente a la estructura de Products y variantes de Shopify. Shopify Plus no elimina la necesidad de tomar estas decisiones; aumenta su importancia porque los datos de catálogo pueden dar soporte a más marcas, mercados, catálogos B2B, tiendas y sistemas externos.
Un catálogo D2C sencillo puede migrarse a Products y variantes con poca interpretación adicional. Un catálogo empresarial suele requerir una clasificación más profunda. Los atributos del origen pueden representar contenido descriptivo, especificaciones consultables, opciones que definen variantes, entradas para filtros, identificadores de ERP, indicadores de elegibilidad B2B, valores específicos por mercado o lógica propiedad de aplicaciones. Tratar todos los atributos como simples descripciones puede debilitar la presentación del catálogo, la búsqueda y las integraciones.
| Patrón del catálogo de origen | Pregunta de planificación para Shopify Plus |
|---|---|
| Product configurable con muchos atributos de origen | ¿Qué atributos definen variantes de Shopify, cuáles pasan a ser metafields y cuáles deben permanecer fuera de Shopify? |
| Visibilidad de Products basada en grupos de Customers | ¿Debe gestionarse mediante catálogos B2B, separación de tiendas, una regla de aplicación o un diseño de datos independiente? |
| Nombres o descripciones regionales de Products | ¿Debe utilizarse Markets/localización, tiendas separadas, flujos de traducción o reconstrucción de contenido? |
| SKU o ID de Product del ERP | ¿Debe conservarse como SKU, metafield, dato de aplicación o referencia de integración? |
| Paquete, kit, suscripción o paquete configurable | ¿Debe utilizar configuración de Shopify o de una aplicación, un rediseño en destino o configuración manual? |
| Enriquecimiento empresarial de Products | ¿Los datos estructurados deben convertirse en metafields, metaobjects, datos de aplicación o configuración de tema/contenido? |
La migración de Products es más sólida cuando cada campo del origen tiene una finalidad clara en destino. El objetivo no es forzar todos los campos empresariales del origen a la forma nativa de Product de Shopify. Es conservar la información que debe seguir siendo utilizable dentro del modelo operativo de Shopify Plus.
Colecciones, navegación y segmentación de la tienda
Las colecciones no equivalen a las Categories de todas las plataformas de origen. Algunas plataformas utilizan Categories como jerarquía de base de datos, navegación de la tienda, páginas comerciales del catálogo, páginas de aterrizaje SEO, grupos para informes o estructuras de control de acceso. Las colecciones de Shopify pueden sostener agrupación de Products y presentación comercial de la tienda, pero el plan de migración debe decidir si cada agrupación del origen debe convertirse en una colección de Shopify, un elemento de navegación, una página, un destino de redirección, una experiencia específica por mercado, una regla de catálogo B2B o una estructura histórica que se excluya.
Shopify Plus añade preguntas de segmentación. Un comercio puede operar tiendas separadas por marca o región. Otro puede utilizar una sola tienda con Markets y contenido localizado. Un comercio B2B puede necesitar disponibilidad de Products por empresa o catálogo en lugar de depender únicamente de colecciones públicas. Estas decisiones en destino afectan a cómo debe representarse el significado de Categories y colecciones.
| Significado de la agrupación en origen | Interpretación más adecuada en Shopify Plus |
|---|---|
| Ruta pública de navegación para Customers | Colección de Shopify, navegación y revisión de la tienda. |
| Landing page SEO | Decisión entre colección, página, redirección, metadatos o reconstrucción de contenido. |
| Agrupación regional de tienda | Markets/localización o planificación de expansion stores. |
| Agrupación de acceso exclusivo B2B | Catálogo B2B, regla de aplicación o diseño de tienda separado. |
| Grupo interno para informes | Metafield, tag, datos de aplicación o exclusión de la tienda pública. |
| Category heredada que ya no se utiliza | Exclusión deliberada, tratamiento de archivo o destino de redirección. |
La diferencia clave está en el significado. Una misma Category de origen puede cumplir varias funciones. La planificación de Shopify Plus debe conservar las funciones que importan tras el lanzamiento, no solo los nombres de las Categories.
Las empresas B2B no son Customers ordinarios
B2B puede ser una de las dimensiones más importantes del modelo de datos en una migración a Shopify Plus, especialmente cuando el destino utiliza capacidades específicas de Plus para asignación de catálogos o pagos. En los distintos planes de Shopify, los registros de Customers pueden participar en estructuras de empresas B2B en lugar de representar únicamente perfiles de compradores con datos de contacto e historial de Orders. Un comprador empresarial puede tener que existir dentro de una estructura de empresa. Company representa la organización principal; Company Locations conserva el contexto de compra específico de cada ubicación, como direcciones, información fiscal, catálogos, condiciones de pago y contactos asignados. Un perfil de Customer puede conectarse a una o varias Company Locations, por lo que la identidad del comprador y el contexto de la cuenta empresarial no deben reducirse a una única etiqueta de Customer.
Una plataforma de origen puede representar B2B de muchas maneras: grupos de Customers, cuentas de empresa, procesos de presupuestos, jerarquías de cuentas, catálogos contractuales, shared catalogs, compradores exentos de impuestos, relaciones con representantes comerciales, IDs de cuenta del ERP, permisos de aprobación o campos personalizados. Estos elementos no deben migrarse automáticamente como simples etiquetas o notas de Customer salvo que ese sea realmente el significado previsto en destino.
| Estructura B2B de origen | Pregunta para el destino Shopify Plus |
|---|---|
| Grupo de Customers | ¿Es un segmento, un atributo de empresa, contexto de precios, regla de catálogo o etiqueta histórica? |
| Cuenta de empresa | ¿Debe convertirse en una Shopify B2B Company con Company Locations o utilizar otra estructura de cuenta definida? |
| Rol o permiso de comprador | ¿Qué contacto Customer pertenece a cada Company Location y qué rol de compra debe mantenerse? |
| Precios contractuales | ¿Los precios pertenecen a catálogos B2B, precios gestionados por una aplicación o un sistema externo de precios? |
| Identificador de cuenta del ERP | ¿Debe utilizar Company ID, Company Location ID, un metafield o una referencia propiedad de la integración? |
| Flujo de presupuesto o aprobación | ¿Es configuración dentro de Shopify, un flujo de aplicación o un funcionamiento del origen que no tiene soporte directo? |
Esta separación evita un error importante de migración: contar registros de Customers como migrados mientras se pierde la arquitectura comercial que hacía utilizables esos Customers para la venta B2B.
Markets, localización y estructuras multitienda
Los comercios de Shopify Plus suelen migrar desde plataformas con websites, store views, configuraciones regionales, regiones, marcas, dominios o catálogos específicos por mercado. Estas estructuras del origen deben interpretarse con cuidado porque Shopify Plus puede dar soporte a la venta internacional mediante Markets y también a varias tiendas o expansion stores. El modelo de destino adecuado depende del gobierno, la responsabilidad sobre el contenido, los equipos operativos, la disponibilidad de Products, la divisa, los impuestos, el envío y la estrategia regional de marca.
Una store view del origen no equivale necesariamente a un market de Shopify. Un dominio regional puede no requerir una tienda Shopify Plus separada. Una versión de idioma puede pertenecer a la configuración de traducción/localización en lugar de convertirse en un árbol de contenido migrado separado. Un website del origen puede representar una marca, geografía, canal o una antigua decisión de implementación que no debería copiarse de forma mecánica.
| Estructura de origen | Posible interpretación en Shopify Plus |
|---|---|
| Store view o vista por idioma | Configuración de localización y traducción, o una tienda separada si el gobierno lo requiere. |
| Dominio específico de un país | Market, estrategia de dominios, plan de redirección o decisión sobre expansion store. |
| Catálogo regional | Reglas de disponibilidad de Products, configuración de Markets, catálogo B2B, lógica de aplicación o tienda separada. |
| Sitio multimarcas de origen | Expansion store, tienda separada, colecciones o arquitectura de contenido específica por marca. |
| Páginas CMS localizadas | Páginas, Blog Posts, traducciones, metaobjects, redirecciones o reconstrucción manual de contenido. |
| Precios regionales | Precios de Markets, precios de catálogo B2B, configuración de aplicación o lógica de sistema externo. |
Por tanto, la pregunta del modelo de datos no es únicamente dónde se guardarán los registros. También es qué estructura operativa de destino deben respaldar esos registros migrados.
Metafields, metaobjects y gobierno de datos personalizados
Los metafields y metaobjects son herramientas importantes en una migración a Shopify Plus, pero no deberían convertirse en un depósito para todos los campos del origen. Los metafields amplían recursos existentes de Shopify, como Products, Customers, variantes, Orders u otros objetos. Los metaobjects crean objetos estructurados con varios campos que pueden ser referenciados por metafields, utilizarse en temas o gestionarse como entradas de contenido/datos.
En Shopify Plus, la planificación de datos personalizados debe ser más disciplinada porque las plataformas de origen empresariales suelen contener grandes volúmenes de atributos, especificaciones, campos personalizados, IDs de ERP, indicadores de mercado, etiquetas B2B, contenido comercial y registros propiedad de aplicaciones. Algunos campos son útiles para contenido orientado a Customers. Otros son necesarios para integraciones. Algunos son históricos. Otros están obsoletos. Algunos requieren definiciones de campo, reglas de datos o configuración de tema. Otros no deberían migrarse.
| Tipo de dato personalizado | Posible tratamiento |
|---|---|
| Especificaciones de Products | Metafields de Product, metafields de Category, metaobjects o datos de aplicación. |
| Bloques de contenido enriquecido y reutilizable | Metaobjects, páginas, Blog Posts, secciones de tema o reconstrucción manual de contenido. |
| Identificadores ERP/CRM/PIM | Metafields, campos propiedad de aplicaciones, un ID externo nativo o una referencia de integración. |
| Contexto de cuenta B2B | Configuración de Company y Company Location, metafields de Customer o datos propiedad de aplicaciones. |
| Datos de extensiones del origen | Migración mediante aplicación, correspondencia de integración, archivo o rediseño cuando no existe un destino nativo. |
| Campos históricos para informes | Exclusión, archivo, metafield o decisión de mantenerlos en informes externos. |
El mejor modelo de datos de Shopify Plus no es el que migra más campos personalizados. Es aquel en el que cada campo personalizado tiene un responsable de destino definido, un comportamiento de presentación, una regla de calidad de datos y una finalidad empresarial.
Orders, pagos, procesamiento de pedidos y contexto de los flujos de trabajo
La migración de Orders a Shopify Plus debe conservar el significado histórico, no dar a entender que se recrean todos los flujos del origen. Los Orders del origen pueden incluir etiquetas de pago, métodos de envío, descuentos, contexto fiscal, estados de procesamiento, envíos parciales, reembolsos, presupuestos, facturas, referencias de órdenes de compra, IDs de ERP o datos del representante comercial. Parte de ese contexto puede conservarse como información histórica del Order. Otra parte puede pertenecer a la configuración de Shopify, configuración de aplicaciones, integraciones externas o un flujo de destino rediseñado.
Esta distinción cobra más importancia para comercios Plus porque los Orders históricos pueden servir para atención al cliente, revisión de cuentas B2B, repetición de compras mayoristas, reconciliación financiera, correspondencia con ERP y análisis del procesamiento de pedidos. Sin embargo, el historial de Orders migrado no configura el proceso de compra activo de Shopify, procesadores de pago, lógica fiscal, enrutamiento de pedidos, procesos de órdenes de compra ni condiciones de pago B2B.
| Contexto del Order de origen | Interpretación para una migración a Shopify Plus |
|---|---|
| Referencia de pago | Contexto histórico, no configuración del pago activo. |
| Método de procesamiento de pedidos | Legibilidad histórica más revisión de la configuración de procesamiento en destino. |
| Reembolso o cancelación | Contexto histórico para soporte y reconciliación. |
| Número de orden de compra | Contexto de Order B2B, metafield o datos de aplicación, o referencia de un sistema externo. |
| ID de Order del ERP | ID externo nativo, metafield, campo de aplicación o referencia de integración. |
| Historial de presupuestos o aprobaciones | Nota histórica, flujo de aplicación, configuración B2B o funcionamiento personalizado sin soporte directo. |
Una migración fiable a Shopify Plus debe hacer útil el historial de Orders sin confundir la historia con la configuración operativa activa.
Aplicaciones, integraciones y datos de sistemas externos
Los comercios Shopify Plus suelen depender de ERP, PIM, OMS, CRM y sistemas de suscripción, fidelización, reseñas, fiscalidad, envío, fraude, analítica, canales de venta externos, personalización y automatización. Algunos valores del origen son datos nativos de comercio; otros pertenecen a esos sistemas y aparecen en la plataforma de origen únicamente porque una extensión o integración los copió allí.
La decisión de traslado debe identificar qué sistema seguirá siendo el sistema de registro. Un PIM puede seguir siendo la autoridad para el enriquecimiento. Un ERP puede continuar controlando identificadores de cuenta, SKU, inventario u Orders. Una plataforma de suscripción puede seguir siendo responsable de contratos y calendarios de facturación. Una aplicación de fidelización puede seguir siendo responsable de saldos e historial de niveles. Guardar copias en Shopify Plus no transfiere la responsabilidad ni recrea el flujo de trabajo.
| Dependencia | Pregunta del modelo de datos |
|---|---|
| ERP | ¿Qué identificadores de Product, Customer, Company, Company Location, Order e inventario deben permanecer estables? |
| PIM | ¿Qué atributos se convierten en campos de Shopify, metafields o metaobjects y cuáles siguen bajo responsabilidad del PIM? |
| OMS o sistema de procesamiento de pedidos | ¿Qué valores de Orders y procesamiento son contexto histórico y cuáles siguen siendo operativos en el sistema conectado? |
| CRM | ¿Qué campos de Customer pertenecen a Shopify Plus y cuáles deben permanecer como datos de relación en el CRM? |
| Aplicación de suscripciones | ¿Qué registros e identificadores deben transferirse mediante la aplicación en lugar de representarse como Orders ordinarios? |
| Aplicación de fidelización o reseñas | ¿Qué saldos, membresías, reseñas y claves entre sistemas tienen un destino compatible? |
Un valor crítico para el negocio no debe trasladarse únicamente porque exista un campo disponible. Debe tener un responsable identificado, un identificador estable, una representación definida en Shopify Plus cuando sea necesaria y un consumidor que siga utilizándolo. Cuando estas condiciones no existan, puede ser mejor archivar el valor, rediseñar el flujo o mantenerlo en el sistema externo en lugar de crear otra copia sin gobierno.
Conclusión
Las diferencias del modelo de datos de Shopify Plus no se limitan a los campos de Shopify. Se refieren al significado empresarial asociado a los datos de Shopify. Products, variantes, colecciones, Customers, Orders, páginas, Blog Posts, redirecciones, metafields, metaobjects, aplicaciones y estructuras de nivel organizativo deben interpretarse teniendo en cuenta B2B, Markets, gobierno multitienda, integraciones externas y responsabilidad operativa.
Un modelo de datos coherente de Shopify Plus distingue los datos ordinarios de Shopify de las estructuras operativas a nivel Plus. Identifica qué debe migrarse, qué debe configurarse en Shopify Plus, qué pertenece a aplicaciones o integraciones, qué requiere correspondencia directa o reestructuración de datos y qué corresponde a la implementación de aplicaciones o integraciones. Esta distinción evita que la tienda de destino se convierta en una copia superficial de la plataforma de origen en lugar de un entorno empresarial Shopify realmente utilizable.
Preguntas frecuentes
¿Las diferencias del modelo de datos de Shopify Plus son independientes de las de Shopify?
Están relacionadas, pero no son independientes. Shopify Plus utiliza la base de datos de Shopify, aunque las migraciones Plus suelen añadir más significado empresarial a los mismos registros mediante B2B, Markets, varias tiendas, datos personalizados, integraciones, permisos y gobierno de flujos de trabajo.
¿Los grupos de Customers B2B del origen deberían convertirse en etiquetas de Customer de Shopify?
No automáticamente. Un grupo de Customers del origen puede representar precios, estructura de empresa, acceso de compradores, situación fiscal, segmentación o una etiqueta histórica. Debe revisarse el significado de destino antes de decidir si corresponde a empresas B2B, catálogos, segmentos de Customers, metafields, aplicaciones o una decisión deliberada sobre los datos de destino.
¿Los metafields pueden resolver todos los requisitos de datos personalizados de Shopify Plus?
No. Los metafields amplían un recurso existente de Shopify; los metaobjects modelan registros estructurados reutilizables. Ninguno de los dos recrea un flujo de aplicación, una relación con ERP, un modelo de permisos B2B ni un sistema externo de registro. Deben utilizarse únicamente cuando estén definidos el responsable y el consumidor de los datos en destino.
¿Cómo deben interpretarse los datos multitienda del origen para Shopify Plus?
Los datos multitienda del origen deben vincularse a la estructura operativa de destino prevista. Pueden convertirse en una tienda Shopify Plus con Markets, varias tiendas, expansion stores, contenido localizado, catálogos B2B o una combinación de configuración en destino y alcance de migración.
¿Qué relaciones de Shopify Plus requieren una interpretación más cuidadosa?
B2B Companies y Company Locations, la responsabilidad de cada market o tienda, el contexto de catálogos y precios y los identificadores de sistemas externos requieren la correspondencia de relaciones más precisa. Cada registro puede existir en Shopify Plus y, aun así, quedar asociado al comprador, ubicación, tienda, catálogo o sistema de registro equivocados.
¿Cómo deben conservarse las relaciones entre empresas B2B y ubicaciones en Shopify Plus?
La empresa, sus ubicaciones, compradores asignados, catálogos, condiciones de pago, contexto fiscal e IDs de cuenta externos deben tratarse como registros relacionados, no como etiquetas de Customer. La correspondencia debe mantener cada comprador asociado a la ubicación de compra correcta y conservar los identificadores necesarios para los sistemas administrativos que seguirán operando.