Si J2Commerce se selecciona como plataforma de destino, la preparación debe conectar los registros comerciales con las estructuras de Joomla que permiten mostrarlos y utilizarlos correctamente. Los Products pueden depender de artículos de Joomla, Categories, menús, módulos, campos personalizados, grupos de usuarios, aplicaciones, extensiones de pago y envío y diseños de plantilla. Los tipos de Product especializados pueden añadir variantes, descargas, suscripciones, reservas, bundles, depósitos o datos introducidos por el cliente que no pueden comprenderse a partir del recuento de Products.
El paquete de preparación debe definir cada acción, responsable, evidencia y condición de preparación antes de iniciar la migración. También debe separar los registros que forman parte del alcance de migración de la configuración activa del proceso de compra, impuestos, pagos, envíos, notificaciones, tareas programadas y extensiones que pertenece a la implementación del destino.
Esta preparación debe producir una muestra representativa de J2Commerce, poner de manifiesto cualquier necesidad de correspondencia de datos o tratamiento adaptado y separar el alcance de la migración de la implementación de Joomla y J2Commerce antes de una ejecución más amplia.
Asegurar el acceso a Joomla, J2Commerce, alojamiento y base de datos
Confirme el acceso a la administración de Joomla, administración de J2Commerce, alojamiento, base de datos, sistema de archivos, medios, tareas programadas y servicios externos. Registre la versión de Joomla, la versión de J2Commerce, las versiones de PHP y base de datos, la plantilla activa, los idiomas habilitados, las aplicaciones instaladas, las extensiones de pago y envío y cualquier código personalizado.
| Acción de preparación | Responsable | Evidencia | Condición de preparación |
|---|---|---|---|
| Confirmar el acceso administrativo | Administrador de Joomla/J2Commerce | Cuentas funcionales y resumen de funciones | Se pueden inspeccionar catálogo, Orders, Customers, aplicaciones, menús y configuración. |
| Crear copias de seguridad recuperables | Responsable de infraestructura | Exportación de base de datos, archivo del sistema de archivos, notas sobre medios externos y responsable de restauración | El origen puede recuperarse sin depender de la tienda activa. |
| Documentar el entorno de extensiones | Responsable técnico | Inventario de componentes, plugins, módulos, plantillas y aplicaciones con versiones | Cada dependencia comercial está registrada y tiene responsable. |
| Registrar procesos programados y externos | Responsable de integraciones | Tareas cron, endpoints de webhook, conexiones ERP/PIM/WMS/CRM/pago/envío e IDs externos | Se identifican las integraciones que continuarán y las autoridades de datos. |
| Conservar identificadores de origen | Coordinador de migración | IDs de Product, Article, Category, usuario, Customer, Order, opción, variante, suscripción y sistemas externos | Las relaciones entre registros pueden rastrearse después de la extracción. |
Si la tienda se originó en J2Store o atravesó un cambio importante de versión, registre ese linaje. Etiquetas similares pueden hacer referencia a tablas o versiones de aplicaciones distintas y las personalizaciones anteriores pueden seguir dependiendo de campos heredados.
Preparar los Products según su funcionamiento de venta
No clasifique los Products de J2Commerce únicamente por nombre o cantidad. Prepárelos de acuerdo con el funcionamiento que debe seguir siendo comprensible: venta simple, venta por variantes, descarga, suscripción, reserva, bundle, servicio, depósito, artículo personalizado o tipo de Product controlado por una aplicación.
| Patrón de Product | Evidencia necesaria | Condición de preparación |
|---|---|---|
| Product físico simple | ID de Article/Product, SKU, precio, perfil fiscal, stock, peso, imágenes, vínculos de Category y Order de muestra | Un registro identifica claramente el elemento vendible y su relación con el contenido de Joomla. |
| Product con variantes | Definiciones de opciones, valores, variantes generadas, SKU/precio/stock/imagen por variante e ID del Product principal | Cada combinación vendible puede rastrearse hasta su Product principal y sus valores seleccionados. |
| Product descargable | Registros de archivos, reglas de acceso, límites, caducidad, vínculo con Product y Order completado de muestra | La propiedad de archivos y la evidencia de acceso basada en Orders están completas. |
| Product de suscripción | Tipo de Product, plan/variante, intervalo de facturación, prueba, estado, dependencia de pago, dependencia de cron, vínculo con grupo de usuarios de Joomla y suscripción de muestra | El estado recurrente y las relaciones de acceso tienen un responsable y una decisión para el destino. |
| Product de reserva | Recurso, reglas de fecha/hora, capacidad, precios, datos introducidos por el Customer y reserva de muestra | Los registros de disponibilidad y el historial de reservas están separados de los campos ordinarios de Product. |
| Bundle o Product agrupado | Product principal, Products componentes, cantidades, lógica de precios, relación de stock y Order de muestra | La identidad y propiedad de los componentes están documentadas. |
| Product personalizado | Definiciones de campos de entrada, funcionamiento de opciones, archivos aportados por el comprador, efectos sobre el precio y línea de Order de muestra | Los datos introducidos por el comprador siguen siendo distinguibles de atributos reutilizables del Product. |
Para cada tipo de Product, registre qué valores controlan la identidad, el precio, el stock, los impuestos, el peso, el envío, el acceso, la renovación o el procesamiento de pedidos. Si una aplicación o plugin personalizado es propietario de parte del funcionamiento, incluya sus tablas, claves y dependencia de configuración dentro del paquete de evidencia.
Preparar opciones, variantes, campos personalizados y relaciones con artículos
Los Products de J2Commerce pueden estar conectados con contenido de artículos de Joomla y con estructuras de opciones o variantes de J2Commerce. La preparación debe distinguir el contenido compartido del Product de los datos de combinaciones vendibles y de los valores introducidos por el cliente.
| Relación | Evidencia | Condición de preparación |
|---|---|---|
| Artículo de Joomla hacia Product | ID de Article, ID de Product, alias, idioma, nivel de acceso y campos de contenido | El contenido del Product no se separa accidentalmente del registro de Product. |
| Opción de Product | Nombre de opción, tipo, valores, orden, efecto en el precio y asignación al Product | Las definiciones reutilizables de elecciones están documentadas. |
| Variante | Product principal, valores de opción seleccionados, SKU, stock, precio, imagen, estado e ID externo | Cada unidad vendible real tiene un registro único y rastreable. |
| Campo personalizado | Definición del campo, contexto, valores, propósito comercial y diseño/aplicación que lo utiliza | Los datos descriptivos no se confunden con elecciones del comprador o estado de una aplicación. |
| Entrada del Customer | Definición de la entrada y valor de línea de Order de muestra | La entrada única del comprador permanece asociada al contexto de compra. |
Normalice etiquetas de opción claramente duplicadas solo después de conservar el vocabulario y las relaciones originales. Si “Colour”, “Color” y “Finish” tienen significados comerciales distintos en el origen, no los fusione simplemente porque parezcan similares.
Preparar Categories, menús, URLs, medios y descubrimiento de la tienda
El descubrimiento del catálogo de J2Commerce puede depender de Categories de Joomla, orden de artículos, elementos de menú, módulos, filtros, búsqueda, diseños de plantilla y medios de Product. Un Product puede estar completo en administración y seguir sin estar disponible mediante la ruta prevista.
Prepare un mapa Product-Category, la jerarquía de Categories, evidencia del orden de artículos, inventario de elementos de menú, asignaciones de módulos, valores de filtros, URLs prioritarias, redirecciones, referencias de imágenes y asignaciones de idioma. Incluya rutas para páginas de Product, vistas de Category, páginas de cuenta, descargas, gestión de suscripciones, carrito, proceso de compra y páginas de campaña importantes.
| Área de descubrimiento | Evidencia de preparación | Condición de preparación |
|---|---|---|
| Pertenencia a Category | IDs de Product/Article y jerarquía de Categories | Los Products incluidos en el alcance tienen una ubicación deliberada para su descubrimiento. |
| Enrutamiento de menús | Tipo de elemento de menú, padre, alias, idioma, nivel de acceso y destino | Las rutas prioritarias de la tienda tienen destinos explícitos. |
| Módulos y filtros | Posición del módulo, asignación de menú, fuente del filtro y extensión propietaria | El funcionamiento de descubrimiento está separado de los datos del Product. |
| Medios de Product | Rutas de archivos, imágenes principales/adicionales/de variante, texto alternativo y notas sobre almacenamiento remoto | Las relaciones de medios pueden rastrearse hasta el Product o variante correctos. |
| Redirecciones y metadatos | URL de origen, intención del destino, metadatos, notas canónicas y evidencia de extensiones de enrutamiento | Las rutas de alto valor tienen un tratamiento previsto único. |
No dé por hecho que migrar los Products recrea menús de Joomla, posiciones de módulos, vistas de plantilla o comportamiento de búsqueda y filtros. Estas son responsabilidades independientes de implementación del destino, aunque las relaciones del origen deben documentarse.
Preparar Customers, usuarios de Joomla, grupos y direcciones
La identidad de Customer en J2Commerce puede involucrar usuarios de Joomla, compradores invitados, registros de direcciones, grupos de Customers, campos de empresa, identificadores fiscales, relaciones de membresía y claves externas de CRM o ERP. Prepare estos elementos por separado.
| Aspecto de cuenta | Evidencia | Condición de preparación |
|---|---|---|
| Customer registrado | ID de usuario de Joomla, ID de Customer, correo electrónico, estado, grupos, direcciones e IDs externos | Los casos de duplicados y pertenencia a varios grupos tienen un tratamiento previsto. |
| Customer invitado | Identidad y direcciones a nivel de Order | El historial de invitados no se fuerza hacia cuentas de usuario inventadas. |
| Grupo de Customer | Definición del grupo y funcionamiento asociado de precio, impuestos, acceso o descuentos | El significado del grupo está documentado más allá de su etiqueta. |
| Identidad de empresa o fiscal | Campos de empresa, números fiscales, estado de validación y referencia externa de cuenta | Los datos de cuentas empresariales tienen un propietario identificado en el destino. |
| Autenticación | Contraseña local, SSO, inicio de sesión social, MFA, proceso de restablecimiento y responsable de comunicaciones | El acceso a cuentas está planificado sin asumir que las contraseñas sean portables. |
Si una aplicación de suscripción o membresía cambia grupos de usuarios de Joomla después de una compra, incluya el estado que activa el cambio, vínculo de Product, grupo de destino, estado de suscripción y Orders de muestra relevantes. La asignación de grupo es entonces una relación controlada por una aplicación, no simplemente metadatos de Customer.
Preparar Orders, pagos, envíos, impuestos e historial posterior a la venta
Los Orders históricos deben explicar qué se compró y qué ocurrió. Prepare cabeceras de Order, líneas de Order, referencias de Product/variante, opciones seleccionadas, valores introducidos por el cliente, direcciones, precios, descuentos, impuestos, etiquetas de pago, etiquetas de envío, estados, comentarios, transacciones, facturas, reembolsos, descargas, suscripciones y referencias de reservas cuando existan.
| Evidencia de Order | Responsable | Condición de preparación |
|---|---|---|
| Cabecera e historial de estados de Order | Operaciones comerciales | La secuencia de estados y las marcas de tiempo son comprensibles. |
| Líneas de Order | Catálogo y operaciones | Product, variante, SKU, valores seleccionados, cantidad y precio se conservan como instantáneas históricas. |
| Evidencia de pago | Finanzas o responsable de pagos | La etiqueta del método y la referencia de transacción están documentadas sin tratar credenciales como datos migrados. |
| Evidencia de envío | Responsable de procesamiento de pedidos | Etiqueta del método, cargo, seguimiento y contexto del envío están disponibles cuando se utilizan. |
| Evidencia fiscal y de descuentos | Finanzas o responsable comercial | Los importes y etiquetas aplicados pueden conciliarse con los totales. |
| Registros posteriores a la venta | Responsable de atención al cliente | Reembolsos, descargas, cambios de suscripción, cancelaciones o estados de reserva están vinculados al Order. |
Cree un glosario de estados que explique qué significa operativamente cada estado de Order, pago, envío, suscripción y reserva del origen. Etiquetas similares pueden representar estados distintos en diferentes extensiones.
Inventariar aplicaciones, plugins, tablas personalizadas e integraciones
Las aplicaciones de J2Commerce y extensiones de Joomla pueden ser propietarias de suscripciones, reservas, bundles, depósitos, envíos, pagos, descuentos, sincronización de stock, fuentes de Products, facturas, fidelización, Reviews y datos personalizados del proceso de compra. El paquete de preparación debe identificar el verdadero propietario de cada registro.
Para cada extensión importante, registre nombre, versión, tablas, campos, claves primarias, claves externas, referencias de Product/Customer/Order, dependencias de configuración, tareas programadas, servicios externos y responsable comercial actual. Clasifique el requisito como registro nativo, registro controlado por una aplicación, registro de sistema externo, configuración del destino, presentación o candidato a retirada.
Los identificadores externos merecen atención independiente. IDs de Product de ERP, IDs de Customer de CRM, IDs de listings de marketplace, códigos de almacén, IDs de transacciones de pago y referencias de gateways de suscripción pueden ser campos pequeños pero claves críticas para conservar relaciones.
La preparación se considera completa cuando ningún registro comercial necesario se describe únicamente como “datos personalizados” o “datos de aplicación”. Cada conjunto de datos activo debe tener entidad, propietario, evidencia de origen y decisión de destino claramente identificados.
Separar los registros migrados de la configuración del destino
El funcionamiento actual de impuestos, pagos, envíos, correo electrónico, monedas, cron, proceso de compra, caché, plantillas y seguridad pertenece a la implementación del destino. Los registros históricos pueden conservar etiquetas e importes sin configurar el funcionamiento activo.
| Evidencia de origen que debe prepararse | Responsabilidad separada en el destino |
|---|---|
| Etiquetas históricas de pago e IDs de transacción | Cuenta de gateway, credenciales, callbacks, configuración antifraude y pruebas de pagos activos |
| Etiquetas históricas de envío y seguimiento | Cuentas de transportistas, tarifas, zonas, embalaje, recogida y configuración de procesamiento de pedidos |
| Importes históricos de impuestos y referencias de perfiles fiscales | Registros fiscales actuales, tasas, exenciones y configuración de cálculo |
| Relaciones de Product y grupos de Customer | Configuración activa de precios, acceso y promociones |
| Historial de suscripciones y referencias de facturación | Compatibilidad actual con tokens del gateway, trabajos de renovación, correo electrónico y automatización de acceso |
| URLs y metadatos existentes | Menús del destino, salida de plantillas, búsqueda e implementación de redirecciones |
La preparación está lista cuando la evidencia del origen explica el significado histórico y el responsable de implementación del destino acepta la responsabilidad sobre la configuración activa. No utilice una exportación correcta del origen como evidencia de que el proceso de compra o la facturación recurrente están configurados.
Seleccionar muestras representativas para las pruebas de migración
Elija muestras que expongan las relaciones difíciles de J2Commerce. Incluya:
- un Product simple vinculado a un artículo y una Category de Joomla;
- un Product con varias opciones, variantes generadas y SKU o stock por variante;
- un Product descargable con evidencia de acceso a archivos;
- una suscripción, reserva, bundle u otro Product especializado cuando se utilice;
- un Customer con varias direcciones o grupos;
- un Order de invitado y un Order de Customer registrado;
- un Order con descuentos, impuestos, envío y referencias de pago;
- un Product con campos personalizados, entrada del cliente o datos controlados por una aplicación;
- una ruta de Product multilingüe o restringida;
- un Product u Order vinculado a un identificador externo.
Para cada muestra, registre IDs de origen, motivo de selección, relaciones que pone a prueba, evidencia necesaria para interpretarla y cualquier configuración del destino que se haya dejado deliberadamente fuera del alcance de migración.
Establecer la condición final de preparación
| Pregunta de preparación | Condición de preparación |
|---|---|
| ¿Puede recuperarse el origen? | Base de datos, sistema de archivos, medios y evidencia de extensiones están respaldados y existe un responsable de restauración. |
| ¿Están clasificados los tipos de Product? | Cada familia de Product incluida en el alcance tiene tipo, funcionamiento de venta, responsable y muestra representativa. |
| ¿Son visibles las relaciones de Joomla? | Artículos, Categories, menús, módulos, idiomas, niveles de acceso y rutas están mapeados para Products prioritarios. |
| ¿Pueden interpretarse Customers y Orders? | Los vínculos de usuario, grupos, direcciones, estados, totales y registros posteriores a la venta están documentados. |
| ¿Tienen propietario las aplicaciones y los datos personalizados? | Cada conjunto de datos activo de una extensión tiene esquema, responsable, clave de origen y decisión de destino. |
| ¿Está separada la configuración? | El proceso de compra activo, impuestos, pagos, envíos, cron y plantillas tienen responsables identificados en el destino. |
| ¿Son adecuadas las muestras? | Las muestras representativas de migración cubren variantes, Products especializados, estados de Customer/Order, URLs y datos de extensiones. |
Copias de seguridad desconocidas, tipos de Product sin clasificar, identidad de variantes ausente, datos de suscripciones o reservas sin documentar o tablas de extensiones sin responsable deben bloquear el alcance afectado hasta completar la evidencia.
Conclusión
Preparar una migración hacia J2Commerce exige algo más que exportar Products y Orders. Es necesario conservar las relaciones entre artículos de Joomla, Categories, menús, usuarios, Products de J2Commerce, opciones, variantes, Customers, Orders, aplicaciones de Products especializados, archivos, rutas y sistemas externos.
Un paquete de preparación sólido asigna cada acción a un responsable, registra la evidencia necesaria para comprender cada relación, separa la configuración activa del destino de los registros históricos y selecciona muestras representativas que expongan la complejidad real de la tienda antes de comenzar la migración.
Preguntas frecuentes
¿Qué debería prepararse primero para una migración hacia J2Commerce?
Asegure el acceso a Joomla, J2Commerce, alojamiento, base de datos, sistema de archivos, tareas programadas y sistemas externos. Después cree copias de seguridad inmutables y un inventario fechado del entorno y las extensiones antes de limpiar o reestructurar registros.
¿Por qué son importantes los artículos de Joomla en la preparación de J2Commerce?
Los Products de J2Commerce pueden depender del contenido de artículos de Joomla, Categories, menús, idioma, niveles de acceso, módulos y rutas. El registro de Product por sí solo puede no contener la identidad completa de la tienda ni su recorrido de descubrimiento.
¿Cómo deberían prepararse las variantes de J2Commerce?
Registre el Product principal, definiciones de opciones, valores seleccionados, SKU, stock, precio, imágenes, estado e identificadores externos de cada variante. Utilice variantes representativas que expongan las combinaciones con mayor riesgo de perder identidad durante la migración.
¿Qué evidencia se necesita para suscripciones o reservas de J2Commerce?
Prepare tipo de Product, plan o recurso, calendarios, estados, vínculos con Customer y Order, referencias de pago, reglas de acceso, dependencias de tareas programadas y registros históricos representativos. Trate la configuración activa de renovación o disponibilidad como una responsabilidad independiente del destino.
¿Deben incluirse los ajustes de pago, envío e impuestos como registros migrados?
Los Orders históricos deben conservar etiquetas de métodos, importes y referencias de transacción o seguimiento. Gateways activos, tarifas de transportistas, zonas, credenciales y cálculo fiscal pertenecen a la configuración del destino y deben tener responsables independientes.
¿Qué registros deberían elegirse para una prueba representativa de migración hacia J2Commerce?
Seleccione Products simples y con variantes, tipos especializados de Product, archivos descargables, Customers complejos, Orders de invitados y registrados, descuentos e impuestos, rutas multilingües o restringidas, campos personalizados, datos controlados por aplicaciones e identificadores externos.