La versión estable vigente de Dolibarr es la 24.0.2 y el proyecto publica una versión mayor cada seis meses, así que una instalación de 2021 quedó unas diez versiones atrás. Se actualiza por etapas, de una versión mayor a la siguiente y con copia de seguridad previa; si el sistema está muy modificado, a veces conviene más migrar a otro o a uno a medida.
En DCisGlobal lo vemos seguido en pymes: el ERP lo instaló alguien hace años, funciona y nadie se anima a tocarlo. El problema es el servidor. Dolibarr 14, de julio de 2021, se probó como máximo con PHP 7.4, y PHP 7.4 dejó de recibir parches el 28/11/2022.
Esta guía explica qué riesgo corre la empresa, cómo se actualiza sin perder datos y cuándo conviene cambiar de sistema.
Por qué una versión vieja de Dolibarr es un riesgo
Dolibarr es un ERP/CRM de código abierto con un proyecto activo, y eso es una buena noticia. Pero su forma de publicar versiones deja poco margen para quedarse atrás:
- No hay una versión oficial de soporte extendido (LTS). Lo dice el propio proyecto.
- Las correcciones de seguridad llegan sobre todo a las ramas recientes.
- Su política de seguridad solo acepta reportes sobre las dos últimas versiones mayores estables: hoy, la 23 y la 24.
En términos de negocio: una versión de hace tres años ya quedó fuera de lo que el proyecto se compromete a revisar.
Qué riesgos concretos corre la empresa
PHP viejo
PHP es el lenguaje en el que está escrito Dolibarr. Cada versión se prueba con un rango de PHP, así que una versión vieja obliga a mantener el servidor en un PHP sin parches.
| Versión de Dolibarr | Lanzamiento | PHP máximo probado |
|---|---|---|
| 12 a 15 | 2020 a 2022 | 7.4 |
| 16 a 18 | 2022 a 2023 | 8.1 |
| 19 y 20 | 2024 | 8.2 |
| 21 | 2025 | 8.3 |
| 22 | 2025 | 8.4 |
| 23 y 24 | 2026 | 8.5 |
El 21/10/2026, PHP corrigió dos fallas críticas conocidas como PHP2Shell, y las versiones 8.1 o anteriores no reciben esa corrección. Traducido: hasta Dolibarr 18 inclusive, el sistema no está probado sobre ningún PHP corregido.
Además, la rama 8.2 tiene soporte de seguridad solo hasta el 31/12/2026. Por eso el destino razonable hoy es Dolibarr 22 o superior. Lo ampliamos en PHP 8.1 sin soporte y en el fin de soporte de PHP 7.4.
Módulos y personalizaciones
Los módulos externos (los que no vienen con Dolibarr) y los cambios hechos a medida son el punto más frágil. La documentación oficial pide comprobar que los módulos externos sean compatibles con la nueva versión antes de actualizar.
Peor todavía si alguien modificó archivos del propio Dolibarr: la actualización sobrescribe los archivos viejos con los nuevos, y esos cambios se pierden sin aviso.
Integraciones
Facturación electrónica, tienda online, bancos, contabilidad externa. Cada integración se escribió contra una versión concreta de Dolibarr y de su API.
Al saltar varias versiones, lo que antes funcionaba puede dejar de hacerlo sin un error visible. Y como las exigencias de facturación cambian seguido, en España y en Argentina, un sistema congelado obliga a parchear por fuera.
Dependencia de quien lo instaló
Es el riesgo menos técnico y el más común. El proveedor o el empleado que montó el sistema se fue, no hay documentación y nadie sabe qué se tocó, dónde están las copias ni qué módulos se compraron.
Mientras nadie toque el sistema, eso no se nota. Cuando hay que actualizar, se vuelve el primer obstáculo.
Cómo se actualiza Dolibarr por etapas
La documentación oficial es clara en tres puntos que conviene respetar:
- Primero, la copia de seguridad. Base de datos, carpeta de documentos, carpeta /custom y el archivo de configuración conf.php.
- De versión mayor en versión mayor. El asistente repite la actualización versión por versión hasta llegar a la instalada, y por línea de comandos se pide correr el proceso una vez por cada versión mayor, en orden.
- Saltar etapas tiene trampa. Según la documentación, un salto directo de la 22 a la 24 aplica los cambios de estructura de la base, pero omite las migraciones de datos de la versión intermedia, sin mostrar ningún error.
Ese último punto es el que más nos preocupa. Un problema que no avisa aparece semanas después, en un saldo que no cierra o en un informe que no coincide.
Un ejemplo: pasar de Dolibarr 14 a 24 son diez saltos. Para eso se trabaja en una copia. PHP 7.4 entra en el rango que admiten todas las versiones de la 12 a la 24, así que la cadena puede hacerse sobre 7.4 en el entorno de prueba, nunca en producción, y subir PHP al final.
El orden que seguimos es este:
- Copia completa de base, documentos, /custom y conf.php, y prueba de que se puede restaurar.
- Clon del sistema en un entorno de prueba.
- Inventario de módulos externos y cambios en el núcleo, con su compatibilidad.
- Saltos de versión mayor en versión mayor, validando cada uno.
- PHP llevado a una versión con soporte: 8.4 o 8.5 para Dolibarr 23 o 24.
- Prueba de procesos reales: facturar, cobrar, mover stock, sacar informes.
- Repetición en producción, con plan de vuelta atrás.
Cuándo conviene migrar a otro sistema o a uno a medida
Actualizar es la opción por defecto cuando el uso es razonablemente estándar: el proyecto sigue activo y publica dos versiones mayores por año.
| Situación | Camino que solemos recomendar |
|---|---|
| Uso estándar, pocos módulos externos | Actualizar por etapas |
| Muchos módulos, pocos cambios en el núcleo | Actualizar y reemplazar los módulos incompatibles |
| Núcleo muy modificado o procesos clave en planillas por fuera | Migrar a otro sistema o a uno a medida |
| El ERP o el CRM es parte de la ventaja competitiva | Desarrollo a medida con los datos de Dolibarr |
La comparación honesta no es «viejo contra nuevo» sino cuánto cuesta cada camino en tres años. Hicimos el mismo análisis para otro sistema habitual en pymes: Vtiger en una versión vieja.
Qué hacer ahora
- Confirmar la versión exacta de Dolibarr y la de PHP del servidor.
- Recuperar los accesos al servidor, la base de datos y el panel, y saber quién tiene cada uno.
- Hacer una copia completa y comprobar que se puede restaurar.
- Listar módulos externos, cambios propios e integraciones.
- Contar cuántos saltos de versión faltan hasta la 24.
- Decidir con ese mapa (actualizar, migrar o desarrollar a medida) y ponerle fecha.
Si el servidor aloja otros sistemas, la guía para actualizar PHP en sistemas sin soporte ayuda a ordenar el resto.
Cómo lo resolvemos en DCisGlobal
Hacemos un diagnóstico tecnológico del Dolibarr: versión, servidor, módulos, cambios en el núcleo e integraciones. Con eso presentamos el plan de saltos, el riesgo de cada uno y si conviene actualizar o migrar.
Ejecutamos la actualización en un entorno de prueba, la validamos con el equipo y recién después tocamos producción. Después seguimos con soporte y mantenimiento para que el sistema no vuelva a quedar años atrás.
Ver modernización de sistemas legacy · Consultar por WhatsApp
