Magento Open Source es una plataforma de comercio electrónico autohospedada y extensible diseñada para comerciantes y equipos de implementación que quieren control directo sobre la aplicación, la base de datos, la infraestructura, el código, las extensiones, los temas, las integraciones y el proceso de despliegue. Su principal fortaleza es la flexibilidad estructural: el catálogo puede usar varios tipos de Product, atributos reutilizables, attribute sets, árboles de Categories, websites, stores y store views, mientras el código puede ampliarse mediante módulos e integraciones de servicios.
Esa flexibilidad hace que Magento Open Source sea materialmente distinto de una plataforma alojada con un modelo operativo estrecho y prescrito. La tienda de destino no se obtiene únicamente a partir de los datos migrados. Se construye mediante registros de catálogo, alcance de configuración, temas, módulos, búsqueda, integraciones, infraestructura, prácticas de despliegue y gobierno técnico continuo.
Un panorama claro también debe mantener separado Magento Open Source de Adobe Commerce. Comparten linaje de plataforma y muchos conceptos básicos, pero no son ediciones intercambiables. Las funciones que dependen de Adobe Commerce no deben suponerse disponibles en Magento Open Source solo porque la terminología subyacente resulte familiar.
Magento Open Source como plataforma de comercio autohospedada
Magento Open Source asigna al comerciante o al equipo de implementación la responsabilidad sobre el entorno de la aplicación. Esto incluye hosting, servicios de base de datos, servicios de búsqueda, caché, almacenamiento multimedia, certificados, copias de seguridad, monitorización, despliegue, parches, compatibilidad de extensiones y mantenimiento de seguridad. La plataforma proporciona la aplicación de comercio, pero no elimina la necesidad de un equipo responsable de operarla.
Este modelo de responsabilidad influye en la orientación de la migración desde el inicio. Una tienda de destino puede contener Products, Customers y Orders y seguir operativamente incompleta porque la búsqueda no está preparada, los índices no están actualizados, las extensiones son incompatibles, las plantillas del tema no muestran los campos migrados o la infraestructura no tiene suficiente capacidad.
| Capa de arquitectura | Propiedad habitual | Importancia para la migración |
|---|---|---|
| Datos de comercio | Products, Categories, Customers, Orders, Reviews, CMS Pages y registros relacionados | Los registros compatibles deben conservar relaciones y significado comercial. |
| Configuración de tienda | Websites, stores, store views, monedas, impuestos, inventario, email, estados de Order y ajustes de catálogo | El alcance y el funcionamiento futuro deben establecerse en la tienda de destino. |
| Código de aplicación | Núcleo de Magento Open Source, módulos, personalizaciones y API | Los datos pueden depender de atributos, tablas o lógica de negocio propiedad de módulos. |
| Presentación | Temas, layouts, bloques, plantillas, contenido y medios | Los datos migrados deben mostrarse y ser navegables mediante la implementación de tienda elegida. |
| Infraestructura | Web, base de datos, búsqueda, caché, colas, almacenamiento, despliegue y monitorización | El rendimiento y la fiabilidad dependen del diseño y mantenimiento del entorno. |
| Sistemas externos | ERP, PIM, WMS, CRM, impuestos, pagos, envíos, analítica y marketplaces | Los identificadores y flujos necesitan una propiedad de integración explícita. |
Magento Open Source recompensa una implementación disciplinada. Su amplitud debe tratarse como una arquitectura que debe gobernarse, no como permiso para reproducir cada personalización heredada.
Magento Open Source también depende de procesamiento en segundo plano y datos derivados para la tienda. Los cambios del catálogo pueden requerir indexación antes de aparecer correctamente en búsqueda, navegación, precios o vistas de inventario. Las cachés y artefactos de despliegue también pueden afectar lo que administradores y clientes ven después de cargar registros. Estos mecanismos pertenecen al entorno operativo, no al registro migrado, y deben estar en buen estado para que la tienda de destino represente correctamente los datos.
Por eso, el comerciante debe distinguir una discrepancia de datos de una discrepancia del entorno. Un Product puede ser correcto en almacenamiento mientras un índice desactualizado, una caché, una plantilla del tema o una respuesta de integración hacen que la tienda parezca incorrecta. Esa distinción será esencial durante la validación y el diagnóstico posterior.
Arquitectura del catálogo: Products, atributos y attribute sets
El catálogo de Magento se construye alrededor de Products estructurados y atributos reutilizables. Información como nombre, SKU, precio, estado, visibilidad, peso, descripciones, clase fiscal, medios y campos empresariales personalizados puede representarse mediante atributos. Los attribute sets agrupan los campos necesarios para familias concretas de Product.
Este modelo permite gobernar el catálogo como algo más que una colección de registros aislados. Un Product de moda puede necesitar talla, material, instrucciones de cuidado y temporada. Un Product industrial puede necesitar voltaje, certificación, dimensiones y compatibilidad. Esos campos pueden organizarse en administración y exponerse selectivamente en la tienda, integraciones, búsqueda o generación de informes.
La relevancia para la migración no consiste únicamente en que los atributos puedan importarse. La tienda de destino necesita una arquitectura coherente de atributos:
- los códigos de atributo deben ser estables y significativos;
- los tipos de datos deben corresponder a su uso operativo;
- los attribute sets deben reflejar familias reales de Product;
- los valores seleccionables deben normalizarse cuando se reutilizan;
- los campos obligatorios no deben bloquear registros válidos de forma inesperada;
- visibilidad, búsqueda, filtrado, comparación e integración deben configurarse de manera intencional;
- residuos obsoletos de extensiones no deben convertirse en estructura permanente del catálogo.
Magento Open Source también admite varias estructuras de Product para distintos patrones de venta. Products simples, variantes, bundles, relaciones agrupadas, productos virtuales, descargables o lógica personalizada de opciones de la tienda de origen deben interpretarse según cómo se venderán en la tienda de destino. Una relación padre-hijo del origen puede parecerse a una estructura configurable de Magento, pero el parecido no basta: deben alinearse la propiedad de SKU, precios, stock, imágenes y funcionamiento de selección del comprador.
| Aspecto del catálogo | Significado en Magento Open Source | Orientación inicial |
|---|---|---|
| Identidad de Product | Registro de comercio centrado en SKU con información basada en atributos | Conservar identificadores estables y distinguir datos de Product de datos del elemento hijo. |
| Familia de Product | Attribute set y tipo de Product | Organizar campos y funcionamiento de venta en lugar de copiar cada esquema de origen. |
| Variaciones | Relación padre-hijo u otra relación compatible de Product | Confirmar qué registro posee precio, stock, medios y valores seleccionables. |
| Información personalizada | Atributos de Product o datos propiedad de módulos | Mantener solo campos con propósito y responsable definidos en la tienda de destino. |
| Inventario | Estructuras de stock a nivel de Product y source según la implementación | Separar cantidades históricas del diseño actual de procesamiento. |
El sistema de atributos es una de las capacidades más fuertes de Magento Open Source y una de las razones por las que una mala clasificación del origen resulta costosa. Un catálogo poco gobernado puede entrar en Magento y quedar técnicamente estructurado pero comercialmente inconsistente si no se normalizan valores, propiedad de campos y familias de Product.
Categories, navegación y descubrimiento del catálogo
Las Categories de Magento forman una jerarquía que puede definir la navegación de la tienda. Products pueden asignarse a cero o más Categories y la estructura de Category raíz puede asociarse con el alcance de store. Por tanto, el árbol de Categories es a la vez una estructura de datos y una estructura de descubrimiento.
Las taxonomías de origen suelen mezclar significados diferentes: navegación para clientes, marcas, filtros, campañas, departamentos internos, páginas de destino o rutas SEO. Magento Open Source ofrece Categories, atributos, búsqueda, layered navigation, contenido CMS, menús y componentes de tema que pueden separar esas responsabilidades de forma más deliberada.
Una Category no debe conservarse solo porque exista en la plataforma de origen. Su propósito futuro debe estar claro:
- ¿crea un destino de navegación?
- ¿debe aparecer en la navegación principal?
- ¿es una clasificación temporal de campaña?
- ¿el mismo concepto se representa mejor como atributo o filtro?
- ¿necesita contenido de Category, metadatos, imagen o layout propio?
- ¿su URL anterior es lo bastante importante para requerir un destino mapeado?
Este panorama no sustituye los artículos posteriores de modelo de datos o preparación. Establece que el descubrimiento del catálogo en Magento es un sistema coordinado. Products, Categories, atributos, búsqueda, filtros, layout del tema y contenido contribuyen conjuntamente a que el cliente encuentre el artículo adecuado.
Websites, stores y store views
Magento Open Source utiliza una jerarquía de websites, stores y store views. Este modelo de alcance puede separar dominios, catálogos, monedas, contextos del proceso de compra, Categories raíz, idiomas y valores de configuración. Es una parte fundamental de la plataforma, no un simple ajuste visual de idioma.
A alto nivel:
- un website puede definir una frontera comercial importante;
- un store puede organizar un catálogo alrededor de una Category raíz;
- un store view puede presentar una variación de la tienda, normalmente para idioma o contenido localizado.
La configuración y los valores de atributos pueden tener alcances diferentes. Un nombre de Product puede variar por store view mientras el SKU sigue siendo global. Un precio puede gobernarse en un alcance más amplio que una descripción traducida. Categories y navegación también pueden variar según la estructura de store elegida.
Esta jerarquía importa porque una implementación multitienda de origen puede no mapearse uno a uno. Dominios de origen separados podrían convertirse en websites, stores o store views de Magento según catálogo, Customers, moneda, impuestos, proceso de compra y requisitos operativos. A la inversa, varias tiendas de origen pueden consolidarse cuando sus diferencias dejan de ser útiles.
El punto clave es que la arquitectura de alcance de Magento influye en el significado y visibilidad de los registros migrados. No es solo una preferencia de presentación del destino.
Customers, Orders e historial transaccional
Magento Open Source gestiona cuentas de Customer, direcciones, grupos de Customer, Orders, invoices, shipments, credit memos, descuentos, contexto fiscal y registros relacionados. Estas estructuras sostienen tanto la administración diaria como la continuidad histórica de servicio.
Un Customer migrado debe seguir siendo reconocible y útil, pero la continuidad de cuenta va más allá de nombre y correo. Estructuras de dirección, grupos de Customer, tratamiento fiscal, estado de newsletter, atributos personalizados e identificadores de sistemas externos pueden afectar operaciones. La compatibilidad de contraseñas depende del método de migración compatible y no debe suponerse.
Un Order migrado debe conservar suficiente contexto para que el personal entienda la transacción. Líneas, SKU, nombres de Product, cantidades, opciones seleccionadas, precios, descuentos, impuestos, envío, totales, estado, direcciones, referencias de pago, invoices, shipments y reembolsos pueden contribuir a ese significado cuando sean compatibles.
Los datos históricos no configuran el funcionamiento futuro. El nombre de un método de envío anterior no despliega una integración con transportista. Una referencia de pago no configura una pasarela. Los importes fiscales históricos no establecen reglas fiscales actuales. El funcionamiento futuro del proceso de compra y procesamiento en Magento depende de configuración del destino, módulos, credenciales e integraciones.
Contenido, temas y presentación de la tienda
Magento Open Source incluye CMS Pages, bloques de contenido, widgets, medios, contenido de Product y Category y renderizado de tienda dirigido por temas. Estos elementos permiten combinar datos de comercio con contenido editorial, promocional y de navegación.
La capa de presentación puede utilizar layouts, plantillas, bloques, configuración del tema y extensiones. Un atributo migrado puede existir en la base de datos y seguir invisible porque el tema no lo renderiza. Una CMS Page puede estar presente pero desconectada de la navegación. Una imagen de Product puede transferirse mientras cambia el funcionamiento de imágenes responsive o de la galería.
Por tanto, la continuidad de la tienda depende de la relación entre:
- registros y medios migrados;
- configuración y alcance de Magento;
- plantillas de tema y decisiones de layout;
- CMS Pages y bloques de contenido;
- búsqueda, navegación, filtrado y funcionamiento de URL.
Las URL, rewrites, rutas de Category, claves de Product y destinos de contenido de Magento pueden diferir de la plataforma de origen. La continuidad SEO debe basarse en destinos válidos de Magento y rutas de origen de alto valor, no en el supuesto de que cada URL heredada pueda recrearse exactamente.
Módulos, personalizaciones e integraciones
Magento Open Source dispone de un gran ecosistema de módulos e integraciones. Las extensiones pueden añadir pagos, envíos, búsqueda, merchandising, suscripciones, marketplaces, constructores de Products, campos de Customer, atributos de Order, generación de informes, procesamiento o flujos administrativos. Los módulos personalizados también pueden cambiar funcionamiento central o crear estructuras de datos completamente nuevas.
Esta extensibilidad es central para la plataforma, pero también una fuente importante de propiedad oculta. Un campo puede almacenarse como atributo de Magento, en una tabla personalizada, mediante una entidad de extensión o en un sistema externo. Un flujo puede imponerse mediante código en lugar de representarse directamente en registros migrados.
Una tienda de destino bien gobernada distingue:
- registros centrales de Magento Open Source;
- configuración estándar del destino;
- datos propiedad de extensiones;
- datos y lógica de módulos personalizados;
- presentación específica del tema;
- propiedad de sistemas externos.
La distinción es especialmente importante para identificadores. Products, Customers y Orders pueden llevar IDs de ERP, claves PIM, referencias de marketplace o códigos de procesamiento. Esos identificadores solo tienen valor si la integración correspondiente los utiliza y mantiene después del lanzamiento.
Magento Open Source y Adobe Commerce
Magento Open Source y Adobe Commerce comparten origen, pero sus fronteras de producto deben permanecer explícitas. Magento Open Source proporciona el núcleo de código abierto y capacidades básicas de comercio. Adobe Commerce añade capacidades propietarias y servicios comerciales que no deben atribuirse automáticamente a Magento Open Source.
Esta frontera afecta las expectativas de migración. Una tienda de origen puede usar capacidades B2B, merchandising, contenido, segmentación, operación o cloud asociadas a Adobe Commerce o extensiones de terceros. La plataforma de destino debe evaluarse según la implementación real de Magento Open Source y los módulos elegidos, no según una lista combinada de funciones de toda la familia Adobe Commerce.
La misma disciplina aplica a los datos de origen. Un campo procedente de una función de Adobe Commerce puede necesitar otro destino, una extensión o tratamiento no estándar en Magento Open Source. Compartir conceptos de base de datos no garantiza funcionamiento empresarial equivalente.
Qué hace distinta una migración hacia Magento Open Source
Magento Open Source se distingue por combinar un modelo de datos de comercio muy estructurado con infraestructura y código bajo control del comerciante. Cuatro características definen su identidad de migración:
- Los atributos y tipos de Product determinan el significado del catálogo. La tienda de destino necesita una arquitectura gobernada de Product, no solo filas importadas.
- El alcance de website, store y store view afecta visibilidad y configuración. Los datos multitienda deben interpretarse mediante la jerarquía de Magento.
- Extensiones y módulos personalizados pueden ser propietarios de datos y funcionamiento críticos. Los registros centrales no revelan todas las dependencias.
- Infraestructura y despliegue forman parte del modelo operativo. Búsqueda, indexación, caché, colas, medios, rendimiento, seguridad y gestión de releases afectan si los datos migrados son utilizables.
Magento Open Source puede sostener tiendas sofisticadas, pero su flexibilidad depende de gobierno técnico. La plataforma funciona mejor cuando estructura de datos, alcance de configuración, módulos, temas, integraciones e infraestructura se diseñan como una sola arquitectura de tienda de destino.
Conclusión
Magento Open Source es una plataforma de comercio autohospedada y de código abierto construida alrededor de Products estructurados, atributos, attribute sets, Categories, alcance de tienda, Customers, Orders, contenido, módulos, temas e integraciones. Su modelo operativo da al comerciante control directo y también le asigna responsabilidad sobre infraestructura, despliegue, seguridad, compatibilidad de extensiones y mantenimiento continuo.
Una migración hacia Magento Open Source debe conservar datos empresariales compatibles sin confundir esos datos con configuración de tienda, código, presentación o infraestructura. Este panorama establece la arquitectura necesaria para los artículos posteriores del hub sobre encaje, representación del modelo de datos, riesgos, preparación, selección del enfoque de migración, validación y problemas recurrentes.
Preguntas frecuentes
¿Magento Open Source es lo mismo que Adobe Commerce?
No. Comparten linaje de plataforma y muchos conceptos centrales, pero Adobe Commerce incluye capacidades propietarias y servicios comerciales que no forman parte automáticamente de Magento Open Source.
¿Por qué son tan importantes los atributos en Magento Open Source?
Los atributos definen información estructurada de Product y pueden sostener administración, presentación en tienda, búsqueda, filtrado, comparación e integraciones. Una mala gobernanza de atributos puede hacer difícil mantener el catálogo incluso si todos los Products están presentes.
¿Cada categoría de origen debe convertirse en una Category de Magento?
No. Las clasificaciones de origen pueden representar navegación, filtros, marcas, campañas u organización interna. Las Categories de Magento deben usarse cuando aportan una estructura significativa de navegación o contenido.
¿Qué diferencia hay entre websites, stores y store views?
Son niveles de la jerarquía de alcance de Magento. Websites pueden definir fronteras comerciales importantes, stores pueden organizar catálogos alrededor de Categories raíz y store views pueden presentar contenido localizado o alternativo.
¿El historial de Orders migrado configura pagos y envíos futuros?
No. Orders históricos pueden conservar contexto de transacciones, mientras pasarelas activas, integraciones de envío, impuestos, proceso de compra y procesamiento requieren configuración y pruebas en el destino.
¿Los registros de extensiones y módulos personalizados forman parte automáticamente de los datos estándar de Magento?
No. Las extensiones y módulos personalizados pueden crear atributos, tablas, entidades y flujos fuera de las estructuras centrales. Sus datos deben identificarse por propósito, destino y responsable a largo plazo.