Si Magento Open Source ha sido seleccionado como la plataforma de destino, la preparación debe convertir la tienda de origen en un modelo documentado de catálogo, Customers, Orders, contenido, inventario, extensiones e integraciones antes de ejecutar cualquier migración. La flexibilidad de Magento aumenta la necesidad de distinguir tipos de Product, SKU hijos configurables, opciones personalizadas, atributos, conjuntos de atributos, store views, sources de inventario, Orders históricas, datos propiedad de extensiones e identificadores externos.
Para cada área de preparación, defina la acción, el propietario, la evidencia y la condición de preparación. Así, la migración representativa se convierte en una muestra controlada de la arquitectura de Magento que se pretende construir, en lugar de ser el primer intento de descubrir cómo funciona la tienda de origen.
Definir la estructura de destino en Magento Open Source
Prepare un mapa conciso de la estructura de destino que cubra websites, stores, store views, idiomas, monedas, propiedad del catálogo, Customer Groups, inventario, contenido e integraciones.
| Área de preparación | Decisión que debe registrarse | Propietario | Evidencia de preparación |
|---|---|---|---|
| Alcance de website y store view | Qué marcas, regiones, idiomas, monedas, dominios y valores localizados necesitan un alcance separado | Responsable de comercio | Matriz website/store/store view |
| Arquitectura de Product | Qué registros de origen se convierten en Products simples, configurables, grouped, bundle, virtuales o descargables | Responsable de catálogo | Clasificación por familias de Products |
| Gobernanza de atributos | Qué campos se convierten en atributos, conjuntos de atributos, opciones personalizadas, contenido o datos externos | Responsables de catálogo y técnicos | Diccionario de atributos y valores de ejemplo |
| Propiedad del inventario | Si Magento, ERP, WMS, proveedor o marketplace mantiene la autoridad del stock | Responsable de inventario | Mapa source/stock/sistema de registro |
| Historial de Customers y Orders | Qué Customer Groups, direcciones, estados, ajustes y referencias externas deben seguir siendo comprensibles | Operaciones y soporte | Paquete representativo de Customers y Orders |
| Límites de extensiones | Qué módulos y tablas personalizadas crean registros importantes | Responsable técnico | Registro de dependencias |
El mapa de destino debe establecer quién será propietario de cada elemento sin convertirse en una especificación completa de implementación de Magento.
Preparar accesos, copias de seguridad y evidencias de origen
Reúna:
- acceso administrativo a la tienda de origen y a Magento con el nivel de permisos necesario;
- copias de seguridad de base de datos y medios cuando estén disponibles;
- exportaciones o informes recientes de Products, Categories, Customers, Orders, cupones, reseñas, CMS Pages, Blog Posts y medios;
- listas de websites, stores, store views, idiomas, monedas y dominios;
- referencias de tipos de Product, atributos, conjuntos de atributos, opciones personalizadas y Categories;
- informes de inventory sources, stocks, almacenes y sistemas externos de inventario;
- ejemplos de Customer Groups, fiscalidad y estados de cuenta;
- inventarios de extensiones, módulos personalizados, cron jobs, APIs e integraciones;
- listas de reescrituras de URL, redirecciones, sitemaps y rutas de alto valor;
- capturas o informes que expliquen comportamientos poco habituales del origen.
| Evidencia | Por qué se necesita | Condición de preparación |
|---|---|---|
| Copia de seguridad de base de datos/medios | Conserva registros que no aparecen en exportaciones estándar | Fecha, ubicación y responsable de restauración documentados |
| Diccionario de atributos | Explica campos personalizados y diferencias entre clases de Product | Cada atributo importante tiene finalidad, tipo, alcance y valores de ejemplo |
| Inventario de extensiones | Identifica registros fuera del núcleo de Magento | Cada módulo crítico tiene propietario comercial y técnico |
| Inventario de URLs | Protege la continuidad de rutas | Las rutas prioritarias de Products, Categories y contenido tienen destinos previstos |
| Registro de IDs externos | Protege continuidad de integraciones | Las claves están asignadas al nivel correcto de Product, Customer, Order o inventario |
Una exportación de extensión que falta, una carpeta de medios inaccesible o una tabla personalizada sin documentar debe permanecer visible como elemento pendiente de preparación.
Preparar tipos de Product y relaciones vendibles
Seleccione ejemplos de cada estructura de Product que afecte materialmente a la gestión del catálogo o al historial de Orders:
- Products simples;
- Products configurables con Products simples asociados;
- grouped Products;
- bundle Products;
- Products virtuales y descargables;
- Products con opciones personalizadas;
- Products presentes en varios websites o con valores por store view;
- Products con campos propiedad de extensiones, tablas personalizadas o IDs externos.
| Funcionamiento de origen | Decisión de preparación en Magento | Evidencia requerida |
|---|---|---|
| Una elección crea un SKU o registro de stock independiente | Definir Product configurable padre y Products simples asociados | IDs padre/hijo, SKUs, atributos, stock, precios e imágenes |
| Products presentados juntos pero vendidos de forma independiente | Definir relación de grouped Product | Miembros del grupo y cantidades |
| El Customer configura un conjunto | Definir componentes del bundle y reglas de selección | Products componentes, cantidades, precios y propietario del inventario |
| Un valor modifica un Product sin stock independiente | Definir opción personalizada u otro propietario | Tipo de opción, valores, efecto en precio y ejemplo de Order histórica |
| El Product es digital o no requiere envío | Definir estructura downloadable o virtual | Archivo, acceso, envío y contexto de Order |
| El origen duplica Products por región | Definir propiedad por website/store view o Products separados deliberadamente | Ejemplos de contenido regional, precio, URL e identificadores |
Normalice SKUs duplicados, Products hijos huérfanos, etiquetas de opciones inconsistentes, vínculos padre ausentes, Products obsoletos y combinaciones no compatibles antes de cerrar la asignación.
Limpiar atributos y conjuntos de atributos
Los atributos de Magento pueden afectar a edición, filtrado, búsqueda, comparación, creación de Products y contenido por store view. Prepare un inventario gobernado de campos en lugar de copiar cada campo de origen dentro de un único conjunto de atributos sobredimensionado.
Para cada campo, documente:
- finalidad comercial;
- tipo de datos y valores permitidos;
- clases de Product que lo utilizan;
- alcance global, por website o por store view;
- si el Customer lo selecciona;
- si búsqueda, filtrado, comparación o integración dependen de él;
- si contiene el identificador de otro registro;
- si debe conservarse, normalizarse, fusionarse o excluirse.
| Patrón de campo | Propietario previsto en Magento | Evidencia de preparación |
|---|---|---|
| Valor que define una variante | Atributo configurable y Products simples asociados | Valores controlados y ejemplos de familias de Products |
| Especificación técnica | Atributo de Product asignado mediante conjunto de atributos | Tipo, alcance, valores permitidos y finalidad de visualización/búsqueda |
| Valor introducido por el Customer | Opción personalizada, extensión o propietario de línea de Order | Ejemplo de escaparate y de Order histórica |
| Valor utilizado solo por integraciones | Atributo de Product o SKU hijo utilizado por un sistema externo | Propietario externo y regla de unicidad |
| Solución heredada del origen | Atributo de destino normalizado, contenido, extensión o exclusión | Registro de decisión que explique la finalidad futura |
La condición de preparación es que cada clase principal de Product tenga un conjunto de atributos aprobado y que ningún campo importante permanezca sin definir o asignado a varios propietarios incompatibles.
Preparar Categories, contenido, URLs y valores por store view
Prepare un inventario de rutas y contenido que cubra:
- jerarquía de Categories y pertenencia de Products;
- Categories utilizadas solo para organización interna o campañas;
- claves de URL de Products y Categories;
- CMS Pages, CMS Blocks, contenido gestionado por Page Builder o por el tema;
- Blog Posts y contenido propiedad de extensiones;
- valores localizados de Products, Categories y CMS;
- backlinks de alto valor, rutas de campañas pagadas, páginas de políticas y páginas de destino;
- reescrituras de URL, redirecciones y enlaces internos.
| Registro de origen | Pregunta de preparación | Evidencia de preparación |
|---|---|---|
| Category | ¿Es estructura duradera de catálogo, navegación, agrupación de campaña o clasificación interna? | Decisión sobre Category y muestra de pertenencia de Products |
| Product o página localizada | ¿Qué store view es propietaria de cada valor? | Matriz de valores por store view |
| CMS Page/block | ¿Es contenido reutilizable, contenido de página o presentación del tema? | Inventario de contenido y propietario de destino |
| Blog Post | ¿Qué extensión o sistema de contenido será su propietario? | Lista de posts, medios, URLs y propietario de destino |
| URL heredada | ¿Qué Product, Category o registro de contenido de destino debe recibir la redirección? | Registro de rutas origen/destino |
Esta área está preparada cuando cada ruta pública prioritaria tiene un destino o una decisión de retirada y cada valor localizado tiene un propietario de store view asignado.
Preparar Customer Groups, Customers y Orders históricas
La preparación de Customers debe cubrir Customers registrados, invitados, varias direcciones, Customer Groups, tratamiento fiscal, estado de cuenta, identidades duplicadas, campos personalizados y claves externas de CRM o ERP.
Para Orders, seleccione ejemplos que incluyan:
- Products configurables y opciones personalizadas;
- grouped o bundle Products;
- descuentos, cupones, impuestos, etiquetas de envío y pago;
- facturas, shipments, credit memos, cancelaciones y comentarios;
- referencias de marketplace, ERP, procesamiento de pedidos, contabilidad o CRM;
- cada website, moneda o Customer Group importante.
| Elemento de preparación | Propietario | Evidencia requerida | Condición de preparación |
|---|---|---|---|
| Identidad del Customer | Operaciones de Customers | Muestras de duplicados, invitados, direcciones e IDs externos | Las reglas para fusionar o mantener separados están documentadas |
| Customer Groups | Responsable comercial | Lista de grupos y finalidad relacionada con precios/fiscalidad/acceso | Cada grupo mantiene un significado comercial vigente |
| Orders históricas | Soporte y finanzas | Paquete representativo de Orders | Líneas, totales, estados, procesamiento de pedidos, reembolsos y referencias están explicados |
| Datos sensibles | Responsable legal/datos | Lista de campos aprobada | Los datos personales innecesarios o no compatibles están excluidos |
No utilice los Customer Groups actuales ni los precios actuales de Products para reinterpretar Orders históricas. El registro de Order debe conservar su propia evidencia correspondiente al momento de la transacción.
Preparar la propiedad del inventario y del procesamiento de pedidos
El inventario de Magento puede implicar sources, stocks, asignaciones a websites, cantidades por source, cantidad disponible para vender, reservas, backorders, puntos de recogida, drop shippers y sistemas externos de inventario.
Prepare ejemplos de:
- SKU simples e hijos configurables;
- Products con una source y con múltiples sources;
- registros con backorder, stock bajo, agotados o similares a preorder;
- ubicaciones de almacén, tienda, proveedor y drop ship;
- Products sincronizados con ERP, WMS, marketplace o sistemas de procesamiento de pedidos;
- stock que deba refrescarse cerca de la ventana de migración.
| Pregunta de inventario | Evidencia | Condición de preparación |
|---|---|---|
| ¿Qué sistema es propietario de la cantidad? | Mapa del sistema de registro | Cada SKU prioritario tiene una autoridad de inventario declarada |
| ¿Qué ubicación de origen corresponde a qué Magento source? | Matriz de ubicaciones | Los códigos source de origen y destino están documentados |
| ¿Qué websites utilizan cada stock? | Relación website/stock | La propiedad por canal de venta está definida |
| ¿Qué nivel de Product posee el inventario? | Ejemplos de SKU padre/hijo | Las responsabilidades del padre configurable y sus hijos están claras |
| ¿Qué valores son instantáneas iniciales? | Informe de stock con fecha | La fecha de la instantánea y el responsable de actualización están registrados |
El inventario está preparado cuando cantidad, ubicación, nivel de Product, relación con website y propiedad del sistema externo son explícitos.
Inventariar extensiones, módulos personalizados y sistemas externos
Cree un registro de dependencias para cada extensión, módulo personalizado, tabla modificada, API, proceso programado y sistema externo que cambie el funcionamiento de Products, Customers, Orders, inventario, contenido o URLs.
Registre:
- nombre del módulo o sistema;
- finalidad comercial;
- registros principales que amplía;
- campos, tablas, estados o IDs personalizados que crea;
- disponibilidad de exportación o API;
- propietario comercial y técnico;
- propietario o sustituto que continuará en el destino;
- datos que deben archivarse o excluirse.
Las dependencias prioritarias incluyen búsqueda, reseñas, fidelización, suscripciones, pagos, fiscalidad, envíos, marketplaces, ERP, PIM, WMS, CRM, contabilidad, consentimiento, analítica y lógica personalizada del proceso de compra o procesamiento de pedidos.
El registro está preparado cuando cada dependencia importante tiene un propietario de destino y una clave estable. No describa registros de extensiones como campos ordinarios de Magento salvo que el núcleo de la plataforma sea realmente su propietario.
Seleccionar muestras representativas para la migración de prueba
| Muestra | Finalidad de preparación |
|---|---|
| Familia de Product simple y configurable | Establecer tipo de Product, atributos, SKU hijos, medios e inventario |
| Grouped o bundle Product | Exponer relaciones de componentes y propiedad de precios |
| Product con opciones personalizadas | Exponer entradas puntuales del Customer y representación en Orders históricas |
| Product o Category localizada | Exponer alcance por website/store view, contenido y URLs |
| Customer con grupo e ID externo | Exponer identidad, segmentación y relaciones de integración |
| Order histórica compleja | Exponer opciones, totales, shipments, credit memos y referencias |
| SKU con inventario multisource | Exponer source, stock, website y propiedad externa del inventario |
| Registro propiedad de extensión | Exponer tablas personalizadas y decisiones de propietario de destino |
Para cada muestra, registre el ID de origen, URL de origen cuando corresponda, motivo comercial, propietario previsto en Magento, identificadores externos relacionados, exclusiones conocidas y revisor responsable. El registro de muestras está preparado cuando cada registro seleccionado tiene una expectativa trazable en origen y un revisor asignado.
Completar la puerta de preparación de Magento Open Source
| Pregunta de preparación | Evidencia requerida | Condición de preparación |
|---|---|---|
| ¿Son recuperables los accesos y archivos del origen? | Registro de acceso, copia de base de datos, copia de medios y exportaciones | Los registros necesarios pueden inspeccionarse independientemente de la tienda de origen activa |
| ¿Están definidas las familias de Products y conjuntos de atributos? | Matriz de Products y atributos | Cada patrón principal del catálogo tiene una estructura prevista en Magento |
| ¿Están asignados Categories, contenido y URLs? | Registro de contenido y rutas | Los registros prioritarios tienen destino o decisión de retirada |
| ¿Están documentados los significados de Customers y Orders? | Paquete de evidencia de Customers y Orders | Identidad, estados y relaciones históricas están explicados |
| ¿Es explícita la propiedad del inventario? | Mapa source/stock/sistema de registro | Cada SKU prioritario tiene una autoridad de cantidad declarada |
| ¿Están inventariados extensiones y sistemas externos? | Registro de dependencias | Cada dependencia crítica tiene propietario continuo |
| ¿Se han seleccionado muestras representativas de migración? | Registro de muestras | Se cubren estructuras ordinarias y excepcionales |
| ¿Están controlados los elementos sin resolver? | Registro de decisiones | Cada punto abierto tiene propietario y fecha límite |
La preparación está completa cuando ninguna decisión crítica sobre Products, atributos, Customers, Orders, inventario, URLs o extensiones depende de supuestos sin documentar.
Conclusión
La preparación de una migración hacia Magento Open Source debe producir un paquete de evidencias recuperable y específico de la plataforma. Tipos de Product, conjuntos de atributos, Categories, store views, inventory sources, Customer Groups, Orders históricas, extensiones, contenido, URLs e IDs externos necesitan propietarios explícitos.
Cuando estas decisiones se documentan antes de la migración representativa, las muestras pueden validar la arquitectura de Magento prevista en lugar de obligar al equipo a deducirla a partir de datos ya importados.
Preguntas frecuentes
¿Qué registro de preparación de Magento Open Source debería crearse primero?
Cree primero el mapa de estructura de destino para websites, store views, tipos de Product, atributos, inventario, Customers, Orders, contenido e integraciones. Ese mapa determina qué evidencias necesita el resto de la lista de preparación.
¿Por qué las muestras de Products son más importantes que los conteos de Products?
Los conteos no revelan relaciones con hijos configurables, componentes de bundles, opciones personalizadas, valores localizados ni campos propiedad de extensiones. Las familias representativas de Products exponen las estructuras que el destino debe sostener.
¿Cada campo de origen debería convertirse en un atributo de Magento?
No. Un valor puede pertenecer a una variante, una opción personalizada, un campo de contenido, una extensión, un sistema externo o una exclusión deliberada. Asigne el campo según su finalidad comercial y el consumidor que continuará utilizándolo.
¿Cómo deberían prepararse los conjuntos de atributos?
Agrupe Products según necesidades reales de gestión, defina los atributos requeridos por cada grupo, normalice valores controlados, documente su alcance y elimine campos obsoletos o duplicados.
¿Cuándo conviene preparar el inventario por separado de los datos del catálogo?
Prepárelo por separado siempre que el stock dependa de sources, stocks, websites, SKU hijos configurables, backorders, reservas o un ERP, WMS, marketplace o proveedor externo.
¿Qué debe hacerse con los datos de extensiones o módulos personalizados?
Identifique el módulo, registro principal, finalidad comercial, tablas o campos, identificadores externos y propietario que continuará en el destino. Los registros importantes necesitan un destino explícito; los obsoletos pueden archivarse o excluirse.