Si se selecciona J2Store como plataforma de destino, la preparación debe tener en cuenta que los Products se construyen sobre artículos de Joomla y pueden ampliarse mediante varios tipos de Product y aplicaciones. Un Product puede depender de contenido de Joomla, Categories, menús, módulos, grupos de usuarios, opciones, variantes, descargas, Products agrupados, aplicaciones de reservas o suscripciones, plugins de pago y envío, sobrescrituras de plantillas y tablas personalizadas.
Un paquete de preparación fiable hace visible cada dependencia antes de que comience la migración. Debe definir la acción, el responsable, la evidencia y la condición de preparación para cada área importante, manteniendo los registros comerciales históricos separados de la configuración activa del destino. Dado que muchas instalaciones de J2Store tienen una larga trayectoria o numerosas extensiones, el paquete también debe documentar quién asume las decisiones de mantenimiento, recuperación y compatibilidad del entorno que seguirá operando.
Confirmar acceso, recuperación y responsabilidad sobre el ciclo de vida
Empiece por comprobar el acceso operativo a Joomla Administrator y J2Store, al alojamiento y la base de datos, al sistema de archivos y medios, y a tareas programadas o servicios externos. Registre las versiones de Joomla, J2Store, PHP, base de datos, plantilla y extensiones.
| Acción de preparación | Responsable | Evidencia | Condición de preparación |
|---|---|---|---|
| Confirmar acceso administrativo | Administrador de Joomla/J2Store | Cuentas operativas y resumen de funciones | Se pueden inspeccionar Products, Customers, Orders, aplicaciones y estructuras de Joomla. |
| Crear copias recuperables | Responsable de infraestructura | Exportación de base de datos, archivo del sistema de archivos, notas sobre medios y procedimiento de restauración | El entorno puede restaurarse independientemente de la tienda activa. |
| Registrar el entorno instalado | Responsable técnico | Inventario de versiones de Joomla, J2Store, PHP, base de datos, plantilla, plugins, módulos y aplicaciones | El entorno real está documentado, incluidos componentes obsoletos o personalizados. |
| Asignar responsabilidad sobre el ciclo de vida | Responsables empresariales y técnicos | Responsable identificado de alojamiento, seguridad, compatibilidad, sustitución de extensiones y recuperación | El alcance de migración no se utiliza como sustituto del mantenimiento del entorno de origen o destino. |
| Conservar identificadores | Coordinador de migración | IDs de artículos, Products, Categories, opciones, variantes, Customers, usuarios, Orders, aplicaciones y sistemas externos | Las relaciones entre registros pueden rastrearse después de la extracción. |
Si la tienda ya no recibe mantenimiento activo, documente ese hecho de forma explícita. Evite realizar limpieza, actualizaciones o eliminación de extensiones antes de completar la copia inmutable y la evidencia del esquema, porque una tabla o un plugin aparentemente sin uso todavía puede contener historial de Orders o Products.
Preparar Products basados en artículos y tipos de Product
J2Store utiliza artículos de Joomla como Products. La preparación debe conservar tanto la identidad del artículo de Joomla como el registro comercial de J2Store. Según la instalación, los tipos de Product pueden incluir simples, variables, configurables, descargables, flexivariable, variable avanzado, reservas, suscripciones, agrupados, paquetes o patrones definidos por aplicaciones.
| Patrón de Product | Evidencia | Condición de preparación |
|---|---|---|
| Product simple | IDs de artículo/Product, SKU, precio, stock, perfil fiscal, peso, imágenes, vínculos con Category y Order de muestra | La identidad de contenido y la comercial apuntan al mismo elemento vendible. |
| Product variable | Opciones, combinaciones generadas, SKU, precio, stock, peso, imagen y estado por combinación | Cada combinación vendible puede rastrearse y está completa. |
| Product flexivariable o variable avanzado | Registros de combinaciones, estado de publicación, entradas que no son variantes y campos personalizados | Las combinaciones de variantes y los valores introducidos por el Customer están separados. |
| Product descargable | Registros de archivos, límites de descarga, caducidad, ruta del área de Customer y Order completado de muestra | Están documentadas las relaciones Product-archivo y Order-acceso. |
| Product agrupado o en paquete | Product principal, componentes, cantidades, lógica de precios/descuentos, responsable del stock y Order de muestra | La composición y la relación de inventario son explícitas. |
| Product de reserva o suscripción | Recurso/plan, calendario, estado, dependencia de pago, funcionamiento de grupos Joomla y registros históricos | Está documentada la responsabilidad de la aplicación especializada. |
Clasifique cada familia de Products según lo que cambia cuando el comprador selecciona una opción: SKU, stock, precio, peso, envío, impuestos, acceso a archivos, disponibilidad de reserva, calendario de suscripción o entrada del Customer. Esto determina si el valor pertenece a una variante real, una opción de Product, una entrada de línea de Order o un registro de aplicación.
Preparar opciones, variantes, imágenes y entradas de Customers
Las estructuras de opciones de J2Store pueden producir resultados diferentes según el tipo de Product y las aplicaciones instaladas. Un Product variable puede generar una matriz de combinaciones con SKU, precio y stock independientes. Un Product variable avanzado puede combinar dimensiones de variante con entradas libres. Un Product agrupado puede rechazar Products que ya tienen opciones.
| Área de preparación | Evidencia | Condición de preparación |
|---|---|---|
| Definiciones de opciones | Nombres, tipos, valores, orden, asignaciones a Products y efectos sobre el precio | Se comprenden los vocabularios de opciones equivalentes y distintos. |
| Combinaciones de variantes | Product principal, combinación de valores, SKU, precio, stock, imagen, estado y clave externa | Cada elemento vendible hijo tiene una identidad estable. |
| Texto o archivos introducidos por Customers | Definición de entrada y valores de muestra en líneas de Orders | Una entrada puntual no se confunde con metadatos reutilizables del Product. |
| Imágenes de Products y variantes | Archivos principales, miniaturas, adicionales y específicos de combinación | Los medios están asociados al Product o variante correctos. |
| Combinaciones obsoletas o sin uso | Estado, uso en historial de Orders y decisión de retirada | Las referencias históricas se conservan aunque la combinación activa se excluya. |
No regenere matrices de variantes antes de registrar las combinaciones originales y sus IDs. La regeneración puede alterar la identidad o eliminar datos asociados a combinaciones existentes. Si es necesaria una limpieza, conserve un registro de correspondencia entre el origen y la versión depurada.
Preparar Categories, menús, módulos y URL de Joomla
Dado que los Products de J2Store son artículos de Joomla, el descubrimiento depende de Categories, orden de artículos, elementos de menú, módulos, niveles de acceso, idiomas, vistas de plantilla y rutas de aplicaciones de Joomla. Prepare estas relaciones para Products y páginas de tienda de alto valor.
| Relación de descubrimiento | Evidencia | Condición de preparación |
|---|---|---|
| Artículo de Product con Category | IDs de artículo/Product y jerarquía de Categories | La ubicación del Product es intencionada y rastreable. |
| Orden de Categories y artículos | Valores de orden del origen y reglas de presentación de menús | El orden comercial importante está documentado cuando corresponde. |
| Elemento de menú con vista de tienda | Tipo de menú, alias, padre, idioma, nivel de acceso y destino | Se conocen las rutas de Product, Category, carrito, proceso de compra, perfil, descarga y cuenta. |
| Asignación de módulos | Posición, asignación a menús, idioma y responsable | Los módulos de la tienda se clasifican como contenido, presentación o salida de aplicaciones. |
| URL y redirección | Ruta actual, responsable del objeto, intención de destino y extensión de enrutamiento | Las rutas prioritarias tienen un único destino previsto. |
| Relación multilingüe | Asignaciones de idioma y asociaciones de Joomla | Las familias traducidas de Products y navegación pueden rastrearse. |
Una exportación de Products no recrea los menús ni los módulos de Joomla. Prepare la evidencia de contenido y rutas necesaria para diferenciar la migración de datos de la implementación de plantillas y navegación en el destino.
Preparar Customers, usuarios de Joomla, grupos y direcciones
Los Customers de J2Store pueden estar relacionados con usuarios de Joomla, Orders de invitados, direcciones, grupos de Joomla, perfiles específicos de aplicaciones, campos fiscales, datos de empresa e identificadores externos. Prepare estas relaciones por separado.
| Patrón de cuenta | Evidencia | Condición de preparación |
|---|---|---|
| Customer registrado | ID de usuario Joomla, perfil de Customer, correo electrónico, grupos, direcciones, estado y Orders | Los correos duplicados y las cuentas con varios grupos tienen un tratamiento documentado. |
| Customer invitado | Identidad y direcciones a nivel de Order | El historial de invitado sigue siendo comprensible sin crear cuentas no justificadas. |
| Comercio basado en grupos | Grupo Joomla, Product relacionado, estado de Order que activa la acción, efecto sobre precio/acceso y aplicación responsable | La asignación de grupo se representa como relación empresarial, no como simple etiqueta. |
| Cuenta empresarial o fiscal | Campos de empresa, ID fiscal, estado de exención e ID externo de cuenta | La identidad empresarial tiene un responsable identificado. |
| Dependencia de autenticación | Origen de contraseña, SSO/inicio de sesión social, MFA, flujo de restablecimiento y responsable de comunicación | El acceso a las cuentas se planifica sin asumir que las credenciales de origen son portables. |
Cuando una aplicación añade un usuario a un grupo de Joomla después de una compra, capture el Product, el grupo seleccionado, el estado de Order que activa la acción, la pertenencia actual y una muestra histórica. Ese flujo puede controlar contenido protegido o servicios después de la venta.
Preparar Orders y evidencia comercial histórica
Prepare cabeceras de Orders, líneas, referencias a Products y variantes, opciones seleccionadas, entradas de Customers, direcciones de facturación y envío, precios, descuentos, impuestos, etiquetas de pago y envío, estados, comentarios, seguimiento, facturas, descargas, suscripciones, reservas, vales y registros pertenecientes a aplicaciones cuando existan.
| Registro histórico | Evidencia | Condición de preparación |
|---|---|---|
| Historial de estados de Order | Definiciones de estados, marcas de tiempo, comentarios y significado operativo | Cada estado puede interpretarse sin depender de la interfaz antigua. |
| Líneas de Products | IDs de artículo/Product/variante, SKU, valores seleccionados, cantidad, precio e impuestos | El elemento comprado sigue siendo identificable aunque cambie el catálogo activo. |
| Contexto de pago | Etiqueta de método y referencia de transacción | La evidencia histórica del pago está disponible sin trasladar credenciales. |
| Contexto de envío | Etiqueta de método, cargo, seguimiento y notas de procesamiento | La evidencia histórica de entrega está separada de la configuración actual del transportista. |
| Acceso a descargas | Archivo de Product, estado de Order, límite, caducidad y vínculo de Customer | El historial de derechos de acceso digital puede rastrearse. |
| Historial perteneciente a aplicaciones | Registros de suscripción, reserva, paquete, asignación de grupo, vale o fidelización | Los registros relacionados están conectados al Order y Customer correctos. |
Construya un glosario de estados de Orders, pagos, envíos, descargas, suscripciones y reservas. Términos similares como New, Confirmed, Pending, Failed o Completed pueden tener significados operativos diferentes según la extensión.
Inventariar aplicaciones, plugins, campos personalizados y tablas personalizadas
Las aplicaciones de J2Store pueden controlar Products agrupados, paquetes, cargos adicionales, descuentos por volumen, acciones sobre grupos de Customers, reservas, suscripciones, descargas, envíos, pagos, analítica y otros registros. Plugins de Joomla, sobrescrituras de plantillas y tablas personalizadas pueden ampliar las mismas entidades.
Para cada dependencia importante, documente:
- nombre y versión;
- propósito empresarial;
- tablas y campos;
- claves de Products, Customers, usuarios y Orders;
- tareas programadas o eventos que la activan;
- servicios e identificadores externos;
- responsable en el destino o decisión de retirada;
- registros de origen representativos.
No describa el requisito únicamente como "datos de aplicación". Identifique la entidad: suscripción, reserva, componente de paquete, cargo, asignación de grupo, derecho de descarga, campo personalizado del proceso de compra, publicación o estado de integración. Se necesita una definición clara de la entidad antes de poder seleccionar un destino.
Separar registros históricos de la configuración activa del destino
Las etiquetas e importes históricos pueden migrarse como evidencia, pero el funcionamiento activo de impuestos, pagos, envíos, correo electrónico, tareas cron, plantillas, seguridad y extensiones debe implementarse por separado.
| Evidencia del origen | Responsabilidad separada en el destino |
|---|---|
| Etiqueta del método de pago e ID de transacción | Cuenta de pasarela, credenciales, callbacks, controles antifraude y pruebas activas |
| Método de envío, cargo y seguimiento | Cuenta del transportista, zonas, tarifas, recogida, embalaje y configuración de procesamiento de pedidos |
| Importe fiscal histórico y etiqueta de perfil | Registros fiscales actuales, tipos, exenciones y reglas de cálculo |
| Relación entre Product y grupo de Customer | Automatización actual de acceso, precios o membresía |
| Historial de descargas | Protección actual de archivos, área de Customer, entrega por correo electrónico y política de acceso |
| Historial de suscripciones o reservas | Compatibilidad actual de pasarela, tareas programadas, reglas de capacidad, notificaciones y lógica de renovación |
| URL existentes de la tienda | Menús, alias, salida de plantillas, redirecciones e implementación de búsqueda en el destino |
El paquete de preparación está listo cuando tanto la evidencia del origen como la responsabilidad sobre la implementación del destino son explícitas. No debe afirmar que los registros históricos configuran las operaciones futuras.
Seleccionar muestras representativas para probar la migración
Elija muestras difíciles y ricas en relaciones, no únicamente Products sencillos y limpios. Incluya:
- un Product simple relacionado con un artículo y una Category de Joomla;
- un Product variable o flexivariable con datos independientes por combinación;
- un Product variable avanzado con entrada del Customer cuando se utilice;
- un Product descargable con historial de acceso;
- un Product agrupado, en paquete, de reserva o suscripción cuando se utilice;
- una ruta de Product multilingüe o restringida;
- un Customer con varias direcciones o grupos;
- un Order de invitado y otro de Customer registrado;
- un Order con evidencia de descuento, impuestos, pago, envío y seguimiento;
- un registro perteneciente a una aplicación o un identificador externo.
Para cada muestra, registre los IDs de origen, los registros Joomla y J2Store relacionados, el motivo de selección, la evidencia necesaria y cualquier funcionamiento activo asignado deliberadamente a la implementación del destino.
Establecer la comprobación final de preparación
| Pregunta de preparación | Condición de preparación |
|---|---|
| ¿Puede recuperarse la tienda? | Existen copias inmutables de base de datos y sistema de archivos con un responsable de restauración. |
| ¿Está clara la responsabilidad sobre el ciclo de vida? | Alojamiento, seguridad, compatibilidad, sustitución de extensiones y recuperación tienen responsables identificados. |
| ¿Se han clasificado los tipos de Product y variantes? | Cada patrón importante de Product tiene evidencia de origen y una muestra representativa. |
| ¿Están trazadas las relaciones de Joomla? | Pueden rastrearse los artículos de Product, Categories, menús, módulos, idiomas, niveles de acceso y URL. |
| ¿Son comprensibles Customers y Orders? | Están documentados vínculos de usuarios, grupos, direcciones, estados, totales e historial perteneciente a aplicaciones. |
| ¿Tienen responsable las aplicaciones y datos personalizados? | Cada conjunto de datos activo tiene esquema, responsable, clave de origen y decisión de destino. |
| ¿Está separada la configuración del destino? | Están asignadas las responsabilidades de proceso de compra, pagos, envíos, impuestos, cron, plantillas y seguridad. |
| ¿Están controlados los asuntos sin resolver? | Cada dependencia pendiente tiene responsable, fecha límite y efecto sobre el alcance. |
La falta de copias de seguridad, una responsabilidad de ciclo de vida poco clara, variantes regeneradas sin registro del origen, tablas de aplicaciones desconocidas o historial de Products especializados imposible de rastrear deben bloquear el alcance afectado.
Conclusión
Preparar una migración hacia J2Store exige conservar la conexión entre artículos de Joomla y registros comerciales, teniendo en cuenta tipos de Product, variantes, archivos, Customers, Orders, aplicaciones, URL y personalizaciones acumuladas durante años. El paquete de preparación debe indicar quién asume cada acción, qué evidencia demuestra la relación de origen y qué condición permite considerar listo cada ámbito.
Este enfoque mantiene los registros históricos separados de la configuración activa del destino y evita que el funcionamiento de extensiones heredadas quede oculto dentro de una exportación genérica de Product u Order.
Preguntas frecuentes
¿Qué debe prepararse primero antes de una migración hacia J2Store?
Confirme el acceso a Joomla, J2Store, alojamiento, base de datos, sistema de archivos, medios y tareas programadas. Cree copias inmutables y documente las versiones exactas del entorno y las aplicaciones instaladas antes de realizar limpieza o actualizaciones.
¿Por qué los Products de J2Store necesitan evidencia tanto de Joomla como del comercio electrónico?
J2Store utiliza artículos de Joomla como Products. El contenido, Categories, idioma, acceso, menús y rutas pueden pertenecer a Joomla, mientras que SKU, precio, stock, opciones, variantes y relaciones de Orders pertenecen a J2Store.
¿Cómo deben prepararse los Products variables de J2Store?
Registre las definiciones de opciones y cada combinación generada con su Product principal, valores seleccionados, SKU, precio, stock, imágenes, estado e identificadores externos. No regenere combinaciones antes de conservar el mapa de identidad original.
¿Qué evidencia se necesita para Products descargables?
Prepare vínculos entre Product y archivo, ubicaciones de archivos, límites de descarga, configuración de caducidad, rutas del área de Customer, estados de Orders relevantes y Orders completados representativos que muestren el historial de acceso.
¿Cómo deben documentarse las aplicaciones y tablas personalizadas de J2Store?
Identifique la aplicación y la entidad, registre tablas, claves, relaciones con Products/Customers/Orders, eventos, tareas programadas, dependencias externas y registros representativos. Evite tratar toda la información perteneciente a extensiones como datos personalizados genéricos.
¿Qué registros deben elegirse para una prueba representativa de migración de J2Store?
Seleccione Products simples basados en artículos, Products con variantes, tipos avanzados o especializados, rutas restringidas o multilingües, Customers complejos, Orders de invitados y registrados, acceso digital, datos pertenecientes a aplicaciones e identificadores externos.