Seleccionar el enfoque de migración adecuado para Phoca Cart exige separar los registros comerciales del entorno Joomla que les da significado operativo. Phoca Cart puede gestionar Products, Categories, Manufacturers, atributos, opciones, especificaciones, inventario, Customers, grupos de clientes, Orders, Coupons, recompensas, divisas, idiomas, impuestos, facturas, métodos de pago, métodos de envío y actividad de punto de venta. También es modular: plugins, módulos, plantillas, integraciones de contenido, niveles de acceso y código personalizado pueden cambiar el funcionamiento de una tienda concreta.
La elección del servicio debe reflejar dónde están los datos y comportamientos necesarios. Standard Service puede ser adecuado para una ruta de migración compatible y limpia. Managed Service ayuda cuando el cliente necesita ejecución por especialistas y validación coordinada. Los Add-ons cubren filtrado acotado de registros, transformación de valores de campos o remapeo de campos dentro de comportamientos compatibles. Custom Service es necesario cuando el resultado esperado depende de registros de extensiones no compatibles, campos personalizados que requieren interpretación o tratamiento no estándar más allá del mapeo compatible, transformaciones a medida, identificadores externos o lógica de migración personalizada.
Dentro de servicios de migración de Next-Cart, la evidencia de Phoca Cart debe distinguir datos comerciales compatibles, necesidades de ejecución dirigida por especialistas, dependencias de Joomla y tratamiento personalizado de extensiones.
Empezar por el alcance de Phoca Cart y Joomla
Phoca Cart es una extensión de comercio electrónico para Joomla, no una aplicación de tienda aislada. El plan debe identificar qué requisitos pertenecen a registros comerciales básicos, cuáles a contenido y estructura del sitio Joomla, cuáles a la configuración de Phoca Cart y cuáles proceden de plugins o desarrollo personalizado.
| Capa de alcance | Ejemplos habituales | Implicación para el servicio |
|---|---|---|
| Datos comerciales básicos | Products, Categories, Manufacturers, Customers, Orders, Coupons, Reviews, imágenes | Pueden encajar en Standard o Managed Service cuando son compatibles y estructuralmente claros |
| Comportamiento de Products | Atributos, opciones, especificaciones, descargas, inventario, Products relacionados, precios por grupo | Requiere mapeo representativo y evidencia de Demo Migration |
| Contexto Joomla | Usuarios, niveles de acceso, menús, alias, módulos, idiomas, contenido y URLs | Debe separarse entre datos migrables, configuración del destino e implementación del sitio |
| Capa de extensiones | Plugins de pago/envío, POS, recompensas, newsletters, herramientas PDF, módulos personalizados | Puede requerir Custom Service o implementación separada en el destino |
| Configuración operativa | Impuestos, divisas, idiomas, pagos, envíos, facturación, estados y plantilla | No se recrea automáticamente mediante la migración del historial de registros |
Una tienda con catálogo pequeño puede requerir un servicio exigente si campos Joomla personalizados, opciones de Product, grupos de clientes, plugins o integraciones externas son esenciales. Una tienda mayor puede seguir siendo adecuada para Standard Service si los registros son convencionales y el cliente puede validar el resultado por su cuenta.
Cuándo puede bastar Standard Service
Standard Service es adecuado cuando la ruta de migración es compatible y los datos requeridos encajan en el comportamiento estándar. Con este servicio de Next-Cart, el cliente es responsable de las decisiones de configuración, la ejecución de la migración y la validación.
Un buen candidato para Standard Service suele tener:
- Products, Categories, Manufacturers, Customers, Orders y contenido compatible bien definidos;
- atributos, opciones y especificaciones comprensibles;
- identificadores de Products y relaciones con imágenes consistentes;
- grupos de clientes y direcciones convencionales;
- Orders históricos legibles sin significado oculto propiedad de plugins;
- alcance de idiomas y divisas definido;
- pocos campos personalizados y pocos datos de extensiones;
- ninguna expectativa de que plantillas, módulos, plugins o configuración activa del proceso de compra de Joomla se reconstruyan mediante migración;
- un equipo capaz de evaluar los resultados de Demo Migration y Full Migration.
Standard Service debe elegirse porque los datos son compatibles y el cliente puede gestionar el trabajo, no porque la tienda parezca visualmente sencilla. Phoca Cart puede ocultar un significado considerable tras opciones de Product, precios por grupo de clientes, reglas de recompensa, plugins de pago, plugins de envío y configuración multilingüe.
Cuándo Managed Service es una mejor opción
Managed Service es adecuado cuando el alcance sigue siendo ampliamente compatible pero el cliente necesita que especialistas de Next-Cart gestionen la ejecución y coordinen la validación. Resulta especialmente útil cuando las responsabilidades de Joomla y comercio están repartidas entre varios equipos.
Managed Service puede ser mejor cuando:
- el cliente no puede operar la migración con confianza por su cuenta;
- varios idiomas, divisas, grupos de clientes o estructuras de Product requieren revisión coordinada;
- un gran volumen de Products u Orders crea una carga significativa de validación;
- la ventana de lanzamiento exige planificación estructurada y gestión de incidencias;
- responsables de negocio, administradores de Joomla y socios de implementación deben aprobar áreas distintas;
- los datos de origen son compatibles pero suficientemente inconsistentes como para requerir una revisión disciplinada;
- se requiere Expert Handle como parte del servicio acordado.
Managed Service no convierte en estándar datos de plugins no compatibles. Resuelve ejecución y coordinación. Si un requisito crítico necesita extracción o transformación no estándar, ese requisito debe seguir evaluándose dentro de Custom Service.
Dónde encajan los Add-ons
Los Add-ons son útiles cuando la migración principal sigue siendo compatible pero se necesita un cambio acotado. Pueden aplicar filtrado de registros por tipo de datos, transformación de valores mediante expresiones, remapeo de campos estándar compatibles o, en rutas elegibles, remapeo de columnas de base de datos sin convertir todo el proyecto Phoca Cart en Custom Service.
Entre los ejemplos se incluyen:
- aplicar condiciones compatibles sobre campos de Products, Customers, Orders o contenido mediante Data Filter;
- aplicar expresiones para transformar valores de campos compatibles mediante Data Transformation;
- remapear campos estándar compatibles de origen a campos compatibles de destino manteniendo el valor sin cambios mediante Advanced Data Mapping;
- mapear columnas de base de datos de origen compatibles a columnas compatibles de Phoca Cart, con los valores sin cambios, mediante Advanced Database Mapping, siempre que la plataforma de origen también sea Open-Source;
- gestionar determinadas salidas SEO o de contenido cuando sean compatibles;
- validar conjuntos filtrados, valores transformados y campos remapeados frente a expectativas definidas.
Los Add-ons no deben presentarse como sustitutos de Custom Service. Remapear un campo estándar compatible de Product del origen a un campo compatible del destino, manteniendo el valor intacto, puede encajar en Advanced Data Mapping. En una migración hacia Phoca Cart, el mapeo de columnas de base de datos compatibles solo puede encajar en Advanced Database Mapping cuando la plataforma de origen también es Open-Source. Extraer historial de recompensas desde una tabla personalizada de un plugin, reconstruir relaciones POS o transformar un sistema de atributos a medida no entra en ese alcance.
La frontera está en si el requisito permanece dentro del comportamiento de migración compatible. Si es así, un Add-on puede bastar. Si exige interpretación a medida, lógica personalizada o datos no compatibles, corresponde Custom Service.
Cuándo se necesita Custom Service
Custom Service debe revisarse cuando el resultado esperado depende de datos o lógica fuera de las estructuras estándar compatibles. En proyectos Phoca Cart, esta necesidad puede aparecer por personalizaciones de Joomla, registros propiedad de extensiones y comportamientos especializados de Products o Customers.
Señales habituales de escalado:
- campos, atributos, opciones o especificaciones de Product personalizados almacenados fuera de estructuras estándar;
- reglas personalizadas de grupos de clientes, historial de recompensas o lógica de precios;
- registros POS o referencias externas de inventario;
- datos de pago, envío, facturación o impuestos almacenados en tablas de plugins;
- usuarios Joomla personalizados, relaciones de acceso, lógica de menús o asociaciones multilingües personalizadas;
- módulos personalizados, personalizaciones de plantilla o integraciones de contenido que almacenan registros críticos para el negocio;
- identificadores externos de ERP, contabilidad, preparación de pedidos, newsletters, marketplaces o CRM;
- transformación a medida entre campos de origen y la plataforma de destino;
- una plataforma personalizada en cualquiera de los dos lados de la ruta de migración;
- requisitos que modifican la lógica estándar de migración.
Custom Service no incluye automáticamente actualizaciones de Joomla, instalación de Phoca Cart, desarrollo de extensiones o plugins, reconstrucción de plantillas, implementación POS, configuración de pago/envío, despliegue de integraciones externas ni construcción completa de la tienda de destino. Esas responsabilidades deben incluirse explícitamente en el alcance acordado.
Cómo influyen los Entity Points en la planificación
Entity Points ayudan a dimensionar los registros elegibles que se migran. En actividad posterior sobre Phoca Cart, los registros elegibles ya contabilizados siguen contándose una sola vez en la misma ruta de migración; la complejidad de Joomla, plugins, campos personalizados y especificaciones se evalúa por separado. Categories, Manufacturers, Reviews, Coupons, atributos, opciones, especificaciones, grupos de clientes, recompensas, CMS Pages, registros de plugins e identificadores externos pueden aumentar la complejidad sin convertirse en tipos de registro separados de Entity Points.
Entity Points contabilizan Products, Customers, Orders y Blog Posts elegibles nuevos cuando se migran por primera vez. Las Categories, Manufacturers, Reviews, Coupons, especificaciones, registros de plugins e identificadores externos de Phoca Cart pueden aumentar la revisión necesaria sin crear nuevos tipos de registro contabilizados, mientras que los registros ya contabilizados siguen contándose solo una vez en la misma ruta.
Esta distinción mantiene separados volumen y complejidad:
| Condición de planificación | Efecto sobre Entity Points | Efecto sobre el servicio |
|---|---|---|
| Muchos Products ordinarios | Requiere capacidad adecuada | Puede seguir encajando en Standard Service |
| Pocos Products con opciones personalizadas o datos de plugins | Menor volumen | Puede requerir Custom Service |
| Nuevos Orders creados antes del lanzamiento | Pueden consumir Entity Points cuando se migran por primera vez | Requiere validación posterior |
| Registros existentes migrados de nuevo en la misma ruta | No generan consumo duplicado solo porque se ejecute otra acción | La configuración debe seguir siendo válida |
Los Entity Points deben planificarse antes de Full Migration, pero nunca deben utilizarse como prueba de que una estructura personalizada de Joomla o Phoca Cart sea compatible.
Qué debe demostrar Demo Migration
Demo Migration debe probar los registros difíciles, no solo los más limpios. Una muestra útil de Phoca Cart incluye:
- Products simples y Products con atributos, opciones, especificaciones o descargas;
- Products que utilicen precios por grupo, recompensas, controles de inventario o valores multilingües;
- Customers de distintos grupos y contextos de acceso;
- Orders con descuentos, Coupons, impuestos, pago, envío, historial de estados y facturas;
- CMS Pages, Blog Posts, menús, alias y URLs prioritarios;
- registros afectados por plugins, módulos, POS o sistemas externos;
- ejemplos de cada idioma, divisa o contexto de tienda que sea relevante.
Demo Migration debe demostrar que el enfoque seleccionado conserva un significado de negocio utilizable. También debe clasificar correctamente las brechas:
- configuración compatible del destino;
- requisito acotado de Add-on;
- requisito de Custom Service;
- responsabilidad de implementación separada de Joomla o Phoca Cart.
El proyecto no debe avanzar a Full Migration suponiendo que un volumen mayor resolverá una brecha estructural ya visible en la muestra.
Additional Migration Options para Phoca Cart
Las Additional Migration Options deben seleccionarse según si la configuración aceptada sigue siendo válida y qué ha cambiado desde la actividad de migración anterior.
| Acción actual | Situación adecuada | Enfoque de revalidación en Phoca Cart |
|---|---|---|
| Continue the Migration with the Last Used Configuration | El alcance, los mapeos y filtros aceptados siguen siendo válidos y debe procesarse nueva actividad del origen. | Nuevos Products, Customers, Orders, Blog Posts, atributos, opciones, valores de idioma, URLs e identificadores de integración. |
| Continue the Migration with a New Configuration | La misma ruta de migración sigue siendo correcta, pero deben cambiar filtros, mapeos o ajustes de destino compatibles. | Estructuras de Products, grupos de clientes, estados de Orders, selección de contenido, alcance de idiomas, URLs y exclusiones. |
| Perform a New Migration | El cliente necesita un resultado de destino distinto en lugar de continuar la configuración anterior. | Alcance completo de comercio, Joomla, contenido, plugins, SEO y aceptación. |
Estas acciones no instalan plugins, reconstruyen plantillas, configuran pagos o envíos, implementan POS ni despliegan automáticamente integraciones externas. Funcionan dentro del alcance de servicio de migración acordado y no cambian la ruta fija de plataforma de origen a plataforma de destino adquirida. Una ruta de plataforma diferente requiere comprar otro servicio de migración.
Separar registros migrados de la implementación de Phoca Cart
Phoca Cart combina datos, contexto Joomla y configuración operativa. Antes de acordar coste y responsabilidades, el enfoque de migración debe identificar qué capa controla cada resultado esperado.
| Resultado esperado | Propiedad principal | Implicación para el servicio |
|---|---|---|
| Products, Customers, Orders, Blog Posts y registros relacionados compatibles | Servicio de migración | Evaluar compatibilidad, mapeo, Entity Points y criterios de aceptación. |
| Categories, Manufacturers, atributos, opciones, especificaciones y relaciones de contenido | Migración + validación del destino | Confirmar cómo se representan las relaciones compatibles y qué ajustes del destino siguen siendo necesarios. |
| Funcionamiento de impuestos, divisas, pagos, envíos, facturas, estados y POS | Configuración de Phoca Cart y proveedores | Los valores históricos sirven de referencia, pero el comportamiento activo debe configurarse y probarse por separado. |
| Menús, módulos, idiomas, niveles de acceso, alias y plantillas de Joomla | Implementación del sitio | Coordinar con los resultados de migración sin asumir una reconstrucción completa del sitio. |
| Plugins y extensiones personalizadas | Responsable de extensión o desarrollo | Identificar los datos que necesitan Custom Service y el comportamiento que debe reimplementarse por separado. |
| Sistemas externos de contabilidad, preparación de pedidos, newsletter, CRM o marketplace | Responsable de integración | Conservar identificadores acordados y volver a desplegar conexiones fuera de la ejecución ordinaria de migración. |
Esta separación evita que el cliente trate una brecha de configuración del destino como un defecto de datos. También evita descartar datos propiedad de extensiones como simple implementación cuando realmente necesitan extraerse o transformarse mediante Custom Service. Los hallazgos de Demo Migration deben clasificarse con este mapa de propiedad antes de cerrar el servicio.
Utilizar escenarios prácticos para elegir el servicio
Escenario 1: catálogo estándar e historial convencional. Los Products utilizan atributos y opciones ordinarios, Customers y Orders son legibles y el equipo de destino configurará Phoca Cart. Standard Service puede bastar cuando Demo Migration confirma las muestras difíciles.
Escenario 2: proyecto compatible pero operativamente exigente. La tienda contiene varios idiomas, grupos de clientes, muchos Orders y una ventana de lanzamiento fija, pero no necesita registros de extensiones no compatibles. Managed Service puede ser más adecuado porque ejecución y validación constituyen el principal riesgo.
Escenario 3: requisito definido de filtrado o remapeo de campos. El cliente necesita excluir Products inactivos mediante condiciones de campos de Product, excluir determinados Orders mediante condiciones de campos de Order o remapear campos estándar compatibles de origen a campos compatibles de destino manteniendo los valores intactos. Data Filter o Advanced Data Mapping pueden resolverlo sin Custom Service. Un mapeo elegible de columnas de base de datos puede utilizar Advanced Database Mapping, siempre que la plataforma de origen también sea Open-Source.
Escenario 4: registros personalizados de recompensas, POS o plugins. Los datos críticos están en tablas de extensiones o campos Joomla personalizados que requieren interpretación no estándar más allá del mapeo compatible. Debe definirse Custom Service para esos registros. Instalar el plugin, reconstruir la operación POS o configurar el proceso de compra activo sigue siendo responsabilidad separada salvo que se incluya expresamente.
Escenario 5: cambios de configuración después de Demo Migration. Opciones de Product, alcance de idiomas, grupos de clientes o selección de contenido necesitan ajustes compatibles mientras la ruta de migración sigue siendo la misma. Debe utilizarse Continue the Migration with a New Configuration en lugar de asumir que la configuración anterior debe reutilizarse.
Escenario 6: se requiere un resultado migrado realmente distinto en la misma ruta adquirida. El cliente necesita un resultado independiente y limpio mientras la ruta de plataforma de origen a plataforma de destino adquirida permanece sin cambios. Debe utilizarse Perform a New Migration y revalidarse el alcance completo, los criterios de aceptación y las responsabilidades del destino. Si debe cambiar la plataforma de origen o la plataforma de destino, se necesita comprar un servicio de migración separado para esa ruta diferente.
Cada escenario debe apoyarse en registros representativos y un resultado esperado documentado. Esto hace defendible la elección y evita utilizar la amplitud de funciones de la plataforma como una justificación vaga para sobredimensionar o infradimensionar el proyecto.
Decisión final sobre el servicio para Phoca Cart
| Evidencia | Servicio probable |
|---|---|
| Registros compatibles, estructuras claras de Product, contexto Joomla convencional y operación gestionada por el cliente | Standard Service |
| Alcance compatible con alta carga de ejecución, coordinación o validación | Managed Service |
| Necesidades acotadas de filtrado de registros, transformación de valores, remapeo de campos compatibles o remapeo elegible de columnas de base de datos en migraciones donde Source y plataforma de destinos son Open-Source | Standard o Managed Service con Add-ons |
| Tablas de plugins, campos personalizados que requieren interpretación no estándar, transformaciones a medida, POS, identificadores externos o lógica Joomla personalizada | Custom Service, potencialmente con Expert Handle y los Add-ons acordados |
La decisión debe confirmarse antes de Full Migration y probarse mediante Demo Migration. El enfoque correcto conserva el significado empresarial de los registros de Phoca Cart sin implicar que todo el sitio Joomla y su ecosistema de extensiones formen parte de la migración estándar de datos. El plan aprobado debe identificar servicio, Add-ons, requisitos de Custom Service, Entity Points Plan, responsables de validación, configuración del destino, trabajo con extensiones y Additional Migration Option. Así se mantiene visible la responsabilidad del lanzamiento y se evita confundir trabajo pendiente de plugins o Joomla con un resultado de migración aceptado.
Conclusión
La selección del enfoque de migración para Phoca Cart depende de separar registros comerciales compatibles, contexto Joomla, configuración del destino, datos propiedad de extensiones e implementación personalizada. Standard Service encaja en rutas limpias y compatibles. Managed Service ayuda con ejecución y validación. Los Add-ons cubren necesidades acotadas y compatibles. Custom Service resuelve requisitos adaptados y no estándar.
Las Additional Migration Options deben reflejar después si la configuración aceptada sigue siendo válida, necesita cambios o debe sustituirse por un nuevo resultado de migración.
Preguntas frecuentes
¿Puede bastar Standard Service para Phoca Cart?
Sí. Puede bastar cuando la ruta de migración es compatible, los registros principales son claros, las estructuras de Product son reconocibles y el cliente puede operar y validar el servicio de forma independiente.
¿Cuándo debe elegirse Managed Service para una migración hacia Phoca Cart?
Managed Service resulta útil cuando el alcance es compatible pero el cliente necesita ejecución especializada, revisión coordinada entre equipos Joomla y comercio o una planificación disciplinada del lanzamiento.
¿Los Add-ons migran plugins de Phoca Cart?
No. Los Add-ons cubren requisitos acotados y compatibles. Tablas de plugins, datos POS, lógica personalizada de recompensas, atributos a medida y registros de sistemas externos suelen requerir revisión de Custom Service o implementación separada.
¿Qué debe demostrar Demo Migration para Phoca Cart?
Debe demostrar opciones y atributos de Products, grupos de clientes, Orders, datos multilingües, contenido, URLs y registros vinculados a extensiones, y mostrar si las brechas corresponden a configuración, Add-ons, Custom Service o implementación separada.
¿Qué Additional Migration Option corresponde a una actividad posterior de Phoca Cart?
Utiliza Last Used Configuration cuando la configuración aceptada siga siendo válida, New Configuration cuando deban cambiar ajustes compatibles y New Migration cuando se requiera un resultado distinto y una revalidación completa.