Lo que tenía que ser a medida, y por qué.
El catálogo de un operador de retiros de bienestar no encaja en los valores por defecto del e-commerce. Un retiro no es un producto: es un paquete acotado por fechas que combina alojamiento, comidas e instrucción en una única unidad comprable. El instructor principal no es el autor de un producto; es la razón por la que un huésped reserva. El vocabulario sánscrito de la marca y los módulos de filosofía no son un blog; son una capa de contenido que se sitúa junto a la tienda y da a la decisión de compra su contexto.
Construimos la plataforma sobre PrestaShop 1.7.4 a finales de 2018, con cuatro módulos específicos del dominio y un tema por defecto fuertemente personalizado. El módulo de paquetes de retiro modelaba ofertas multifecha y multicomponente con selección de fechas y configuración de componentes; nada en el ecosistema de PrestaShop se acercaba. El módulo de aprendizaje de sánscrito tenía sus propias tablas de base de datos, rutas de frontend y panel de administración: una superficie de vocabulario y filosofía que el operador podía editar de forma independiente del catálogo. Un módulo de revendedores rastreaba agencias socias B2B con registros de contacto, país y divisa.
El flujo de checkout se sobrescribió —67 anulaciones de clases y controladores en su punto máximo— porque las compras de retiros tienen reglas de validación distintas a las de los checkouts de bienes físicos. No puedes comprar dos plazas en un retiro sin seleccionar fechas. No puedes dejar un campo de componente vacío y avanzar al pago.
Pequeñas cosas que mantuvieron viva la plataforma.
Los años dos a seis no fueron dramáticos. Cambios de proveedor de pagos. Ajustes de RGPD. Adiciones de transportistas. Actualizaciones del runtime de PHP integradas a lo largo del proyecto. Algún texto nuevo ocasional, nuevos formatos de retiro, nuevos socios B2B incorporados a través del módulo de revendedores. El tipo de mantenimiento que no da para una página de proyecto pero que es el contenido real de un proyecto de siete años.
La mayoría de las plataformas a medida no sobreviven a esta fase. El equipo que las construyó se ha ido. Los módulos están sin documentar. Las anulaciones de clases son código misterioso. Cada subida de dependencia es una tirada de dados.
La plataforma sobrevivió porque las mismas personas estaban en ella. Cuando un cambio de proveedor de pagos requería modificar la anulación del checkout, el ingeniero que escribió la anulación hizo el cambio. Cuando una actualización del runtime de PHP rompió dos constructores de módulos, sabíamos qué constructores comprobar. El conocimiento institucional sobre un código base tiene un valor compuesto que solo aparece cuando algo se rompe, y algo siempre acaba rompiéndose.
- F · 01Tipo de producto paquete de retiro
- Paquetes multicomponente acotados por fechas (alojamiento, comidas, instrucción) modelados en un módulo de PrestaShop a medida. Sin equivalente estándar.
- F · 02Capa de contenido de aprendizaje de sánscrito
- Separada de la tienda y del blog: sus propias tablas de base de datos, rutas de frontend y panel de administración para contenido de vocabulario y filosofía.
- F · 03Capa de revendedores B2B
- Seguimiento de agencias socias con registros de contacto, país y divisa. Reservas enrutadas a través del módulo de revendedores sin tocar el flujo público de la tienda.
- F · 04Flujo de checkout personalizado
- 67 anulaciones de clases y controladores en su punto máximo, modelando reglas de validación específicas de retiros —selección de fechas, configuración de componentes— que el checkout por defecto no impone.
- F · 05Mantenimiento continuo
- Siete años de cambios de proveedor de pagos, ajustes de RGPD, actualizaciones de envío y actualizaciones del runtime de PHP, todos gestionados por el equipo que escribió los módulos originales.
- F · 06Migración de versión mayor en curso
- PrestaShop 1.7.4 → 1.7.8.11 completada en producción; 1.7.8.11 → 8.2.3 en una fase avanzada de staging. Cada anulación vuelta a probar, cada módulo con una pasada de compatibilidad con PHP 8.x. La migración es el trabajo que justifica la custodia.
La migración que se está ejecutando ahora.
El fin de vida de PrestaShop 1.7 forzó una elección en 2025: replataformar o migrar. Replataformar significa tirar siete años de trabajo de módulos específicos del dominio y empezar de nuevo sobre un stack distinto. Defendimos la migración. El operador estuvo de acuerdo.
La migración se ejecuta en dos etapas. La primera —PrestaShop 1.7.4 → 1.7.8.11— aterrizó antes y está en producción. La segunda —1.7.8.11 → 8.2.3— es el salto más difícil: PrestaShop 8 movió más vistas a Twig y cambió el sistema de anulaciones lo suficiente como para que las 67 anulaciones de clases y controladores deban volver a probarse o refactorizarse. Cada módulo a medida necesita una pasada de compatibilidad con PHP 8.x.
Solo octubre de 2025 produjo 245 commits en la rama de migración a 8.2.3. El trabajo se ejecuta en un entorno de staging ramificado con datos de producción replicados. Cada flujo de checkout, cada configuración de paquete de retiro, cada ruta de contenido en sánscrito se está probando contra la nueva versión antes de que se abra la ventana de cambio. La migración es metódica y lenta porque el rastro de auditoría que deja importa tanto como el código actualizado.
La razón por la que la migración es posible —y se mantiene dentro de presupuesto— es que el equipo que la hace escribió los módulos originales. No descubrimos la complejidad; ya éramos sus dueños.
El argumento para seguir con el mismo equipo en la actualización.
Siete años. Un solo equipo de principio a fin. Una migración de versión mayor actualmente en una fase avanzada de staging.
La plataforma en producción hoy ejecuta PrestaShop 1.7.8.11 con el módulo de paquetes de retiro, la superficie de aprendizaje de sánscrito, la capa de revendedores B2B y el flujo de checkout personalizado intactos. La rama 8.2.3 es el siguiente paso: la migración que se resiste a ser tratada como un sprint de una semana, y la parte que nadie planifica al inicio de un proyecto de plataforma a medida.
El valor de un proyecto largo sobre una plataforma a medida no es la construcción inicial. Cualquiera puede construir la primera versión. El valor es el contexto acumulado: saber qué anulación es portante, qué supuesto de un módulo se hará añicos bajo una nueva versión del framework, de qué clase de PHP depende el paso de pago de un modo que la documentación no menciona. Ese contexto no se transfiere a un equipo nuevo con un encargo de migración. Vive en las personas que escribieron el código. La migración que ahora está en staging es posible —y sobrevivible— porque el mismo equipo es dueño del código original.
Ellos escribieron los módulos. Eran el equipo adecuado para migrarlos.