Una migración a Cafe24 cambia algo más que el lugar donde se almacenan los registros. Cambia cómo deben funcionar conjuntamente después del lanzamiento la estructura de Products, el diseño de la tienda, las cuentas de Customers, el historial de Orders, el contexto de pagos, las operaciones de envío, las redirecciones, las aplicaciones y los procesos conectados mediante API.
Una tienda de origen puede organizar sus datos comerciales alrededor de un catálogo sencillo, una extensión de marketplace, una base de datos personalizada, una tienda regional, un proceso de inventario gobernado por ERP o un proceso de compra muy personalizado. Cafe24 puede admitir un modelo operativo estructurado con recursos de Product, opciones, variantes, inventarios, Categories, niveles de Customer, Orders, pagos, envíos, reembolsos, devoluciones, redirecciones, webhooks, recursos de diseño de tienda y conexiones con aplicaciones. La pregunta de migración no es si cada campo del origen puede copiarse a algún lugar. La pregunta es qué debe seguir significando cada registro cuando Cafe24 se convierte en la tienda operativa.
En Cafe24, la planificación del modelo de datos debe separar la migración de registros de la traducción del significado empresarial. Los datos de Product deben seguir apoyando las decisiones de compra. Los datos de Customers deben seguir permitiendo reconocer cuentas, segmentar y revisar el servicio. Los datos de Orders deben seguir siendo útiles para soporte posterior al lanzamiento, revisión de pagos y envíos, reembolsos, devoluciones e informes. Los datos de tienda y SEO deben conservar el descubrimiento donde importe. Los datos de aplicaciones y API deben asignarse al sistema futuro correcto en vez de tratarse como campos ordinarios.
Traducción del modelo de datos de Cafe24 de un vistazo
Cafe24 dispone de una superficie de datos amplia. Products, Categories, Customers, Orders, pagos, envíos, reembolsos, devoluciones, redirecciones y webhooks pueden ser relevantes durante la planificación. Eso no significa que todos los registros del origen pertenezcan a un único alcance plano de migración. Cada capa debe interpretarse según su función futura en Cafe24.
| Capa de datos | Qué puede existir en la tienda de origen | Pregunta de interpretación en Cafe24 |
|---|---|---|
| Identidad de Product | Nombre, SKU, marca, modelo, proveedor, código de proveedor e ID interno | ¿Qué identificador debe seguir visible para el comprador, la administración o una integración? |
| Estructura de Product | Opciones, variantes, bundles, atributos personalizados y grupos de Products | ¿Qué elementos se convierten en opciones, variantes, propiedades de Product o lógica de aplicaciones/personalizada? |
| Inventario | Cantidad de stock, stock por almacén, stock de seguridad, stock reservado y reglas de disponibilidad | ¿Qué valores deben migrarse, configurarse, sincronizarse o excluirse del contexto histórico? |
| Categories y merchandising | Árbol de Categories, ubicación en menús, reglas de colecciones, grupos de campaña y secciones destacadas | ¿Qué agrupaciones son estructura real de catálogo y cuáles son presentación o lógica promocional? |
| Datos de Customers | Cuentas, niveles, direcciones, notas, referencias de login social y contexto de consentimiento | ¿Qué campos se necesitan para continuidad de cuenta, segmentación, servicio y marketing? |
| Historial de Orders | Orders, artículos, opciones, pagos, envíos, reembolsos, devoluciones, cupones y notas | ¿Qué detalles deben seguir siendo útiles para soporte e informes y no para recrear el procesamiento activo? |
| Tienda y contenido | Menús, tableros, páginas, campos de detalle de Product, ajustes SEO, redirecciones y lógica del tema | ¿Qué elementos son datos, cuáles son configuración de tienda y cuáles requieren diseño o desarrollo? |
| Aplicaciones e integraciones | Datos propiedad de aplicaciones, webhooks, analítica, proveedores de pago e identificadores ERP/CRM/WMS | ¿Qué sistema futuro será responsable del proceso después de la migración? |
Un mismo campo del origen puede pertenecer a recursos diferentes de Cafe24 según defina una elección del comprador, descripción de catálogo, control operativo, evidencia histórica o relación con un sistema externo. El modelo de destino debe conservar esa función en lugar de limitarse a conservar la etiqueta del campo.
Los datos de Product son más que una lista de Products
La planificación de Products en Cafe24 debe comenzar por la función comercial del Product: qué ve el comprador, qué gestiona el equipo administrativo y de qué dependen los sistemas conectados. Una tienda de origen puede guardar atributos de Product como variantes, campos personalizados, metafields, tablas de especificaciones, etiquetas de Categories, datos de aplicaciones o bloques de texto. Cafe24 puede necesitar una separación más clara entre recursos de Product, opciones de Product, variantes, imágenes, campos SEO, etiquetas, Categories, propiedades personalizadas e inventario.
La distinción más importante es entre elección, descripción y operación. Un color, talla, cantidad de paquete o configuración puede ser una elección vendible. Un material, nota de compatibilidad, dimensión o certificación puede ser contenido descriptivo. Un código de proveedor, ubicación de almacén, valor aduanero o clave ERP puede ser dato operativo. Tratar las tres cosas como el mismo tipo de campo suele producir un catálogo de Cafe24 más débil.
| Elemento de Product del origen | Qué suele significar | Consideración de planificación en Cafe24 |
|---|---|---|
| SKU | Identificador vendible u operativo | Confirmar si pertenece al Product principal, a la variante o a un sistema externo. |
| Nombre y valor de opción | Lógica de selección del comprador | Confirmar si cada opción debe crear funcionamiento de variante o mantenerse como información. |
| Conjunto de imágenes de Product | Confianza del comprador y merchandising | Confirmar si las imágenes se asocian al Product principal, variantes o presentación de una página de destino. |
| Tabla de especificaciones | Contexto para comparar Products | Decidir si se conserva como detalle estructurado, propiedad personalizada o bloque de contenido. |
| Etiqueta promocional | Lógica de campaña o merchandising | Decidir si pertenece a etiquetas, ajustes de visualización, funcionamiento de aplicaciones o configuración de campaña de lanzamiento. |
| Campos SEO | Continuidad de búsqueda | Conservar metadatos y rutas de alto valor cuando apoyen el descubrimiento. |
| Campo personalizado | Significado desconocido hasta interpretarlo | Definir el significado empresarial antes de asignarlo. |
Una migración de calidad a Cafe24 no fuerza cada detalle del Product a entrar en el campo disponible más cercano. Identifica qué detalles deben seguir estructurados, cuáles pueden pasar a contenido de Product, cuáles requieren tratamiento mediante aplicaciones o diseño y cuáles deben permanecer fuera de Cafe24 en un sistema conectado.
Opciones, variantes e inventario necesitan un significado explícito
Cafe24 admite opciones de Product, variantes y recursos de inventario de variantes. Por ello, representar la lógica de opciones del origen es una decisión de relación de primer nivel en el destino. Muchas tiendas de origen emplean terminología distinta para opciones, variantes, Products secundarios, Products configurables, combinaciones, atributos, bundles y modificadores.
El plan debe evitar dos errores opuestos. El primero es aplanar variantes del origen en descripciones genéricas. El segundo es intentar conservar exactamente toda configuración del origen incluso cuando Cafe24 debería representarla de otra forma. El enfoque correcto consiste en identificar qué debe elegir el comprador, qué debe gestionar el comerciante y qué deben reconocer los sistemas de inventario o procesamiento de pedidos.
| Patrón que conviene revisar | Por qué importa | Paso de interpretación recomendado |
|---|---|---|
| Las opciones afectan al precio | La elección del comprador cambia el valor comercial | Confirmar si se necesita precio a nivel de variante u otra vía de configuración en Cafe24. |
| Las opciones afectan al stock | La elección del comprador cambia la disponibilidad | Confirmar la propiedad del inventario a nivel de variante. |
| Las opciones afectan a la imagen | La elección del comprador cambia la presentación | Confirmar si la asociación de imágenes debe seguir la lógica de variantes o la galería del Product. |
| Las opciones son solo descriptivas | La elección no afecta al procesamiento | Considerar contenido de Product, campos de especificación o contexto de filtrado en vez de crear variantes. |
| El origen utiliza Products agrupados o kits | Un artículo visible representa varios artículos operativos | Determinar si Cafe24, una aplicación o una asignación/reestructuración específica debe gestionar la relación. |
El inventario requiere la misma disciplina. Un valor de stock puede significar cantidad disponible, cantidad en almacén, cantidad vendible, stock reservado, lógica de backorder o un valor sincronizado desde otro sistema. Si el inventario del origen está controlado por ERP, POS, marketplace o software de almacén, Cafe24 no debe tratarse como única fuente autorizada sin confirmar el modelo operativo futuro.
Categories, menús y datos de descubrimiento no son lo mismo
Las tiendas de origen suelen combinar Categories, menús, colecciones, páginas de destino y agrupaciones de campaña. La planificación de Cafe24 debe separar esos significados. Una Category puede definir organización de Products. Un menú define navegación. Una página de destino puede definir merchandising. Una redirección puede proteger tráfico de búsqueda. Un filtro puede ayudar al comprador a encontrar Products. Estos significados se solapan, pero no son equivalentes.
Cuando se migran Categories sin esta distinción, el catálogo de destino puede contener Products y seguir resultando desorganizado para los compradores. Los Products pueden existir y no ser fáciles de encontrar. Las rutas SEO pueden existir y tener enlaces internos débiles. Las páginas de campaña pueden reconstruirse visualmente y perder la relación con los Products.
| Estructura del origen | Posible significado en Cafe24 | Consideración de migración |
|---|---|---|
| Árbol principal de Categories | Organización del catálogo | Conservarlo solo si apoya la navegación futura del comprador. |
| Etiquetas de menú | Ruta de la tienda | Reconstruirlas deliberadamente si los menús difieren de la estructura de Categories. |
| Colección destacada | Regla de merchandising | Decidir si utilizar ubicación en Categories, contenido, lógica de aplicación o selección manual. |
| Página de destino de campaña | Ruta de conversión | Conservar contenido y contexto de Product cuando sostengan tráfico de pago o SEO. |
| URL antigua | Activo de tráfico | Redirigir o retirar deliberadamente según su valor. |
| Filtro de Product | Apoyo al descubrimiento | Confirmar si el filtrado depende de campos estructurados o del tema/aplicación. |
Por eso, la planificación del modelo de datos de Cafe24 debe incluir el descubrimiento y no limitarse a campos de base de datos. Las decisiones sobre Categories y rutas afectan a la conversión porque determinan la rapidez con la que el comprador pasa de la intención a la selección del Product.
Los registros de Customers necesitan contexto de cuenta y segmentación
Los datos de Customers en Cafe24 pueden incluir cuentas, niveles, propiedades, notas, contexto de cuentas sociales, recursos de información de pago, campos de registro y detalles relacionados con marketing o servicio. La tienda de origen puede no separar estos conceptos con claridad. Algunos atributos de Customer pueden ser campos estándar. Otros pueden proceder de aplicaciones de fidelización, aplicaciones B2B, CRM, plataformas de marketing o formularios de registro personalizados.
La pregunta central es qué deben hacer esos datos después de la migración. Un registro de Customer puede necesitar continuidad de reconocimiento, asociación con historial de Orders, asignación de nivel, precios B2B, revisión de soporte, segmentación de marketing, reutilización de direcciones o revisión antifraude. Estos resultados requieren algo más que nombre y correo electrónico.
| Capa de Customer | Significado en migración | Consecuencia para la relación |
|---|---|---|
| Identidad de cuenta | Reconoce al comprador en Cafe24 | Cuentas duplicadas o asociación rota con Orders. |
| Nivel/grupo de Customer | Apoya precios, beneficios, segmentación o servicio | Se copia el nombre del nivel sin las reglas asociadas. |
| Direcciones | Apoyan proceso de compra y revisión de servicio | El formato de dirección no coincide con requisitos de mercado o envío. |
| Propiedades de registro | Capturan campos específicos del negocio | Se ignoran campos importantes porque eran personalizados en el origen. |
| Notas de Customer | Apoyan servicio y tratamiento interno | Las notas operativas migran sin significado o se pierden por completo. |
| Referencias sociales/de pago | Conectan identidad o pagos externos | Se supone que pueden migrarse datos sensibles o propiedad de proveedores. |
La migración de Customers también debe distinguir utilidad histórica de funcionamiento activo de la cuenta. Los datos históricos pueden apoyar al servicio, pero login activo, contraseñas, métodos de pago y beneficios de Customers pueden requerir configuración específica de plataforma o comunicación con los Customers.
El historial de Orders conserva evidencia operativa
Cafe24 dispone de recursos de Orders y áreas relacionadas que cubren artículos, información del comprador, cronologías de pago, destinatarios, envíos, reembolsos, devoluciones, cupones, notas, cancelaciones, cambios, canales de venta y recursos de Orders migrados. Esta amplitud es útil, pero eleva el nivel de detalle necesario para interpretar correctamente el historial.
El significado histórico de un Order no procede solo de su número. Los registros relacionados deben seguir explicando qué se compró, quién lo compró, cómo se pagó y envió, qué descuento se aplicó, si hubo reembolso o devolución y qué contexto de servicio pertenece a la transacción.
| Detalle de Order | Significado histórico | Implicación para el modelo de datos |
|---|---|---|
| Número y fecha | Identifican la transacción histórica | Conservar consistencia para soporte e informes. |
| Artículos y opciones comprados | Explican exactamente qué compró el Customer | Mantener comprensible el significado de variantes u opciones. |
| Estado y cronología de pago | Apoyan revisión del pago | No asumir que se recrea el funcionamiento del proveedor anterior. |
| Datos de envío y destinatario | Apoyan historial de procesamiento | Confirmar que el contexto de dirección y envío siga siendo útil. |
| Cupones y beneficios | Explican el resultado del descuento | Separar evidencia histórica de configuración activa de promociones. |
| Reembolsos, devoluciones y cambios | Apoyan soporte y revisión contable | Conservar contexto suficiente para soporte posterior al lanzamiento. |
| Notas o etiquetas del Order | Apoyan operaciones internas | Determinar si las notas siguen siendo útiles, sensibles u obsoletas. |
| Canal de venta | Muestra dónde se originó el Order | Conservarlo cuando afecte a informes o tratamiento de servicio. |
El objetivo de migración no es convertir Orders históricos en procesos operativos activos. Es conservar la evidencia necesaria para servicio al Customer, continuidad del negocio e informes después de que Cafe24 se convierta en el entorno comercial principal.
Los datos de tienda, diseño y contenido necesitan control de límites
Cafe24 incluye conceptos de diseño como Smart Design, Smart Themes, módulos, componentes, Web Components y funciones conectadas mediante aplicaciones. Las tiendas de origen pueden contener CMS Pages, contenido tipo blog, banners, menús, scripts, diseños de detalle de Product y páginas promocionales que no se transfieren como registros ordinarios de Products u Orders.
El contenido debe clasificarse según su propiedad y uso. Parte puede trasladarse como CMS Pages. Parte debe reconstruirse en el sistema de diseño de Cafe24. Parte del funcionamiento visual del origen debería retirarse porque refleja limitaciones antiguas. Los scripts y código insertado necesitan un responsable deliberado en el destino en lugar de reintroducirse automáticamente.
| Elemento de contenido o diseño | Interpretación de migración | Tratamiento preferido |
|---|---|---|
| CMS Pages | Páginas informativas con valor empresarial o SEO | Conservar o reconstruir según la estrategia actual de contenido. |
| Diseño de detalle de Product | Lógica de presentación que genera confianza de compra | Reconstruir deliberadamente si depende de temas o módulos. |
| Banners y páginas de destino | Contexto de campañas y merchandising | Conservar contenido de alto valor; evitar copiar campañas obsoletas. |
| Menús y navegación | Recorrido del comprador | Recrearlos conforme al plan futuro de navegación de Cafe24. |
| Scripts o elementos insertados | Funcionamiento personalizado o seguimiento | Revisar compatibilidad, privacidad y necesidad operativa. |
| Redirecciones | Continuidad de búsqueda y campañas | Conservar o redirigir rutas que mantengan valor para búsqueda, campañas o Customers. |
El modelo de datos incluye, por tanto, fronteras de presentación. Un archivo, página o script puede ser valioso sin pertenecer al alcance de migración del mismo modo que Products o Customers.
Aplicaciones, API, webhooks y sistemas externos definen la responsabilidad
Cafe24 puede operar con aplicaciones, API, webhooks, analítica, Data Bridge, proveedores de pago, servicios de envío, procesos de marketplaces y sistemas empresariales externos. En la planificación de migración, estas conexiones definen responsabilidad. Un registro puede aparecer en Cafe24 y, aun así, otro sistema controlar cómo se actualiza, fija su precio, procesa, reporta o muestra.
| Área conectada | Qué identificar | Por qué cambia el significado del dato |
|---|---|---|
| ERP o sistema de inventario | IDs de Product, responsabilidad sobre stock y reglas de almacén | Cafe24 puede mostrar stock mientras otro sistema controla las actualizaciones. |
| CRM o sistema de marketing | IDs de Customer, consentimiento, segmentos y datos del ciclo de vida | Los campos de Customer pueden necesitar sincronización y no una migración estática. |
| Proveedor de pago | Referencias de transacción, estado de pago y reembolsos | La evidencia histórica de pago difiere de la configuración activa. |
| Proveedor de envío | Tarifas, seguimiento, tratamiento de destinatarios y estado de procesamiento | Los registros de envío pueden no recrear los procesos del proveedor. |
| Marketplace o canal de venta | Identificadores de canal, reglas de stock y origen de Orders | El significado del canal afecta a informes y operaciones. |
| Aplicación personalizada o webhook | Lógica de activación, cargas de eventos e IDs externos | Puede necesitarse asignación o reestructuración específica cuando el funcionamiento debe transformarse. |
Este mapa evita un error habitual: migrar valores sin considerar el sistema que les da fiabilidad. Una migración estable a Cafe24 define qué sistema será responsable de cada resultado de datos importante después del lanzamiento.
El contexto de mercado, idioma y tienda puede cambiar el significado de los datos
Cafe24 suele ser considerado por comerciantes con necesidades regionales, ambiciones transfronterizas, requisitos del comercio coreano o modelos de tienda que deben coordinar Products, contenido, pagos, envíos y operaciones de marketplaces. Esto convierte el contexto de mercado en parte del modelo de datos. Un título de Product, etiqueta de Category, campo de Customer o estado de Order puede tener significado distinto según se utilice para venta nacional, internacional, mayorista, sincronización con marketplaces o informes de servicio.
Cuando la tienda de origen tiene varios idiomas, mercados o presentaciones específicas por país, la planificación debe evitar fusionar todo el significado en una descripción genérica de Product. Parte del contenido debe seguir visible para el comprador. Parte debe seguir siendo operativo. Parte puede necesitar recreación mediante configuración de tienda de Cafe24, aplicaciones, procesos externos de localización o configuración separada por mercado.
| Datos sensibles al mercado | Por qué requieren cuidado | Señal de planificación en Cafe24 |
|---|---|---|
| Nombres localizados de Products | Afectan a búsqueda, reconocimiento y comparación | Confirmar si el texto localizado pertenece al contenido de Cafe24, configuración de tienda o proceso externo de localización. |
| Descripciones específicas por mercado | Pueden incluir detalles legales, de envío o confianza | Separar contenido que debe seguir visible del texto antiguo que debe retirarse. |
| Contexto de moneda o precio | El precio puede depender de mercado, promoción o canal de pago | Confirmar el responsable futuro de precios antes de migrar campos relacionados. |
| Notas regionales de envío | La disponibilidad de entrega puede no ser contenido ordinario de Product | Decidir si la nota pertenece al detalle de Product, configuración de envío o contenido de políticas. |
| Identificadores de marketplace | Los IDs específicos de canal pueden ser operativamente importantes | Conservarlos solo cuando apoyen informes, sincronización o procesos de servicio futuros. |
Por tanto, el modelo de Cafe24 debe revisarse desde el contexto operativo futuro. Un mismo campo puede aportar valor distinto según sirva a compradores, administradores, integraciones, sincronización de marketplaces o informes posteriores al lanzamiento.
Las propiedades personalizadas y notas administrativas necesitan interpretación
Cafe24 incluye recursos relacionados con propiedades personalizadas de Products y Customers, notas, etiquetas, contenido de tableros y ajustes administrativos. Son útiles cuando la tienda migrada necesita más contexto operativo, pero pueden convertirse en un depósito indiscriminado si no se interpreta el origen.
La información personalizada debe clasificarse por función empresarial. Una especificación técnica puede mejorar la comparación. Un campo de registro de Customer puede apoyar calificación B2B. Una nota de Product puede ayudar al personal y no debe mostrarse al comprador. Un ID de base de datos del origen puede importar solo si ERP o CRM todavía depende de él. Un campo de una aplicación obsoleta puede no merecer migración.
| Tipo de dato personalizado | Mejor pregunta de clasificación | Posible dirección de tratamiento |
|---|---|---|
| Detalle de Product visible para el comprador | ¿Ayuda al Customer a elegir? | Conservar como información estructurada o contenido de página. |
| Nota operativa solo administrativa | ¿Ayuda al personal a dar soporte, procesar o reportar? | Conservar solo cuando siga siendo útil y seguro. |
| Identificador de integración | ¿Otro sistema seguirá utilizándolo? | Conservar en un campo controlado o mediante asignación/reestructuración específica. |
| Indicador de aplicación antigua | ¿Existe un consumidor actual en el destino? | Asignarlo a la aplicación o integración vigente, reestructurarlo o excluirlo. |
| Campo personalizado de registro | ¿Afecta al nivel del Customer, aprobación o servicio? | Asignarlo a propiedades de Customer/cuenta o revisarlo mediante una solución específica. |
El objetivo no es maximizar el número de campos migrados. Es conservar los que todavía crean valor empresarial dentro de Cafe24.
Conclusión
Cafe24 cambia el significado de los datos cuando los Products dependen de opciones y variantes, el inventario se controla entre sistemas, los Customers contienen contexto de nivel y registro, los Orders incluyen evidencia de pagos y procesamiento, las tiendas localizadas conservan valores distintos y las aplicaciones o API son responsables de parte del registro operativo.
La decisión central no es cuántos campos del origen pueden copiarse, sino qué recurso de Cafe24 debe ser responsable de cada valor, qué relaciones deben mantenerse, qué registros pertenecen al diseño de la tienda o lógica de aplicaciones y qué identificadores deben seguir conectando Cafe24 con sistemas externos. Un modelo claro de responsabilidad produce una tienda más limpia y evita convertir soluciones provisionales de la plataforma anterior en datos permanentes del destino.
Preguntas frecuentes
¿Las opciones y variantes de Product de Cafe24 coinciden siempre exactamente con las de la tienda de origen?
No. Las tiendas de origen pueden modelar opciones, variantes, atributos, Products agrupados y modificadores de distintas maneras. La planificación debe decidir qué elementos se convierten en elecciones vendibles, información estructurada de Product, variantes con inventario, funcionamiento de aplicaciones o requisitos de asignación/reestructuración específica.
¿Deben migrarse todos los campos personalizados del origen a Cafe24?
No automáticamente. Los campos personalizados deben interpretarse antes de asignarlos. Algunos son información de Product visible para el comprador, otros son notas administrativas, otros identificadores de integración y otros simples soluciones heredadas sin utilidad futura.
¿Qué datos de Orders son más importantes en una migración a Cafe24?
Los más importantes son los necesarios para servicio e informes: artículos comprados, significado de opciones, asociación con Customer, estado de pago, contexto de envío, descuentos, reembolsos, devoluciones, cambios y notas internas útiles.
¿Los datos de diseño de la tienda pueden tratarse como datos ordinarios de migración?
No. Contenido de tienda, módulos de diseño, scripts, menús, páginas de destino y funcionamiento del tema deben separarse de registros ordinarios de Product, Customer y Order. Algunos elementos pueden migrarse; otros necesitan rediseño, reconfiguración o desarrollo.
¿Cuándo necesitan los datos de Cafe24 una decisión de responsabilidad separada?
Cuando un valor del origen pertenece a una aplicación, marketplace, ERP, CRM, sistema de almacén, tabla personalizada o script de tienda y no a un registro ordinario de Product, Customer, Order o contenido. Conserve el valor solo cuando exista un responsable claro en el destino y una relación empresarial que continúe.
¿Por qué deben revisarse por separado el contexto de mercado e idioma en Cafe24?
El mismo Product o registro de contenido puede tener nombres, precios, visibilidad, URL o significado operativo diferentes según tienda, idioma o mercado. Revise estos ámbitos explícitamente para evitar que valores traducidos o regionales se sobrescriban con una única representación predeterminada.