Si OpenCart ha sido seleccionado como plataforma de destino, la preparación debe hacer comprensible la Store de origen antes de finalizar cualquier configuración de migración. La tienda online visible puede parecer sencilla mientras relaciones importantes están distribuidas entre Products, opciones reutilizables, atributos, filtros, Categories, Manufacturers, Customer Groups, descuentos, ofertas especiales, varias Stores, SEO keywords, extensiones, temas y campos personalizados de base de datos.
El objetivo es convertir esa estructura distribuida en evidencia controlada del origen. Cada área principal debe identificar la acción que hay que completar, quién puede confirmar su significado para el negocio, qué evidencia debe prepararse y qué condición permite considerar el área lista. Así se evita tratar una exportación de Products como una descripción completa de la Store cuando las elecciones de compra, reglas de descubrimiento, contexto histórico de Orders o dependencias de extensiones están en otros lugares.
Confirmar primero la instalación, el alcance y el acceso de origen
Antes de analizar campos individuales, registra exactamente qué instalación de OpenCart se está migrando y qué Stores, idiomas, monedas, temas, extensiones y modificaciones forman parte del origen. En entornos autohospedados, también deben conocerse el hosting, versión de PHP, base de datos, configuración del servidor web y cualquier mecanismo de reescritura o tarea programada que afecte al funcionamiento.
| Acción de preparación | Responsable | Evidencia | Condición para estar listo |
|---|---|---|---|
| Confirmar versión y alcance de OpenCart | Responsable de plataforma | Versión, URLs administrativas, lista de Stores y notas de alcance | La instalación exacta y todas las Stores incluidas están identificadas. |
| Verificar acceso a base de datos y archivos | Hosting o responsable técnico | Credenciales disponibles, datos de la lista de acceso permitida y nota de prueba de acceso | La conexión requerida puede alcanzar la instalación correcta. |
| Identificar tema y capas de modificaciones | Desarrollador o agencia | Nombre del tema, listas OCMOD/VQMod e inventario de archivos modificados | Los registros nativos pueden distinguirse del funcionamiento dependiente de código. |
| Registrar idiomas, monedas, impuestos y unidades | Responsable de comercio | Exportación de configuración o capturas | Los valores globales que afectan al significado de Products y Orders están documentados. |
| Identificar importaciones o sincronizaciones programadas | Responsable de integración | Frecuencia de las fuentes o sincronizaciones de datos, sistemas externos y evidencia de última ejecución | El equipo conoce qué valores pueden cambiar durante la preparación. |
Establece un punto de corte para cambios estructurales no controlados. La actividad comercial ordinaria puede continuar, pero nuevas extensiones, cambios de esquema, reorganizaciones masivas del catálogo o reescrituras de URLs deben registrarse después de reunir la evidencia de origen.
Preparar Products, opciones, atributos y filtros como conjuntos de evidencia separados
OpenCart distingue los registros de Product de opciones, atributos y filtros. Las opciones recogen valores seleccionables o introducidos por el Customer y pueden afectar a precio, peso, puntos de recompensa, cantidad u obligatoriedad. Los atributos describen características de Products. Los filtros ayudan a descubrir Products mediante relaciones con Products y Categories. Combinar todas estas estructuras en una sola hoja puede ocultar si un valor es una elección de compra, una especificación o una ayuda de navegación.
Crea un inventario de Products que incluya modelo, SKU u otros identificadores, estado, cantidad, stock status, precio, tax class, peso, dimensiones, Manufacturer, Categories, imágenes, Downloads, Products relacionados, ofertas especiales, descuentos, recompensas, opciones, atributos y filtros cuando se utilicen. El inventario no necesita reproducir cada columna de la base de datos, pero sí revelar las relaciones que distinguen Products simples y complejos.
| Patrón de origen | Acción de preparación | Evidencia necesaria | Condición para estar listo |
|---|---|---|---|
| Opción obligatoria o que cambia el precio | Registrar tipo de opción, valores, obligatoriedad y ajustes | IDs de Products y asignaciones representativas de opciones | El efecto comercial de la opción es explícito. |
| Entrada de texto, textarea, archivo, fecha u hora | Separar valores introducidos por el Customer de valores reutilizables de opciones | Lista de Products y líneas de Order de ejemplo que utilicen la entrada | La entrada específica de la compra no se confunde con una variante. |
| Especificación técnica | Registrar Attribute Group, Attribute, valor por idioma y asignación a Product | Exportación de atributos o muestra estructurada | Los datos descriptivos están separados de las elecciones seleccionables. |
| Filtro de tienda online | Registrar Filter Group, valor y asignaciones a Product y Category | Mapa de filtros activos | Solo se conservan filtros utilizados por recorridos actuales de descubrimiento. |
| Product con varias imágenes o Downloads | Registrar secuencia de media y disponibilidad de archivos | Lista de media, rutas e IDs de Products representativos | Los archivos y sus relaciones con Products están disponibles. |
| Ofertas especiales o descuentos por Customer Group | Registrar Product, Customer Group, importe o porcentaje, umbral de cantidad y fechas | Inventario de reglas de Prices | La evidencia de Prices condicionales está completa y no se reduce al precio base. |
Normaliza solo defectos de origen evidentes. Las etiquetas de opciones duplicadas, diferencias de mayúsculas, filtros sin uso o identificadores vacíos pueden señalarse, pero no deben fusionarse valores solo porque se parecen. El responsable de comercio debe aprobar cualquier normalización que cambie el significado visible para el Customer.
Documentar Categories, Manufacturers, Stores y relaciones de descubrimiento
Las Categories de OpenCart pueden formar jerarquías, contener contenido multilingüe, conectarse con filtros y asignarse a Stores concretas. Los Products pueden pertenecer a varias Categories y Stores. Los Manufacturers pueden actuar como un simple dato de Product o como páginas públicas de marca. Estas relaciones deben registrarse por separado de la presentación del menú.
Prepara el árbol activo de Categories con IDs padre, asignaciones por Store, estado, orden, imágenes, descripciones, metadata, filtros y URLs actuales. Marca Categories obsoletas, ocultas, duplicadas solo para navegación o conservadas por enlaces históricos. Para Manufacturers, registra cuáles tienen rutas públicas, descripciones útiles, imágenes o valor para búsqueda.
En instalaciones multitienda, crea una matriz de alcance por Store. Un Product o Category disponible en la Store predeterminada puede no pertenecer a todas las demás. También pueden variar idiomas, temas, dominios, páginas de contenido y configuraciones. La evidencia final debe mostrar qué registros son compartidos, duplicados o específicos de una Store.
| Área de descubrimiento | Responsable | Evidencia | Condición para estar listo |
|---|---|---|---|
| Jerarquía de Categories | Responsable de catálogo | Exportación padre-hijo y lista de Categories activas | Cada Category conservada tiene un padre conocido y una finalidad de negocio. |
| Asignaciones Product-to-Category | Responsable de merchandising | Products representativos en varias Categories y exportación de asignaciones | La ubicación compartida de Products es visible sin crear Products duplicados. |
| Páginas de Manufacturers | Responsable de marca o SEO | Lista de Manufacturers, inventario de rutas y notas de visibilidad | Las marcas públicas están separadas de valores internos de fabricante. |
| Asignaciones por Store | Responsable multitienda | Matriz de alcance de Products, Categories, páginas informativas y dominios | Cada registro tiene un alcance de Store previsto. |
| Filtros y navegación | Responsable de merchandising | Mapa Filter-to-Category y capturas de menú | La clasificación del catálogo está separada de la presentación del menú. |
Preparar Customers, Customer Groups, direcciones e historial de Orders
La preparación de Customers debe distinguir identidad de cuenta, libreta de direcciones, pertenencia a Customer Groups, estado de aprobación, preferencias de marketing, puntos de recompensa, campos personalizados e identificadores externos. Un Customer Group puede controlar descuentos, Prices de Products, tratamiento fiscal, acceso a pagos o flujos de aprobación; debe documentarse su efecto comercial y no únicamente conservar el nombre.
La preparación de Orders debe conservar evidencia histórica. Crea un inventario de estados y selecciona Orders que representen compras de invitados y registrados, diferentes Customer Groups, opciones seleccionadas, descuentos, Coupons, puntos de recompensa, impuestos, envío, etiquetas de pago, reembolsos o devoluciones cuando existan y totales creados por extensiones. Registra qué campos históricos se necesitan para búsquedas internas, historial de cuenta del Customer, conciliación contable o integraciones externas.
| Área de registro | Acción de preparación | Evidencia | Condición para estar listo |
|---|---|---|---|
| Cuentas de Customers | Identificar correos duplicados, estados de aprobación, campos personalizados y claves externas | Resumen de Customers y lista de excepciones | Cada excepción de identidad tiene responsable y resolución prevista. |
| Customer Groups | Registrar cada efecto comercial o de acceso activo | Matriz grupo-to-regla | El significado del grupo está documentado más allá de la etiqueta. |
| Direcciones | Separar direcciones reutilizables de Customers de instantáneas guardadas en Orders | Muestras de direcciones de Customers y Orders | Los datos actuales de cuenta y la evidencia histórica no se mezclan. |
| Estados de Orders | Relacionar cada estado con su significado operativo | Lista de estados y Orders de ejemplo | Los estados históricos pueden interpretarse sin depender solo del color o la etiqueta. |
| Totales de Orders | Inventariar subtotal, impuestos, envío, Coupon, recompensa, cargo, crédito y líneas de extensiones | Totales de Orders representativos | Cada ajuste material tiene un propietario de origen conocido. |
| Referencias externas | Registrar IDs de ERP, marketplace, pago, envío o contabilidad | Mapa de identificadores | Los sistemas que seguirán funcionando pueden localizar el mismo Customer u Order. |
No edites Orders históricos solo para que parezcan consistentes. Una etiqueta o importe inusual puede ser evidencia importante de la transacción original. Registra las anomalías conocidas por separado.
Inventariar extensiones, modificaciones, temas y datos personalizados
Las extensiones de OpenCart pueden añadir campos, tablas, funcionamiento de opciones, totales de Orders, fuentes de datos, publicaciones de marketplace, pasos del proceso de compra, registros de pago, referencias de envío, informes, lógica SEO o flujos administrativos. Los temas también pueden leer campos personalizados o modificar cómo se muestran opciones, filtros y contenido. Una lista de nombres de extensiones no es suficiente; la preparación debe registrar los registros de negocio que controla cada una.
Crea un registro de extensiones con estado, proveedor, versión, finalidad, ubicación de almacenamiento cuando se conozca, entidades afectadas, campos o tablas personalizados, dependencias externas y el responsable que pueda confirmar si la función sigue siendo necesaria. Separa datos activos del negocio de configuración y residuos técnicos obsoletos.
| Efecto de la extensión | Evidencia que preparar | Decisión de preparación |
|---|---|---|
| Campos de Product u opción | Nombres de campos, Products de muestra y ubicación de tabla o exportación | Cada valor activo tiene propietario en destino o exclusión deliberada. |
| Lógica de totales de Order o proceso de compra | Orders de ejemplo, etiquetas de totales y resumen de configuración del módulo | Los valores históricos pueden separarse de la configuración futura del proceso de compra. |
| Integración de marketplace o fuente de datos | IDs de publicaciones, Categories del canal y claves de sincronización | La identidad canónica del Product y los registros del canal están diferenciados. |
| Modificación SEO o de URLs | Ejemplos de rutas actuales, tablas de redirects y configuración de reescritura | Las rutas importantes de origen pueden reconstruirse. |
| Contenido dependiente del tema | Capturas, rutas de templates y asignaciones de bloques o módulos | El contenido está separado del código de presentación. |
| Extensión abandonada | Evidencia de último uso y confirmación del responsable de datos | Los registros obsoletos están marcados para archivo o exclusión. |
Preparar contenido, SEO keywords, media y evidencia de rutas
OpenCart puede asignar SEO keywords a Products, Categories, Manufacturers y páginas informativas. Prepara un inventario de rutas que registre el objeto de origen, alcance por Store e idioma, ruta actual, SEO keyword, importancia por tráfico o negocio y disposición prevista. Marca keywords duplicadas, keywords vacías en registros importantes, rutas creadas por extensiones y rutas que dependen de configuración de reescritura del servidor.
La preparación de contenido debe incluir páginas informativas, descripciones de Products y Categories, contenido de Manufacturers, banners, layouts, módulos y archivos multimedia que sigan siendo importantes. Registra si cada elemento es un registro de contenido que debe migrarse, una tarea de configuración de la tienda de destino, un recurso del tema, un recurso externo o material obsoleto.
Haz copia de los archivos originales de imágenes y Downloads junto con sus rutas. Una exportación de base de datos puede contener nombres de archivo sin incluir los propios archivos. Identifica archivos ausentes, URLs externas, diferencias de mayúsculas sensibles a la ruta y thumbnails generados que no necesitan convertirse en originales de origen.
Construir el paquete de copias de seguridad y preparación de entradas
Crea un paquete de origen restaurable antes de realizar limpieza estructural o ejecutar la migración. Para una Store de OpenCart autohospedada, normalmente incluye copia de seguridad de base de datos, árbol de archivos relevante, detalles del entorno, referencias de configuración y evidencia de que la copia corresponde al mismo estado de Store.
| Componente del paquete | Responsable | Evidencia | Condición para estar listo |
|---|---|---|---|
| Copia de base de datos | Hosting o administrador de base de datos | Dump con fecha y nota sobre restauración | El dump está completo y corresponde a la base correcta. |
| Archivos y media | Hosting o responsable técnico | Archivo comprimido o árbol de archivos accesible | Imágenes originales, Downloads, extensiones y archivos del tema están disponibles. |
| Registro del entorno | Responsable técnico | Notas de PHP, base de datos, servidor web y extensiones | Puede interpretarse el funcionamiento sensible a versiones. |
| Registro de acceso | Responsable del proyecto | Responsable de credenciales y estado de acceso | El acceso necesario está disponible sin compartir credenciales en documentos de planificación. |
| Registro de cambios | Administrador de Store | Cambios posteriores al punto de corte de evidencia | Los cambios estructurales tardíos pueden incorporarse de forma deliberada. |
Seleccionar muestras representativas para probar la migración
El conjunto de muestras debe exponer las relaciones que definen la Store de OpenCart. Prepara un manifiesto compacto con IDs de origen, motivo de negocio, archivos relacionados y estructura de origen esperada para cada muestra. El manifiesto está listo cuando cada registro seleccionado tiene evidencia completa de origen y una persona responsable de revisarlo.
Incluye como mínimo:
- un Product simple y uno inactivo o archivado;
- Products con opciones obligatorias, que cambian el precio, de texto, archivo, fecha o sensibles al stock cuando se utilicen;
- Products con atributos, filtros, varias Categories, Manufacturers, varias imágenes, Downloads, ofertas especiales y descuentos por Customer Group;
- Customers de Customer Groups relevantes, un Order de invitado y un Order de Customer registrado;
- Orders con valores de opciones, Coupons, recompensas, impuestos, envío, referencias de pago, totales inusuales e IDs externos;
- una ruta importante de cada tipo de objeto público;
- un registro activo perteneciente a una extensión y un ejemplo de contenido dependiente del tema.
Aplicar el criterio final de preparación de OpenCart
OpenCart está preparado para el siguiente paso de la migración cuando el origen puede describirse sin depender de suposiciones no documentadas.
| Pregunta de preparación | Resultado requerido |
|---|---|
| ¿Se conoce la instalación exacta y el alcance de Stores? | Se registraron versión, Stores, idiomas, monedas, tema y capas de modificaciones. |
| ¿Están completas las relaciones de Products? | Se representan opciones, atributos, filtros, Categories, media, reglas de Prices e identificadores. |
| ¿Customers y Orders son interpretables? | Lógica de grupos, direcciones, estados, totales y referencias externas tienen responsables. |
| ¿Se clasificaron extensiones y datos personalizados? | Cada dependencia activa tiene finalidad de negocio y decisión de destino. |
| ¿Se inventariaron contenido y URLs? | Rutas importantes, páginas informativas, media y dependencias de reescritura están documentadas. |
| ¿Copias de seguridad y acceso están listos? | El paquete de origen es restaurable y la conexión requerida está disponible. |
| ¿El conjunto de muestras es representativo? | Registros complejos y ordinarios están listados con IDs de origen y relaciones esperadas. |
Los asuntos sin resolver deben registrarse en un log de decisiones con responsable y fecha. La preparación no está completa si un campo crítico, tabla de extensión, asignación de Store o identificador externo sigue descrito únicamente como “desconocido”.
Conclusión
La preparación de OpenCart es más sólida cuando trata la Store como un catálogo conectado y un registro operativo, no como una simple exportación plana de Products. Opciones, atributos, filtros, Categories, Stores, Customer Groups, totales de Orders, extensiones, temas, media y SEO keywords necesitan cada uno un responsable y un conjunto de evidencia claro.
Un paquete de origen controlado, un manifiesto de muestras representativas y un criterio explícito de preparación ofrecen una base fiable para configurar la migración.
Preguntas frecuentes
¿Por qué deben prepararse por separado las opciones, atributos y filtros de OpenCart?
Porque cumplen funciones diferentes. Las opciones recogen elecciones de compra o entradas del Customer, los atributos describen Products y los filtros ayudan a descubrir Products. Combinarlos puede crear estructuras de variantes incorrectas o eliminar especificaciones y relaciones de navegación útiles.
¿Qué debe registrarse en una instalación multitienda de OpenCart?
Registra cada Store ID, dominio, idioma, moneda, tema, configuraciones, asignaciones de Products y Categories, páginas informativas y URLs importantes. Los registros compartidos deben poder distinguirse de los específicos de una Store.
¿Una copia de seguridad de base de datos incluye imágenes y Downloads de OpenCart?
No. La base de datos suele almacenar referencias a archivos, mientras las imágenes originales, Downloads, recursos del tema y archivos de extensiones permanecen en el sistema de archivos. Prepara evidencia tanto de base de datos como de archivos.
¿Cómo deben prepararse los datos pertenecientes a extensiones de OpenCart?
Registra la extensión, entidades afectadas, campos o tablas personalizados, registros de origen representativos, dependencias externas y finalidad de negocio que continúa vigente. Los valores activos necesitan un propietario explícito; los registros obsoletos pueden marcarse para archivo o exclusión.
¿Qué registros de OpenCart deben formar parte del conjunto de muestras representativas?
Utiliza Products ordinarios y complejos, varios tipos de opciones, atributos y filtros, relaciones con varias Categories, Customer Groups, Orders significativos, rutas importantes y registros activos de extensiones. El manifiesto debe incluir IDs de origen y relaciones esperadas.
¿Deben modificarse las SEO keywords duplicadas durante la preparación?
Primero deben marcarse y asignarse a un responsable. Solo deben cambiarse mediante una decisión de URL aprobada que registre el destino previsto y la relación de redirect, porque una keyword aparentemente duplicada puede seguir teniendo importancia para tráfico o integraciones.