OpenCart o Laravel: ya tiene una aplicación PHP

Las páginas de comparativa suelen meter OpenCart en el mismo saco que las plataformas alojadas y discutir sobre control y propiedad. Ese argumento aquí no aplica. El control ya lo tiene. OpenCart es PHP en su propio servidor, su base de datos, sus archivos, sin comisión por pedido, y nadie puede cambiarle las condiciones por debajo.

Así que la versión honesta de esta pregunta es más estrecha: tiene una aplicación PHP y se está preguntando si sigue siendo la adecuada para lo que el negocio hace ahora.

En qué es genuinamente bueno OpenCart

Conviene decirlo claro, porque suele quedarse fuera.

Un catálogo con opciones y variantes, un carrito, un checkout, reglas de impuestos y envío, una configuración multitienda, un panel que un equipo pequeño maneja sin formación. Corre sobre alojamiento barato, se ha desplegado cientos de miles de veces, y el mercado de extensiones cubre la mayoría de lo que pide una tienda en crecimiento.

Si esa descripción todavía encaja con su tienda, quédese. Sustituir un carrito que funciona por una aplicación a medida es una factura grande para un resultado que a sus clientes les parecerá similar.

Dónde empieza la pregunta de verdad

Ni en el tráfico ni en el tamaño del catálogo. Empieza cuando las reglas que necesita dejan de tratar del catálogo.

Una extensión es la forma natural para todo aquello de lo que un carrito ya tiene concepto: una regla de precio, un método de envío, una pasarela, un campo en un producto. Para eso está el modelo de extensiones, y funciona.

La forma cambia cuando la regla trata de otra cosa. Un presupuesto que se convierte en pedido tras una aprobación. Un proceso de preparación con estados por los que el personal de operaciones mueve las cosas. Precios de contrato por cliente con su propio histórico. Stock que vive en un ERP y tiene que seguir cuadrando con él. Suscripciones y prorrateo.

Nada de eso es algo que un carrito se construyera para sostener, y cada uno implementado como extensión tiene que meterse en partes del sistema no pensadas para ello. Ahí empieza el coste, y es un coste de encaje, no de defecto.

La cuestión de las modificaciones, con honestidad

Lo que más conviene medir antes que nada es cuánto se ha alejado su instalación de una estándar.

El modelo de extensiones de OpenCart ha permitido históricamente que las extensiones alteren el comportamiento del núcleo directamente. Eso es lo que lo hizo flexible y fácil de extender, y también por lo que dos tiendas en la misma versión pueden estar en estados muy distintos. Algunas están cerca del estándar y actualizan limpiamente. Otras arrastran una década de modificaciones, varias sobre los mismos archivos, instaladas por gente que ya no está disponible.

Lea eso antes de decidir nada. Es un día de trabajo y cambia la aritmética por completo, porque una tienda que actualiza limpiamente tiene una opción barata que una muy modificada no tiene. Es la misma lectura que hace una auditoría, aplicada a otra base de código.

Qué cambia una aplicación Laravel y qué no

Cambia dónde viven las reglas. Una capa de servicio, un esquema con restricciones, migraciones, una suite de pruebas, y una cola para el trabajo que no debería ocurrir dentro de una petición. Si la lógica de negocio es el producto, para eso está el framework.

No mejora por sí sola su situación de alojamiento, y no le regala un catálogo, un carrito ni un checkout. Eso se reconstruye. Ese es el coste honesto y la razón por la que empezamos preguntando si el problema de encaje es real o si son dos extensiones haciendo algo torpe.

Cómo transcurre un movimiento de verdad

Ruta a ruta, con los dos sistemas en producción, que es el enfoque y no la excepción.

OpenCart sigue sirviendo el escaparate mientras la aplicación nueva asume un grupo de rutas cada vez. Un solo sistema es dueño del pedido en cada momento, y cuál es se deja por escrito antes de mover nada. El mapa de URL va primero, porque las URL de categoría y producto son las que ganaron su tráfico, y una redirección escrita la última semana está escrita tarde.

Y el modelo de pedido entra antes que el escaparate. El escaparate es la parte más barata de cambiar después.

Si la tienda está en una plataforma alquilada y no en su propio servidor, el argumento de propiedad que aquí no aplica pasa a ser todo el argumento, y esa es otra página.