Migrar hacia Storeden exige más que colocar registros en un nuevo entorno de administración. Storeden funciona como un entorno de comercio cloud que puede conectar gestión del catálogo, inventario, gestión de Orders, pagos, temas, aplicaciones, venta en plataformas de venta externas, logística, recursos de API y registros del ecosistema más amplio de TeamSystem. Ese modelo operativo cambia la forma en que deben interpretarse los datos migrados.
Una tienda de origen puede contener Products, Categories, Customers, Orders, registros SEO, campos de aplicaciones, identificadores de plataforma de venta externa o referencias ERP que parecían completos en la plataforma anterior. Después de la migración, esos mismos valores deben respaldar la estructura del catálogo de Storeden, la preparación de los canales de venta, los flujos de Orders, las integraciones y los informes del negocio. Por tanto, la cuestión del modelo de datos no es solo si llegan los registros. La cuestión es si siguen conservando el significado comercial correcto dentro de Storeden.
El significado de los datos en Storeden de un vistazo
La planificación de una migración hacia Storeden debe separar la transferencia de registros de su interpretación operativa. Un valor que en la tienda de origen aparece como opción de Product, nota de Order, etiqueta de pago, método de envío, grupo de Customer, campo personalizado o referencia de plataforma de venta externa puede necesitar un tratamiento diferente en Storeden.
| Área de datos | Significado que debe preservarse | Pregunta de propiedad en Storeden | Por qué importa la diferencia |
|---|---|---|---|
| Products | Identidad comercial del catálogo | Nombre, descripción, imágenes, precio, inventario, ubicación en Categories, visibilidad del Product y preparación para canales | Un Product puede existir y, aun así, resultar difícil de vender, localizar, gestionar o publicar correctamente. |
| Variantes y opciones | Opciones del comprador y significado operativo del SKU | Opciones equivalentes a variantes, valores de atributos, relaciones de SKU, implicaciones de stock, lógica de imágenes y diferencias de precio | La estructura de opciones afecta a la selección en la tienda, la preparación logística, el inventario y las fuentes de datos de plataformas de venta externas. |
| Categories y navegación | Forma de descubrir Products y jerarquía comercial | Agrupación en Categories, lógica de menús, ubicación de Products, expectativas de filtrado y rutas SEO | Un catálogo migrado puede parecer completo en administración mientras empeora la forma en que el comprador descubre Products. |
| Inventario | Disponibilidad y confianza en la preparación logística | Cantidades de stock, referencias SKU, disponibilidad multicanal, dependencias logísticas y fuentes de inventario conectadas con TeamSystem | El significado del stock puede depender de más de un canal o sistema. |
| Customers | Identidad de cuenta, comprador y atención | Perfil del Customer, historial de facturación/envío, datos de contacto, contexto empresarial y referencias externas | Los registros de Customers deben respaldar atención, búsqueda de Orders, continuidad de cuentas y uso de marketing. |
| Orders | Contexto comercial histórico | Products comprados, relación con el Customer, totales, impuestos, etiquetas de pago, datos de envío, valores de estado y origen dla plataforma de venta externa | El historial de Orders solo es útil si el personal puede comprenderlo y utilizarlo después de la migración. |
| Pagos y envíos | Etiquetas históricas frente a configuración activa | Etiquetas preservadas en Orders comparadas con configuración activa de pagos, transportistas, logística e impuestos | El historial migrado no configura el funcionamiento futuro del proceso de compra. |
| Registros de plataformas de venta externas | Contexto comercial específico de cada canal | Identificadores de publicaciones, Categories de plataforma de venta externa, precios por canal, reglas de disponibilidad y origen de Orders | La continuidad en plataformas de venta externas puede requerir más que la migración ordinaria de Products y Orders. |
| Datos de aplicaciones y APIs | Propiedad de flujos e identidad de integraciones | Datos gestionados por aplicaciones, referencias de API, IDs externos, disparadores de automatización y conexiones con el ecosistema TeamSystem | Los flujos conectados pueden necesitar configuración o un diseño específico del destino aunque migren los registros estándar. |
| SEO y contenido | Capacidad de encontrar contenido y continuidad | URLs, redirecciones, metadatos, descripciones de Products, contenido de Categories, nombres de imágenes y páginas controladas por el tema | La continuidad de búsqueda y de experiencia depende de presentación y rutas, no solo de registros importados. |
Los datos de Product pasan a formar parte de un catálogo gestionado de Storeden
Los registros de Product son el centro visible de una migración hacia Storeden, pero el significado de Product va más allá de la fila del Product. Un Product de origen puede incluir títulos, descripciones, códigos, SKUs, marcas, proveedores, clases fiscales, precios normales y promocionales, visibilidad, Categories, imágenes, relaciones entre variantes, Products relacionados, campos personalizados, atributos de plataforma de venta externa y claves externas de stock.
Storeden necesita que esos valores formen un catálogo que pueda administrarse de forma centralizada y distribuirse a través de los canales de venta previstos. Deben mantenerse separadas tres capas de responsabilidad: el Product comercial que ve el comprador, el artículo operativo que gestiona el personal y la representación del canal o sistema externo utilizada por plataformas de venta externas, servicios de inventario o sistemas contables.
| Elemento de origen | Interpretación en Storeden | Consecuencia sobre la relación |
|---|---|---|
| Título y descripciones del Product | Contenido de catálogo orientado al comprador | Idioma, formato e identidad del Product deben seguir unidos al mismo artículo comercial. |
| SKU o código de Product | Identidad operativa o entre sistemas | Variantes, líneas de Order, actualizaciones de inventario e integraciones deben referirse al artículo vendible previsto. |
| Imágenes | Relación multimedia de Product o variante | Imágenes principal, de galería y específicas de variantes no deben aplanarse en una lista de archivos sin orden. |
| Precio normal y promocional | Valor comercial que puede depender del tiempo o del canal | Los precios históricos de Orders siguen siendo evidencia; la propiedad de precios futuros pertenece al flujo de precios del destino. |
| Asignación de Category | Organización del catálogo | La pertenencia a una Category no debe confundirse con la ubicación en menús ni con la taxonomía de plataformas de venta externas. |
| Visibilidad o estado | Estado de publicación | Products activos, ocultos, en borrador o retirados necesitan un significado intencional en el destino. |
| Campo personalizado | Dato descriptivo, operativo, de canal o integración | El destino depende de quién lea o actualice ese valor después de la migración. |
Un Product solo está completo cuando su identidad, relaciones de variantes, Categories, contenido multimedia, contexto de precios y claves externas describen el mismo artículo vendible.
Variantes, opciones y atributos tienen responsabilidades distintas
Talla, color, material, cantidad por paquete, texto de personalización, elección de componentes, intervalo de suscripción y preferencia de entrega pueden aparecer como «opciones» en una exportación de origen, pero no necesariamente representan el mismo tipo de registro. La adaptación hacia Storeden debe separar una variante vendible de la información descriptiva de Product, la entrada aportada por el comprador en una línea de Order, la lógica de aplicaciones y los atributos específicos de canal.
La diferencia importa porque una variante real puede tener su propio SKU, stock, precio, imagen, peso, tratamiento fiscal o identidad de plataforma de venta externa. Un atributo descriptivo puede respaldar filtros o ayudar a comprender el Product sin crear un artículo vendible independiente. La personalización puede pertenecer a la línea de Order y no al Product principal. El funcionamiento de un paquete puede calcularlo una aplicación o un sistema externo de inventario.
| Patrón de origen | Significado en el destino | Relación que debe seguir siendo clara |
|---|---|---|
| Talla o color con SKU y stock | Variante vendible | Product principal, valores seleccionados, inventario, precio, imagen y línea de Order deben apuntar a la misma variante. |
| Material o propiedad técnica | Atributo descriptivo o valor de filtro | Preservar el significado estructurado sin crear variantes falsas con inventario propio. |
| Texto de personalización | Entrada del comprador asociada a una compra | Mantener el valor junto a la línea de Order correspondiente cuando deba seguir siendo visible históricamente. |
| Paquete o kit | Relación comercial o de inventario compuesta | Decidir si Storeden, una aplicación o un sistema externo es responsable de la lógica de componentes. |
| Atributo de plataforma de venta externa | Taxonomía de canal o requisito de publicación | Mantenerlo separado del modelo canónico de Product de la tienda salvo que ambos utilicen exactamente el mismo significado. |
| Código vinculado al ERP | Clave entre sistemas | Preservar el identificador estable sin exponerlo como contenido innecesario en la tienda. |
Esta interpretación evita un catálogo que parece correcto visualmente pero ya no identifica el artículo que se cobra, se mantiene en stock, se publica o se prepara.
Categories, navegación y taxonomías de canal son estructuras separadas
Una Category de origen puede actuar como padre del catálogo, elemento de menú, página de destino SEO, grupo promocional, regla de filtro, segmento de informes o relación con una taxonomía de plataforma de venta externa. Storeden no debe heredar todos esos significados a través de un único registro de Category.
| Estructura de origen | Papel en Storeden | Consecuencia de propiedad |
|---|---|---|
| Árbol padre-hijo de Categories | Organización canónica del catálogo | La pertenencia de Products y la jerarquía siguen siendo relaciones de datos. |
| Menú de la tienda | Presentación de navegación | El orden y las etiquetas del menú pueden hacer referencia a Categories, pero no forman parte del propio modelo de Category. |
| Descripción y metadatos de Category | Contenido de página de destino | El significado del contenido y del SEO debe seguir unido a la ruta pública correspondiente. |
| Filtro o faceta | Lógica de descubrimiento basada en valores estructurados | El atributo subyacente debe mantenerse coherente entre Products. |
| Colección manual o grupo de campaña | Relación de comercialización | Puede requerir selección manual, reglas o presentación mediante el tema en lugar de una Category permanente. |
| Category de plataforma de venta externa | Taxonomía específica del canal | Preservar la relación por separado respecto del árbol de Categories de la tienda. |
Separar estas estructuras permite que el catálogo de Storeden admita una gestión centralizada mientras cada tienda o plataforma de venta externa presenta Products mediante su propio modelo de descubrimiento.
Los valores de inventario necesitan un sistema de registro claramente definido
Una cantidad de origen puede representar stock físico, stock vendible, stock reservado, disponibilidad del proveedor, stock de almacén, disponibilidad por canal, capacidad de preventa o un valor sincronizado desde un ERP. Storeden debe recibir el valor de inventario que corresponde a su papel, junto con los identificadores necesarios para mantener ese valor conectado con el futuro sistema de registro.
| Patrón de inventario | Significado | Decisión de propiedad en Storeden |
|---|---|---|
| Una cantidad por Product | Disponibilidad vendible simple | Storeden puede ser responsable del valor cuando ningún otro sistema mantiene el stock. |
| Cantidad por variante o SKU | La disponibilidad pertenece al artículo hijo vendible | La identidad de la variante y el stock deben permanecer alineados. |
| Stock gestionado por ERP o almacén | Autoridad operativa externa | Storeden puede recibir disponibilidad sincronizada mientras el sistema externo continúa siendo la fuente autorizada. |
| Disponibilidad específica de plataforma de venta externa | Asignación por canal | Mantener las reglas de canal separadas de la cantidad física o canónica del Product. |
| Stock de paquete | Derivado de la disponibilidad de componentes | Preservar los identificadores de componentes y quién es responsable del cálculo. |
| Artículo sin stock o de servicio | La disponibilidad no es una cantidad física | Evitar inventar relaciones de stock que no existían en el modelo de origen. |
La frontera de migración debe preservar las cantidades iniciales cuando corresponda, pero, aún más importante, debe conservar las claves de Product o variante que permitan que las futuras actualizaciones de inventario lleguen al registro correcto.
Los datos de Customers y cuentas cumplen varias funciones
Los registros de Customers pueden representar compradores, titulares de cuentas, contactos de newsletter, cuentas de empresa, contactos de compras B2B, destinatarios de facturación, destinatarios de envío, Customers de plataforma de venta externa, registros CRM o identidades conectadas con TeamSystem. Tratar todos estos casos como una lista plana de Customers puede reducir la utilidad de la tienda de destino.
La planificación debe definir qué significa continuidad de Customer para la empresa. Algunas tiendas necesitan principalmente poder consultar Orders anteriores. Otras necesitan acceso a cuentas, segmentación de Customers, relaciones B2B, elegibilidad para marketing, referencias de facturas o continuidad de integraciones.
| Valor relacionado con Customer | Pregunta sobre el modelo de datos | Riesgo o consideración en Storeden |
|---|---|---|
| Nombre y correo electrónico | ¿El Customer es una cuenta real, un registro de comprador o un contacto? | Registros duplicados o parciales pueden afectar atención y uso de marketing. |
| Direcciones de facturación y envío | ¿Las direcciones están completas y vinculadas al Customer u Order correctos? | El personal necesita direcciones para revisar Orders históricos y atender Customers. |
| Grupo o segmento de Customer | ¿El valor es descriptivo, afecta a precios o afecta a permisos? | Los precios y el acceso pueden requerir configuración del destino o un diseño separado. |
| Datos de empresa o fiscales | ¿La empresa utiliza B2B o flujos de facturación? | La información de empresa puede ser importante para contabilidad e historial de Orders. |
| IDs externos | ¿CRM, ERP, contabilidad o herramientas de marketing dependen de ese ID? | Preservar o relacionar identificadores cuando sigan siendo necesarios operativamente. |
| Consentimiento y datos de marketing | ¿El origen contiene preferencias legalmente sensibles? | No tratar la migración de contactos como permiso para reutilizar registros de marketing sin revisión. |
Un modelo útil de Customer en Storeden permite al personal reconocer, atender y segmentar Customers correctamente. Los recuentos de registros por sí solos no preservan el significado de cuentas, segmentación, B2B, consentimiento o sistemas externos.
Los Orders preservan relaciones comerciales históricas
Un Order de Storeden es útil cuando permite explicar la transacción histórica: quién compró, qué Product o variante se seleccionó, qué cantidad y precio se aplicaron, qué descuentos e impuestos modificaron el total, cómo se describieron pago y envío, qué canal originó el Order y qué contexto de estado o seguimiento se produjo después.
| Valor histórico del Order | Significado que debe preservarse | Consideración separada del destino |
|---|---|---|
| Etiquetas de Product y variante | Identidad del artículo comprado | La estructura actual de Product puede evolucionar sin reescribir la línea histórica. |
| Precio, descuento e impuesto | Fotografía comercial del momento de compra | Los precios, campañas y reglas fiscales futuras pertenecen a la configuración actual. |
| Etiqueta de pago o referencia de transacción | Evidencia de cómo se pagó el Order | No crea una conexión activa de pago. |
| Método de envío y seguimiento | Contexto histórico de preparación logística | No define tarifas actuales del transportista ni reglas logísticas activas. |
| Estado y notas | Estado operativo pasado | Los nuevos flujos de Orders pueden utilizar estados diferentes. |
| Origen dla plataforma de venta externa | Atribución de canal y contexto para informes | Las publicaciones y sincronizaciones actuales siguen siendo registros separados. |
Esta separación mantiene legible el historial de Orders sin fingir que las etiquetas históricas son responsables del proceso de compra, los pagos, los impuestos o la preparación logística futura.
Los registros de plataformas de venta externas y multicanal forman una capa paralela de datos
El papel multicanal de Storeden convierte los datos de plataformas de venta externas en una capa paralela y no en unos pocos campos adicionales de Product. Identificadores de publicaciones, Categories de canal, títulos de ofertas, precios por canal, reglas de disponibilidad, atributos de plataforma de venta externa, referencias del vendedor y origen de Orders pueden relacionarse con el mismo Product canónico sin dejar de estar gestionados por un canal o conector concreto.
| Registro de canal | Relación canónica | Límite de propiedad |
|---|---|---|
| Identificador de publicación | Conecta un Product o variante de Storeden con una oferta externa | Conservarlo cuando el futuro conector o proceso de informes siga utilizándolo. |
| Category de plataforma de venta externa | Relaciona el Product con la taxonomía del canal | No integrarla en el árbol de Categories de la tienda Storeden. |
| Precio de canal | Valor comercial para un destino específico | Identificar si Storeden, un sistema intermediario o la plataforma de venta externa publica el precio final. |
| Stock de canal | Disponibilidad asignada o sincronizada | Mantener la regla del canal separada del stock físico o canónico. |
| Origen de Order de plataforma de venta externa | Contexto histórico del canal de venta | Preservarlo en Orders cuando sea útil para informes y atención. |
| Atributo de fuente de datos | Dato de Product requerido por el canal | Almacenarlo por separado cuando no represente el significado canónico del Product. |
La relación importante es un artículo comercial canónico con varias representaciones de canal. La migración debe preservar esa identidad sin duplicar cada registro de plataforma de venta externa como si fuera un Product independiente de Storeden.
Apps, APIs y conexiones con TeamSystem definen la propiedad de los registros
Storeden puede participar en un ecosistema más amplio de aplicaciones, APIs, contabilidad, inventario, logística, plataformas de venta externas y flujos conectados con TeamSystem. Estas conexiones crean registros que pueden aparecer dentro de la tienda, pero seguir siendo generados o gestionados por otro sistema.
| Propietario del registro | Datos habituales | Regla de interpretación |
|---|---|---|
| Comercio principal de Storeden | Products, Categories, Customers, Orders | Preservar directamente en Storeden las relaciones entre tipos de datos compatibles. |
| Aplicación o conector | Reviews, datos de fidelización, opciones personalizadas, fuentes de datos, estado de automatización | Determinar si la aplicación del destino ofrece un registro equivalente y un identificador persistente. |
| ERP, contabilidad, CRM o almacén | Códigos de Product, autoridad sobre stock, claves de Customer, referencias de facturas | Conservar la clave entre sistemas y evitar duplicar innecesariamente el modelo completo del sistema externo. |
| Plataforma de venta externa | Publicación, oferta, taxonomía y estado del canal | Preservar únicamente los registros necesarios para el flujo de canal que continuará. |
| Tema o capa de tienda | Composición, bloques, menús y comportamiento de presentación | Recrear la presentación por separado respecto de los registros canónicos de comercio. |
| Flujo de API | Importación, actualización, sincronización o lógica de eventos | Tratar el flujo como diseño de integración, no como un campo estático migrado. |
Cuando el origen contiene tablas de aplicaciones no compatibles o datos de conectores propietarios, el modelo de migración debe preservar el significado comercial y la clave externa solo cuando exista un propietario definido en el destino.
El contenido, las URLs y los datos SEO tienen relaciones propias
Descripciones de Products, textos de Categories, páginas, Blog Posts, imágenes, metadatos, enlaces internos, menús y redirecciones pueden estar repartidos por la tienda de origen. Storeden debe separar la propiedad del contenido de la propiedad del catálogo, incluso cuando el contenido aparezca en una ruta de Product o Category.
| Elemento de contenido o ruta | Relación con los datos de comercio | Significado en el destino |
|---|---|---|
| URL de Product | Ruta pública hacia un Product | La ruta puede cambiar mientras la identidad del Product permanece estable mediante claves internas y externas. |
| URL de Category | Ruta pública hacia una agrupación del catálogo | Jerarquía de Category, slug, ubicación en menús y redirección están relacionados, pero son elementos distintos. |
| Metadatos | Descripción de búsqueda de un recurso público | Mantenerlos asociados al Product, Category o página correctos. |
| Contenido enriquecido de página | Presentación editorial o gestionada por el tema | Reconstruirlo mediante la capa de contenido o tienda adecuada cuando no sea texto ordinario del catálogo. |
| Imágenes y contexto de texto alternativo | Medios relacionados con Products o contenido | Preservar asociación y secuencia, no solo los archivos. |
| Enlace interno | Relación entre rutas públicas | Reescribirlo cuando cambien las rutas del origen. |
| Redirección | Regla de continuidad desde una ruta antigua | Preservarla como lógica de rutas y no como contenido del Product. |
Esta separación evita cargar la migración del catálogo con comportamiento del tema, sin dejar de proteger el contenido y las rutas que permiten descubrir Products.
Conclusión
Storeden cambia el significado de los datos cuando un Product gestionado de forma central se representa mediante variantes, Categories, inventario, plataformas de venta externas, aplicaciones y sistemas empresariales externos. El mismo valor del origen puede ser dato de catálogo, atributo de canal, instantánea de un Order, clave de conector o contenido de tienda según quién sea responsable de él y cómo se actualice.
Por ello, un modelo coherente de migración hacia Storeden define una identidad canónica de Product, preserva relaciones de variantes y Orders, declara el sistema de registro del inventario, separa las Categories de la tienda de las taxonomías de plataformas de venta externas y conserva únicamente los identificadores externos necesarios para las integraciones que seguirán funcionando. Este enfoque crea un modelo multicanal más limpio que copiar todos los campos del origen dentro de Storeden sin contexto de propiedad.
Preguntas frecuentes
¿Por qué los datos de Product son más que una importación de Products en una migración hacia Storeden?
Los datos de Product deben respaldar presentación en la tienda, ubicación en Categories, confianza en el inventario, precios, imágenes, preparación de canales y gestión por parte del personal. Un registro de Product está incompleto cuando sus variantes, ubicación en Categories, visibilidad o atributos de plataforma de venta externa dejan de conservar el mismo significado.
¿Los Orders migrados configuran pagos y envíos en Storeden?
No. Los Orders migrados preservan información histórica de pago y envío como referencia. El proceso de compra, los pagos, los envíos, la logística, los impuestos y la preparación futura pertenecen a registros actuales y configuración operativa independientes de la plataforma.
¿Cuándo deben revisarse por separado los datos de plataformas de venta externas?
Deben revisarse por separado cuando la tienda de origen utiliza publicaciones, precios, Categories, atributos, reglas de stock, origen de Orders o identificadores específicos de cada canal. Esos valores pueden no comportarse como campos ordinarios de Product de la tienda online.
¿Cómo deben tratarse los campos personalizados y los IDs externos?
Los campos personalizados y los IDs externos deben clasificarse por su uso empresarial. Si respaldan ERP, contabilidad, CRM, logística, sincronización de plataformas de venta externas o informes, pueden necesitar relaciones entre campos, relaciones estructuradas con datos de destino, un tratamiento dedicado en el destino o un diseño separado, en lugar de una simple transferencia de campos.
¿Por qué los recuentos de registros son insuficientes para interpretar los datos de Storeden?
Los recuentos no muestran si las variantes siguen identificando artículos vendibles, si el inventario pertenece al sistema correcto, si los registros de plataformas de venta externas siguen relacionados, si los Orders conservan contexto comercial o si los IDs externos siguen conectando los sistemas correctos. El significado de las relaciones es la medida decisiva.
¿Cómo deben influir las integraciones de plataforma de venta externa o canal en la propiedad de los datos de Storeden?
Identifique qué sistema es responsable del Product canónico, el valor de inventario, la identidad del Customer, el estado del Order y el ID externo de publicación. Preserve las claves entre sistemas que sigan siendo operativas, pero no duplique los registros generados por integraciones como si Storeden fuera su fuente original de verdad.