Una migración hacia Magento Open Source puede parecer correcta antes de ser coherente desde el punto de vista operativo. Products, Customers, Orders y Categories pueden aparecer en Admin mientras siguen incompletas las relaciones con hijos configurables, el alcance de atributos, las asignaciones a websites, las relaciones de stock, las reescrituras de URL, los registros de extensiones o los índices.
El patrón recurrente consiste en una transferencia que conserva campos visibles pero pierde las estructuras que Magento Open Source utiliza para construir el catálogo, el escaparate y el significado histórico de las operaciones. Cada problema siguiente identifica el patrón de fallo, las señales que lo revelan y la condición que demuestra que la relación se ha restaurado.
Problema 1: convertir todos los Products en Products simples
Qué sale mal
Magento Open Source admite Products simples, configurables, grouped, virtuales, bundle y descargables. Estos tipos utilizan relaciones distintas de padre-hijo, precio, stock, archivos y carrito. Aplanarlos como Products simples duplica contenido de merchandising, elimina combinaciones seleccionables y cambia la forma en que las Orders identifican los artículos comprados.
Señales tempranas
| Señal temprana | Qué indica |
|---|---|
| Los SKU padre e hijos no aparecen por separado. | La identidad de Products configurables y compuestos está incompleta. |
| Los componentes de bundle o grouped Products aparecen solo en descripciones. | Las relaciones vendibles se han reducido a contenido. |
| Los archivos descargables y límites de acceso están fuera de la exportación del Product. | El Product descargable no puede funcionar únicamente con el registro del Product. |
| Las opciones configurables se mezclan con opciones personalizadas ordinarias. | Se están confundiendo variantes con inventario y elecciones introducidas por el Customer. |
Prevención
Clasifique los Products de origen según su funcionamiento comercial antes de asignar campos. Conserve vínculos con hijos configurables, asociaciones grouped, opciones de bundle, significado virtual, archivos descargables y el SKU exacto que posee inventario y aparece en las líneas de Order.
Ejemplo de recomendación
Utilice como estructuras de referencia un Product configurable, un grouped Product, un bundle dinámico y un Product descargable. Registre qué entidad es propietaria del precio, stock, peso, medios y procesamiento de pedidos.
Condición de aprobación
Cada Product de referencia conserva su tipo correcto, vínculos padre-hijo o de componentes, valores seleccionables, identidad de SKU, fuente del precio, comportamiento de inventario, archivos y significado histórico de las líneas de Order.
Problema 2: recrear atributos sin conservar sus conjuntos y alcance
Qué sale mal
Los atributos de Magento adquieren significado mediante tipo de entrada, vocabulario de opciones, conjunto de atributos, ubicación en grupos, flags del escaparate, búsqueda y filtros, estado obligatorio y alcance. Copiar únicamente códigos y valores de atributos puede producir opciones duplicadas, filtros vacíos, formularios administrativos incorrectos o valores que se sobrescriben entre websites y store views.
Señales tempranas
| Señal temprana | Qué indica |
|---|---|
| Campos similares utilizan códigos o etiquetas de opciones inconsistentes. | La identidad de atributos se fragmentará entre Products. |
| Falta la pertenencia a conjuntos de atributos en el inventario de origen. | Los campos no podrán asignarse a las familias correctas de Products. |
| Valores globales, por website y por store view están mezclados en una columna. | El significado específico del alcance será sobrescrito. |
| El origen utiliza atributos creados por extensiones cuyo funcionamiento se desconoce. | El campo puede depender de código, indexación o lógica de escaparate además del valor. |
Prevención
Conserve la definición del atributo antes de importar valores. Asigne tipo de entrada, IDs o etiquetas de opciones, conjunto de atributos, grupo, alcance, uso en búsqueda y filtros, comparación, visibilidad y estado obligatorio. Fusione sinónimos únicamente cuando representen el mismo vocabulario gobernado.
Ejemplo de recomendación
Utilice color como atributo de variante, material como especificación filtrable e instrucciones de cuidado como contenido por store view. Represente cada uno mediante el conjunto, grupo, alcance y funcionamiento de escaparate correctos.
Condición de aprobación
Los atributos de referencia aparecen en los conjuntos y grupos previstos, conservan opciones y alcance normalizados y sostienen correctamente variantes, filtros, búsqueda, comparación y edición administrativa.
Problema 3: confundir opciones personalizadas con variantes configurables
Qué sale mal
Las opciones personalizadas pueden recoger una elección o dato introducido por el comprador sin crear un Product separado. Los Products configurables dependen de Products simples asociados con SKU e inventario independientes. Convertir variantes de origen con stock en opciones personalizadas elimina la identidad de los hijos; convertir personalizaciones en hijos configurables crea unidades de inventario falsas.
Señales tempranas
- Una elección tiene stock o SKU independiente pero se propone como opción de texto o dropdown.
- Un grabado o una carga de archivo se propone como atributo configurable.
- Las variantes de origen tienen imágenes o precios propios que quedan vinculados solo al padre.
- Las líneas de Order no pueden identificar el SKU hijo comprado.
Prevención
Clasifique cada elección según si crea una unidad vendible administrada de forma independiente. Utilice hijos configurables para variantes con SKU e inventario propios; mantenga opciones personalizadas para elecciones sin inventario y entradas del comprador. Conserve el valor seleccionado en las líneas de Orders históricas.
Ejemplo de recomendación
Represente talla y color de una camiseta como atributos configurables, el envoltorio de regalo como opción personalizada con precio y el grabado como texto introducido por el comprador.
Condición de aprobación
Las variantes reales conservan SKU hijo, precio, stock, medios e identidad en líneas de Order, mientras las personalizaciones y servicios opcionales permanecen vinculados al Product padre y a la línea comprada sin generar variantes falsas.
Problema 4: aplanar la jerarquía de Magento en un único contexto
Qué sale mal
Magento Open Source utiliza websites, stores y store views para controlar asignación de catálogo, root Categories, valores localizados, URLs, monedas y configuración. Una transferencia global puede sobrescribir traducciones, publicar Products en el website equivocado o asignar la root Category incorrecta.
Señales tempranas
| Señal temprana | Qué indica |
|---|---|
| El origen tiene varios dominios, idiomas, marcas o regiones. | Un único alcance predeterminado no puede representar la arquitectura de la Store. |
| Descripciones de Products y claves de URL cambian según el escaparate. | El contenido por store view y el significado SEO necesitan propiedad independiente. |
| Stores distintas utilizan root Categories o selecciones de Products diferentes. | La navegación y el surtido dependen del alcance. |
| Existen precios o Customer Groups específicos por website. | Las reglas comerciales están vinculadas al contexto del website. |
Prevención
Cree un mapa de alcance para cada website, store y store view. Separe la identidad global del Product de sus asignaciones a websites y del texto por store view. Conserve códigos de alcance utilizados por importaciones, APIs o correspondencias de integraciones.
Ejemplo de recomendación
Utilice un Product vendido en dos websites con descripciones, claves de URL y ubicación en Categories diferentes por store view. Registre explícitamente cada valor con alcance.
Condición de aprobación
El Product representativo aparece solo en los websites y stores previstos, utiliza las root Categories y valores localizados correctos y no hereda contenido ni rutas de la store view equivocada.
Problema 5: asumir que las filas de Categories recrean navegación e historial de URLs
Qué sale mal
Los registros de Category por sí solos no recrean la ruta del escaparate. La asignación de root Category, jerarquía padre-hijo, pertenencia de Products, visibilidad, inclusión en menú, claves de URL, metadatos, contenido CMS y reescrituras determinan si una Category sostiene descubrimiento y continuidad.
Señales tempranas
- Las Categories existen en Admin pero no aparecen en el menú.
- Los Products están asignados a ramas inesperadas.
- Las Categories de origen tienen varias URLs históricas.
- El contenido de páginas de destino o los enlaces internos se almacenan por separado.
Prevención
Conserve jerarquía de Categories y pertenencia de Products por separado del comportamiento del menú y las rutas. Asigne root Categories por store, identifique Categories ocultas o de página de destino, conserve metadatos y descripciones y cree relaciones explícitas de reescritura para rutas críticas para el negocio.
Ejemplo de recomendación
Utilice una Category principal de menú, una Category oculta de página de destino y una Category que haya cambiado de posición en la jerarquía. Conserve pertenencia de Products, ruta de destino y redirecciones de origen para cada una.
Condición de aprobación
Las Categories de referencia aparecen en la jerarquía de store prevista, contienen Products y contenido correctos y resuelven todas las rutas importantes del origen hacia el destino adecuado sin rutas duplicadas o no deseadas.
Problema 6: copiar stock sin contexto de source, stock y disponibilidad vendible
Qué sale mal
El inventario de Magento Open Source puede utilizar sources físicas, stocks, asignaciones de canal por website, cantidades por source y disponibilidad vendible. Una cantidad positiva puede producir un Product no disponible si la asignación de source, stock, estado, reservas o disponibilidad de hijos es incorrecta.
Señales tempranas
- Varios almacenes se suman en una única cantidad.
- Los Products importados siguen asignados únicamente a Default Source.
- Padres e hijos configurables muestran disponibilidad contradictoria.
- Un ERP o sistema de almacén continúa siendo autoritativo pero faltan sus claves de artículo.
Prevención
Conserve códigos source, cantidades, estado, asignaciones de stock, relaciones con websites e identificadores externos de almacén. Defina si Magento u otro sistema será propietario del inventario después de la migración. Mantenga separada la cantidad física de la cantidad disponible para un canal de venta.
Ejemplo de recomendación
Utilice un SKU con stock en dos almacenes y un Product configurable con disponibilidad diferente entre sus hijos. Asigne cada source al stock que sirve al website correcto.
Condición de aprobación
Los Products representativos conservan cantidades correctas por source, asignaciones de stock y website, disponibilidad de hijos y claves externas de inventario, produciendo el estado vendible previsto sin aplanar las ubicaciones.
Problema 7: importar Customers y Orders sin sus instantáneas operativas
Qué sale mal
Los registros de Customers y Orders pueden existir mientras direcciones, Customer Groups, selecciones de Products, descuentos, impuestos, envíos, referencias de pago, facturas, shipments, reembolsos e historial de estados pierden su significado original. Actualizar un Customer también puede sobrescribir información que debería permanecer congelada dentro de una Order histórica.
Señales tempranas
- Las direcciones de Order se derivan de la libreta actual del Customer.
- Las líneas configurables, bundle o grouped pierden los detalles del hijo.
- Reembolsos o shipments se exportan por separado sin vínculos con la Order.
- Existen nombres de Customer Groups sin su contexto histórico de precios.
Prevención
Mantenga los datos maestros del Customer separados de las instantáneas correspondientes al momento de la Order. Conserve SKU de línea, opciones seleccionadas, direcciones, totales, descuentos, impuestos, etiquetas de métodos, historial de estados, facturas, shipments, reembolsos, comentarios e IDs externos de transacción.
Ejemplo de recomendación
Utilice una Order de invitado, una Order de Customer registrado, una Order parcialmente enviada y una Order reembolsada que contenga un Product configurable.
Condición de aprobación
Cada Order representativa sigue siendo comprensible sin depender de la configuración actual de Product, Customer, precio, pago o envío, y cada shipment, factura, reembolso e identificador externo relacionado permanece vinculado.
Problema 8: tratar contenido CMS, medios y campos SEO como una única exportación genérica de páginas
Qué sale mal
El contenido de Magento Open Source puede incluir CMS Pages, CMS Blocks, widgets, descripciones de Products y Categories, archivos de medios, metadatos, enlaces internos y rutas específicas de store view. Una importación genérica de páginas puede conservar texto mientras pierde referencias a blocks, directivas de widgets, rutas de medios, alcance o reescrituras de URL.
Señales tempranas
- El contenido CMS contiene directivas, widgets o URLs de medios de origen.
- Los blocks se reutilizan en varias Pages o store views.
- Las descripciones de Products y Categories contienen enlaces internos codificados directamente.
- Los metacampos y claves de URL difieren según el alcance.
Prevención
Clasifique por separado CMS Pages, blocks, widgets, contenido de catálogo, medios, metadatos e historial de reescrituras. Actualice referencias hacia IDs de entidades y medios del destino, conserve el alcance por store view y evite trasladar marcado obsoleto del tema como si fuera contenido comercial.
Ejemplo de recomendación
Utilice una CMS Page que contenga un block reutilizable y una imagen, junto con una página de destino de Category con metadatos localizados y una URL antigua.
Condición de aprobación
El contenido representativo se renderiza mediante las relaciones correctas de Page, block, widget, medios y store view, mientras los enlaces internos y rutas heredadas importantes alcanzan el destino previsto.
Problema 9: copiar tablas de extensiones sin reconstruir su propiedad comercial
Qué sale mal
Las Stores Magento Open Source suelen contener extensiones y módulos personalizados para ERP, PIM, fidelización, suscripciones, marketplaces, fiscalidad, envíos, búsqueda, proceso de compra e informes. Sus tablas y atributos pueden depender de código, eventos, cron jobs, APIs o taxonomías externas. Mover únicamente filas crea valores huérfanos.
Señales tempranas
- Campos importantes utilizan prefijos de módulo o IDs de entidades personalizadas.
- El personal no puede identificar qué sistema actualiza un campo.
- Los sistemas externos utilizan claves ausentes de las entidades estándar de Magento.
- Los flujos de origen dependen de procesos programados u observers.
Prevención
Cree un registro de propiedad para cada entidad y campo personalizado. Indique el Product, Customer, Order o registro de contenido padre; el módulo o propietario externo; la clave duradera; la dirección de actualización; y el flujo de destino. Excluya residuos técnicos abandonados.
Ejemplo de recomendación
Siga un ID de Product procedente del PIM, una cuenta de fidelización y una referencia de Order de marketplace desde la tabla de origen hasta el propietario de destino y la integración que continuará utilizándolos.
Condición de aprobación
Cada registro personalizado conservado tiene propietario conocido, relación padre válida, identificador estable y flujo de trabajo vigente; ningún proceso crítico del negocio depende de datos copiados que el destino no puede interpretar.
Problema 10: asumir que los datos importados están listos para el escaparate antes de que índices y cachés los reflejen
Qué sale mal
Magento Open Source utiliza índices para preparar datos de catálogo, precios, Categories, Customer Groups y búsqueda para un uso eficiente en el escaparate. Las cachés sirven configuración procesada, layout, blocks y páginas. Importaciones grandes o cambios directos en base de datos pueden dejar índices inválidos o actualizaciones programadas incompletas, haciendo que los valores de Admin difieran de búsqueda, filtros, precios o listados de Categories.
Señales tempranas
| Señal temprana | Qué indica |
|---|---|
| Los Products existen en Admin pero faltan en búsqueda o Categories. | Los datos están presentes, pero la visibilidad de escaparate basada en índices está obsoleta o incompleta. |
| Cambios de precio o Customer Group aparecen de forma inconsistente. | Los índices relacionados con precios todavía no reflejan el estado importado. |
| Los indexers muestran estados de reindexado requerido, suspendido o retrasado. | Los resultados del escaparate no pueden considerarse actuales. |
| Persisten avisos de caché después de cambios en catálogo o extensiones. | Los Customers pueden seguir recibiendo una versión renderizada anterior. |
Prevención
Incluya la propiedad de índices y cachés en el runbook de migración. Asegure la disponibilidad de cron e indexers programados, documente qué importaciones disparan reindexación parcial o completa y separe reindexación de actualización de caché. Los procesos de importación personalizados deberían utilizar operaciones compatibles sobre entidades o contabilizar explícitamente sus efectos de indexación.
Ejemplo de recomendación
Después de una importación masiva representativa del catálogo, siga un Product desde Admin hasta listado de Category, búsqueda, resultados de filtros y precios por Customer Group mientras observa el estado de los índices relacionados.
Condición de aprobación
Todos los indexers necesarios alcanzan un estado actual, las cachés previstas contienen salida vigente y Products, Categories, precios y atributos buscables representativos aparecen de forma consistente en Admin y escaparate.
Prioridades de prevención comunes a todos los problemas
La prevención de fallos en Magento Open Source depende de conservar cuatro estructuras conectadas: relaciones de Products, datos de catálogo con alcance, instantáneas comerciales históricas y propiedad de extensiones. Después, la indexación y las cachés determinan si esos registros correctos se vuelven visibles en el escaparate.
| Capa de prevención | Control requerido |
|---|---|
| Estructura de Product | Conservar distinciones padre-hijo, grouped, bundle, downloadable y opciones personalizadas. |
| Gobernanza de atributos | Mantener conectados código de atributo, opciones, pertenencia a conjuntos, alcance y uso en escaparate. |
| Alcance de Store | Mantener diferencias de website, store y store view para contenido, precios, Categories y URLs. |
| Instantáneas históricas | Conservar contexto de Customer, Product, dirección, estado, shipment y reembolso correspondiente al momento de la Order. |
| Visibilidad del escaparate | Tratar índices y cachés como la capa de entrega de registros que, por lo demás, son correctos. |
Conclusión
Los fallos en migraciones hacia Magento Open Source rara vez se explican únicamente por conteos faltantes de Products o Customers. El problema más habitual es que tipos de Product, atributos, alcance, inventario, Categories, contenido, Orders y registros de extensiones dejan de funcionar juntos.
El modelo de destino más seguro conserva cada relación en el nivel correcto y mantiene la evidencia histórica separada de la configuración actual. Cuando catálogo, alcance, inventario, Orders, rutas, registros personalizados e índices son coherentes entre sí, la Store migrada resulta operativamente sólida en lugar de estar simplemente poblada de datos.
Preguntas frecuentes
¿Por qué deben conservarse los tipos de Product de Magento Open Source en lugar de aplanarlos?
Cada tipo de Product define relaciones diferentes de padre-hijo, precio, stock, archivos y carrito. Aplanarlos cambia lo que selecciona el comprador y lo que el personal puede administrar o rastrear dentro de las Orders.
¿Cuál es la diferencia práctica entre atributos configurables y opciones personalizadas?
Los atributos configurables seleccionan Products hijos independientes con sus propios SKU e inventario. Las opciones personalizadas modifican o personalizan el Product padre sin crear unidades de stock administradas de forma independiente.
¿Por qué importa el alcance de atributos durante la migración?
El alcance global, por website y por store view determina si un valor se comparte o se localiza. Utilizar un alcance incorrecto puede sobrescribir traducciones, precios, metadatos y otros valores específicos de cada escaparate.
¿La cantidad importada por sí sola demuestra que un Product de Magento está disponible?
No. La disponibilidad puede depender de la asignación a source, asignación de stock, estado, relación con website, reservas y estado de Products hijos además de la cantidad.
¿Los datos antiguos de extensiones deben copiarse siempre a atributos personalizados?
No. Los registros de extensiones pueden depender de entidades separadas, flujos, código, sistemas externos o taxonomías. Solo deben conservarse los datos con un propietario de destino definido y un uso que continuará vigente.
¿Por qué pueden aparecer Products en Admin y seguir ausentes del escaparate?
Magento utiliza índices y cachés para preparar la salida de catálogo, precios, Categories y búsqueda. Índices inválidos o retrasados, procesamiento cron incompleto o cachés obsoletas pueden hacer que registros correctos en base de datos parezcan ausentes o inconsistentes.