Si osCommerce se selecciona como plataforma de destino, la preparación debe comenzar por el linaje de la instalación, porque osCommerce v4 actual y las instalaciones heredadas de larga duración pueden utilizar estructuras sustancialmente distintas para catálogo, extensiones, contenido y base de datos. Una tienda descrita como osCommerce puede ser v4 actual, una versión 2.x antigua, un fork o una base de código muy modificada con extensiones comunitarias y cambios directos de esquema.
El objetivo de la preparación es identificar el modelo real del origen antes de elegir los mapeos de campos. Cada área debe indicar la acción, el responsable, la evidencia y la condición para considerarla preparada. Relaciones actuales de v4 como canales de venta, grupos de Customers, atributos, propiedades y registros CMS no deben suponerse presentes de la misma forma en un origen heredado. Del mismo modo, una tabla de extensión antigua no debe tratarse como datos nativos de v4 solo porque exista una función moderna con un nombre similar.
Confirmar el linaje del origen, el acceso y la responsabilidad técnica
Registra el nombre de la plataforma de origen, versión, rama o fork, prefijo de base de datos, entorno de alojamiento, front ends o tiendas activos, idiomas, monedas, extensiones, archivos modificados, tablas personalizadas y sincronizaciones externas. Cuando una tienda antigua haya pasado por varias actualizaciones, conserva notas de desarrollo o evidencia del esquema que explique qué tablas siguen controlando el comportamiento actual.
Prepara el acceso al origen necesario para la ruta de migración seleccionada. El responsable técnico debe confirmar que la conexión accede a la base de datos y al árbol de archivos correctos y que las copias de seguridad disponibles pertenecen al mismo estado de la tienda.
| Acción | Responsable | Evidencia | Condición de preparación |
|---|---|---|---|
| Identificar generación y linaje del código de origen | Responsable técnico | Evidencia de versión, repositorio o nota de paquete, historial del fork | El origen está clasificado como v4 actual, osCommerce heredado, fork o derivado personalizado. |
| Confirmar acceso a base de datos y archivos | Responsable de alojamiento o base de datos | Nombre/prefijo de base de datos, estado de conexión, nota del document root | La conexión requerida al origen accede a la instalación prevista. |
| Inventariar extensiones y modificaciones del núcleo | Desarrollador o agencia | Lista de extensiones, registro de archivos modificados, lista de tablas personalizadas | Pueden separarse registros nativos, propiedad de extensiones y personalizados. |
| Registrar front ends, idiomas, monedas y contexto fiscal | Responsable comercial | Evidencia de configuración y matriz de alcance | Está documentado el contexto global que cambia el significado de Products u Orders. |
| Identificar sistemas externos e importaciones | Responsable de integraciones | Lista de ERP/PIM/WMS/CRM, calendario de fuentes, campos clave | Los valores mantenidos fuera de osCommerce tienen una autoridad asignada. |
Una vez reunida la evidencia, congela los cambios estructurales no documentados. La operativa habitual puede continuar, pero las nuevas extensiones, cambios de esquema, modificaciones del modelo de Products o reescrituras de rutas deben registrarse en el control de cambios del proyecto.
Preparar Products, Categories, marcas, proveedores y alcance por front end
osCommerce v4 actual puede asociar Products con Categories, marcas, proveedores, canales de venta o front ends, grupos de Customers, descripciones multilingües, modos de stock, imágenes, identificadores, precios, campos SEO y relaciones de merchandising. Las tiendas heredadas pueden utilizar tablas principales más simples y extensiones para muchas de estas funciones.
Crea un inventario de Products que registre el ID de origen, SKU o modelo, otros identificadores, estado, precio base, clase fiscal, comportamiento de stock, peso, estado virtual o descargable, asignaciones a Categories, marca o fabricante, proveedor, imágenes, valores por idioma, alcance por canal de venta, alcance por grupo de Customers y relaciones activas de promoción o precios por cantidad.
| Patrón del origen | Acción de preparación | Evidencia | Condición de preparación |
|---|---|---|---|
| Product asignado a varias Categories | Registrar todas las relaciones con Categories y el contexto principal de merchandising | Exportación Product-to-Category | La colocación compartida es visible sin duplicar Products. |
| Product disponible solo en determinados front ends | Registrar asignaciones y restricciones por canal/front end | Matriz de alcance por Product y Category | La disponibilidad por canal es explícita. |
| Relación de marca o proveedor | Separar identidad pública de marca de la responsabilidad de aprovisionamiento | Vínculos entre marca, proveedor y Product | Etiquetas similares no se fusionan en un campo no relacionado. |
| Estado de stock real, ilimitado, oculto o preventa | Registrar cantidad, modo de stock y tratamiento cuando no hay existencias | Configuración de Products representativos | El significado de disponibilidad no se reduce a una cantidad numérica. |
| Product virtual o descargable | Registrar archivo, caducidad, límites de descarga, significado de envío y ruta de origen | Manifiesto de Product/archivo | Las relaciones de entrega digital y los archivos originales están disponibles. |
| Precio por grupo o cantidad | Registrar Product, grupo de Customers, umbral, moneda e importe | Inventario de relaciones de precios | El precio condicional no se sustituye por el precio base. |
En tiendas heredadas, indica qué valores proceden de tablas principales de Products y cuáles de columnas de extensiones o tablas separadas. El responsable comercial debe aprobar cualquier limpieza que cambie la identidad del Product o su alcance por canal.
Separar atributos, propiedades y relaciones de Products configurables
v4 actual distingue atributos y propiedades. Los atributos pueden representar valores seleccionables, plantillas reutilizables, efectos sobre precio o peso, archivos virtuales y relaciones de inventario. Las propiedades describen características estructuradas utilizadas para presentación, filtros, búsqueda, comparación, rangos, iconos o grupos de Products. Los atributos heredados de osCommerce pueden combinar varios de estos significados.
Prepara evidencia que clasifique cada valor del origen por su función y no por su nombre.
| Significado comercial | Acción de preparación | Evidencia | Condición de preparación |
|---|---|---|---|
| Elección seleccionable por el comprador | Registrar atributo, valores, plantilla, asignación de Product y efectos sobre precio/peso | Exportación de atributos y asignaciones | La elección de compra y su efecto comercial son explícitos. |
| Combinación con SKU o stock independiente | Identificar registros de combinación configurables o propiedad de extensiones | Tabla de combinaciones y claves de Product | La identidad vendible independiente queda preservada en el modelo del origen. |
| Especificación técnica | Registrar categoría de propiedad, propiedad, tipo, unidades, valores y vínculos de Product | Inventario de propiedades | Los datos descriptivos están separados de las elecciones del comprador. |
| Valor para filtros o comparación | Registrar funcionamiento de presentación/filtro/búsqueda y taxonomía | Mapa de campos activos para descubrimiento | Están identificados los valores necesarios para encontrar Products. |
| Entrada de texto o personalización | Identificar propietario del campo y líneas de Orders representativas | Ejemplos de Product y Order | La entrada específica de la compra no se trata como metadato reutilizable. |
| Atributo descargable | Registrar archivo, límites, Product y relación con atributo | Manifiesto de archivos y atributos | El archivo y la evidencia del derecho de descarga están completos. |
No conviertas automáticamente todos los atributos heredados en atributos actuales de v4. Algunos pertenecen a propiedades, relaciones de Product configurable, campos personalizados o estructuras propiedad de extensiones.
Documentar grupos de Customers, cuentas, direcciones y contexto comercial
Los grupos de Customers de v4 actual pueden controlar visibilidad de Products y Categories, aplicación de impuestos, descuentos acumulativos y valores predeterminados para invitados o usuarios recién registrados. Las extensiones pueden añadir registros mayoristas, B2B, crédito, fidelización o aprobación. Las tiendas heredadas pueden representar estas relaciones de otra manera.
Prepara evidencia de Customers que separe identidad, registros de libreta de direcciones, estado de invitado, pertenencia a grupos de Customers, situación fiscal o comercial, reseñas, identificadores externos y saldos o permisos propiedad de extensiones.
| Área del registro | Responsable | Evidencia | Condición de preparación |
|---|---|---|---|
| Identidad del Customer | Atención al cliente o responsable de CRM | Lista de duplicados y excepciones | Cada cuenta conservada tiene una decisión de identidad clara. |
| Grupos de Customers | Responsable comercial | Matriz de grupo frente a visibilidad, impuestos y descuentos | El significado del grupo está documentado más allá de su etiqueta. |
| Direcciones | Responsable de datos de Customers | Direcciones reutilizables y ejemplos en Orders | Los registros de cuenta y las instantáneas históricas están separados. |
| Extensiones mayoristas o B2B | Responsable de negocio y desarrollador | Registros de empresa, rol, aprobación, precio o crédito | Las relaciones comerciales propiedad de extensiones tienen una decisión de destino. |
| Reseñas y actividad | Responsable de contenido o comercio | Relaciones representativas entre Customer y Product | Los registros generados por Customers mantienen el propietario correcto. |
| Claves externas de Customer | Responsable de integraciones | Mapa de identificadores CRM/ERP | Los sistemas que continúan pueden localizar la misma cuenta. |
La portabilidad de contraseñas debe documentarse como una característica del origen, no suponerse por la presencia de una dirección de correo electrónico. Registra el esquema de autenticación del origen y la dependencia de acceso de las cuentas sin convertir esta lista en un plan de comunicación con clientes.
Preparar Orders y evidencia comercial histórica
La preparación de Orders debe permitir interpretar las transacciones históricas. Los Orders actuales de v4 pueden incluir contexto del canal de venta, instantáneas de Products y atributos, direcciones, totales, estados, comentarios, etiquetas de pago y envío, seguimiento, reembolsos, devoluciones, facturas y referencias externas. Los módulos heredados pueden añadir filas separadas de totales o tablas de transacciones.
Selecciona Orders que representen la complejidad real de la tienda e identifica qué registros o extensiones son propietarios de cada valor histórico.
| Evidencia de Order | Acción de preparación | Condición de preparación |
|---|---|---|
| Líneas de Products y atributos | Registrar nombres, SKUs, valores seleccionados, cantidades y precios de la instantánea | El artículo comprado sigue siendo comprensible independientemente del catálogo actual. |
| Direcciones de facturación y entrega | Conservar instantáneas del momento del Order separadas de las direcciones del Customer | Las direcciones históricas de la transacción están completas. |
| Impuestos, envío, descuentos, comisiones y créditos | Inventariar cada línea material del total del Order y su módulo propietario | El total final puede explicarse sin recrear código retirado. |
| Referencias de pago y envío | Registrar etiquetas, IDs de transacción, seguimiento y propiedad del módulo | Las referencias históricas están disponibles sin tratarlas como configuración actual. |
| Estado y comentarios | Registrar significado, secuencia, fechas y visibilidad de los estados | El personal puede interpretar el proceso histórico. |
| Reembolsos, devoluciones e IDs externos | Registrar entidades relacionadas y claves de conciliación | Las relaciones posventa y con sistemas externos siguen siendo rastreables. |
No recalcules Orders antiguos a partir de la configuración actual de Products, grupos de Customers, impuestos o envíos. El paquete de evidencia debe conservar la transacción original tal como fue registrada.
Inventariar Apps, extensiones heredadas, tablas personalizadas e integraciones
Las Apps actuales de v4 y las extensiones heredadas pueden ser propietarias de campos del catálogo, grupos de Customers, totales de Orders, datos SEO, referencias de pago, ofertas de marketplaces, informes o mapeos con sistemas externos. Una lista de extensiones no basta; la preparación debe identificar los registros que crea o modifica cada componente.
| Patrón de dependencia | Evidencia que debe prepararse | Condición de preparación |
|---|---|---|
| App actual de v4 | Nombre, versión, entidades afectadas, campos/tablas e IDs representativos | Los datos activos de la App tienen propietario explícito. |
| Extensión heredada | Nombre del paquete, archivos principales modificados, cambios SQL y registros relacionados | Los datos de la extensión pueden separarse de los registros principales de osCommerce. |
| Tabla o campo personalizado | Esquema, significado comercial, claves padre y sistema consumidor | Cada valor personalizado activo tiene una decisión definida. |
| Conector con marketplace o canal de venta | IDs de listing, oferta, canal y externos | La identidad canónica del Product está separada de su representación en el canal. |
| Integración ERP/PIM/WMS/CRM | Autoridad, dirección de sincronización y claves estables | Los sistemas que continúan pueden volver a conectarse con las entidades de destino. |
| Componente abandonado | Evidencia de último uso y confirmación del responsable | Los residuos técnicos obsoletos están marcados para archivo o exclusión. |
Preparar contenido CMS, medios, SEO y evidencia de rutas
v4 actual puede gestionar contenido CMS, temas, front ends, descripciones de Products y Categories, medios y configuración SEO. Las tiendas heredadas pueden utilizar extensiones de páginas informativas, archivos estáticos, cajas de plantilla, archivos de idioma o módulos SEO. Prepara el contenido según su propietario en lugar de tratar cada página visible como una única entidad CMS.
Crea un inventario de rutas para Products, Categories, marcas, páginas CMS, páginas informativas, contenido específico de front ends y endpoints de extensiones que sean prioritarios. Registra la ruta de origen, objeto propietario, idioma, front end, metadatos, configuración canónica cuando exista, importancia para el negocio y tratamiento previsto.
Haz una copia de seguridad de imágenes originales, descargas, documentos, recursos de temas y archivos de contenido. Registra las relaciones de adjuntos y URLs externas. Un volcado de base de datos puede conservar nombres de archivo sin incluir los archivos originales.
Construir el paquete de copias de seguridad y preparación de entradas
Crea un paquete restaurable vinculado a un único estado del origen.
| Componente del paquete | Responsable | Evidencia | Condición de preparación |
|---|---|---|---|
| Copia de seguridad de base de datos | Administrador de base de datos | Volcado con marca temporal, prefijo y nota de generación del origen | Se incluye el esquema completo previsto. |
| Archivos y medios | Responsable de alojamiento o técnico | Archivo de archivos o árbol de origen accesible | Medios originales, descargas, extensiones y código personalizado están disponibles. |
| Registro de linaje | Responsable técnico | Historial de versión/fork y notas de actualización | Las estructuras heredadas y actuales pueden interpretarse correctamente. |
| Registro de acceso | Responsable del proyecto | Propietario del acceso y estado de conexión | El acceso necesario está disponible sin publicar credenciales. |
| Registro de cambios | Administrador de la tienda | Cambios estructurales posteriores al corte de evidencia | Los cambios tardíos pueden incorporarse de manera deliberada. |
Seleccionar muestras representativas para las pruebas de migración
Prepara un manifiesto de muestras con IDs de origen, propietario, motivo comercial, archivos relacionados y relaciones esperadas en el origen. El conjunto debería exponer tanto estructuras actuales de v4 como estructuras específicas heredadas cuando existan. El manifiesto de osCommerce está preparado cuando cada expectativa del origen, dependencia de linaje, archivo vinculado e identificador está completo y asignado a un revisor.
Incluye como mínimo:
- un Product sencillo y otro con varias asignaciones de Category o front end;
- Products con atributos, propiedades, combinaciones configurables, descargas, proveedores y precios por grupo;
- Customers de grupos relevantes, transacciones de invitados y cuentas mayoristas o propiedad de extensiones;
- Orders con atributos, varios totales, reembolsos, seguimiento, comentarios y referencias externas;
- rutas prioritarias de CMS, Product, Category, marca y propiedad de extensiones;
- un registro actual de App o extensión heredada que contenga datos comerciales;
- un registro cuyo significado difiera entre la generación de origen y v4 actual.
Aplicar la puerta final de preparación de osCommerce
| Pregunta de preparación | Resultado requerido |
|---|---|
| ¿Está confirmado el linaje del origen? | Están registrados versión, rama o fork, base de datos, front ends, extensiones y personalizaciones. |
| ¿Está completo el alcance del catálogo? | Products, Categories, marcas, proveedores, canales, stock, precios y medios tienen propietarios definidos. |
| ¿Están clasificados atributos y propiedades? | Las relaciones seleccionables, descriptivas, configurables y personalizadas están separadas. |
| ¿Pueden interpretarse Customers y Orders? | Están documentados grupos, direcciones, totales, estados y referencias externas. |
| ¿Están clasificadas Apps y datos personalizados? | Los registros activos propiedad de extensiones tienen decisiones explícitas de destino. |
| ¿Están inventariados contenido y rutas? | CMS, contenido heredado, medios y URLs importantes están vinculados con sus objetos propietarios. |
| ¿Están listos las copias de seguridad, el acceso y las muestras? | El paquete del origen es restaurable y los IDs representativos están listados. |
La preparación permanece abierta mientras una tabla heredada crítica, una asignación de canal, una regla de grupo de Customers, un módulo de total de Order o un identificador externo siga sin propietario y sin una decisión definida.
Conclusión
Preparar osCommerce es tanto un ejercicio de linaje como un inventario de datos. Los Products, front ends, grupos de Customers, atributos, propiedades, contenido CMS y Apps de v4 actual deben distinguirse de tablas heredadas, extensiones comunitarias y código modificado.
Un paquete controlado del origen hace explícitos estos límites y proporciona registros representativos para configurar y validar la migración.
Preguntas frecuentes
¿Por qué debe confirmarse primero la versión o fork de osCommerce del origen?
v4 actual y las instalaciones heredadas de osCommerce pueden almacenar e interpretar de manera diferente datos de catálogo, Customers, Orders, contenido y extensiones. El linaje de versiones determina qué relaciones y tablas son realmente propietarias de los registros de origen.
¿Qué diferencia de preparación existe entre atributos y propiedades?
Los atributos suelen representar valores seleccionables o configurables de Product y pueden afectar precio, peso, inventario o descargas. Las propiedades describen características estructuradas utilizadas para presentación, filtros, búsqueda o comparación.
¿Cómo deben documentarse las asignaciones por canal de venta o front end?
Registra qué Products, Categories, contenido, idiomas y URLs pertenecen a cada front end. Los registros compartidos y los específicos de un canal deberían poder verse en una matriz de alcance.
¿Deben copiarse tablas de extensiones heredadas directamente a campos actuales de osCommerce v4?
No automáticamente. Primero identifica la extensión, el significado comercial, el registro padre y el consumidor que seguirá utilizándolo. Una función moderna con una etiqueta similar puede no usar el mismo esquema ni comportamiento.
¿Qué Orders deben incluirse en una muestra de osCommerce?
Incluye Orders de invitados y registrados, varios estados, selecciones de atributos, descuentos, impuestos, envíos, referencias de pago, reembolsos, comentarios, seguimiento y totales creados por extensiones o IDs externos.
¿La copia de seguridad de la base de datos contiene imágenes, descargas y archivos de extensiones de osCommerce?
No. Prepara el árbol de archivos correspondiente junto con la base de datos para que los medios, archivos descargables, temas, Apps, extensiones heredadas y código personalizado sigan disponibles.