Seguir en Vtiger 5.x, 6.x o 7.x es trabajar sobre un CRM que ya no recibe versiones nuevas y que, en la mayoría de los casos, corre sobre un PHP sin parches de seguridad. La salida es diagnosticar primero y después elegir entre actualizar Vtiger a la línea 8, migrar, blindar el servidor mientras se planifica o replantear con un sistema a medida.
Un dato para dimensionar: la última versión de la línea 7, la 7.5.0, salió en noviembre de 2022, y la 6.5.0 es de julio de 2016. Desde entonces, la edición open source solo publica versiones de la línea 8. La vigente es la 8.4.0, del 9 de julio de 2025, pensada para PHP 8.
En DCisGlobal vemos un patrón repetido. La empresa creció apoyada en el CRM, el CRM se quedó quieto y hoy nadie quiere tocarlo porque «funciona». El problema es que funcionar no es lo mismo que estar a salvo.
Por qué una versión vieja de Vtiger es un problema de negocio
El CRM guarda lo más sensible de una pyme: clientes, contactos, presupuestos, oportunidades, historial de ventas y muchas veces correos. Si ese sistema se cae o se filtra, no se pierde un programa: se pierde la memoria comercial de la empresa.
Una versión vieja no falla de golpe. Se va quedando atrás en tres frentes a la vez: seguridad, soporte e integraciones. Cada frente, por separado, parece manejable. Juntos, frenan la operación.
Además, Vtiger corre sobre PHP, el lenguaje de programación del servidor. La versión de Vtiger define qué PHP se puede usar, y ahí está buena parte del riesgo:
| Línea de Vtiger | Años de publicación | PHP para el que se pensó | Qué significa hoy |
|---|---|---|---|
| 5.x | 2009 a 2012 | PHP 5 | PHP 5.6, la última de PHP 5, no tiene soporte desde el 31/12/2018 |
| 6.x | 2014 a 2016 | Época de PHP 5 | Misma situación: base sin parches desde hace años |
| 7.0 a 7.4 | 2017 a 2021 | PHP 5.x y 7.x, sin soporte oficial para PHP 8 | PHP 7.4 no tiene soporte desde el 28/11/2022 |
| 7.5 | 2022 | Primera de la línea 7 con soporte para PHP 8 | Sin versiones nuevas desde 2022 |
| 8.x (vigente: 8.4.0) | 2023 a 2025 | PHP 8.x | Línea activa; conviene confirmar la versión exacta de PHP del servidor |
Qué implica no tener soporte ni parches
Sin soporte significa que, cuando aparece una falla nueva, nadie publica la corrección para esa versión. La falla queda abierta y además es pública, que es la peor combinación.
Pasa en dos capas. En Vtiger, las líneas 5, 6 y 7 no reciben versiones nuevas. En PHP, el 21/10/2026 se corrigieron dos fallas críticas, conocidas como PHP2Shell, solo en las versiones 8.2, 8.3, 8.4 y 8.5. Un Vtiger que corre sobre PHP 7.4 u 8.1 no recibe esa corrección oficial. Lo explicamos en qué es PHP2Shell y qué hacer.
En términos de negocio, el riesgo deja de ser teórico. El CRM suele estar publicado en internet para que el equipo comercial entre desde cualquier lugar. Un servidor expuesto con software sin parches es un blanco fácil.
También hay un tema de cumplimiento. El propio sitio de Vtiger recuerda que las normativas piden usar software con soporte. Ante un incidente con datos de clientes, un CRM sin parches es difícil de justificar.
El costo oculto de quedarse
Quedarse parece no costar nada porque no llega ninguna factura. Pero el costo existe y se paga todos los meses:
- Horas de IT apagando incendios: parches caseros, reinicios, copias a mano.
- Integraciones que no se hacen: facturación, tienda online, mensajería o correo. Cada conector nuevo pide versiones modernas.
- Servidor congelado: no se puede actualizar el sistema operativo ni PHP sin romper el CRM, así que todo el servidor envejece con él.
- Dependencia de una persona: el único que sabe cómo está armado.
- Datos atrapados: reportes que se arman a mano en planillas porque el CRM no los resuelve.
Ninguno de estos costos aparece en el balance. Aparecen como lentitud, como oportunidades que no se siguen y como proyectos que se postergan «hasta que cambiemos el CRM».
Señales de que ya hay que actuar
- La versión empieza con 5, 6 o 7. Se ve en el pie de página o en la configuración del CRM.
- El servidor corre PHP 8.1 o anterior. Lo detallamos en PHP 8.1: fin de soporte y en PHP 7.4: fin de soporte.
- El correo dejó de sincronizar o hubo que desactivar el lector de correo. Los proveedores exigen métodos de acceso más modernos, y Vtiger 8.4 incorporó cambios de autenticación (OAuth) en ese módulo.
- Hay módulos personalizados que nadie se anima a tocar.
- Para conectar algo nuevo, la respuesta siempre es «con esta versión no se puede».
- No hay copias de seguridad probadas, o nadie sabe cuánto tarda restaurarlas.
Con dos o más de estas señales, el tema ya no es técnico: es de continuidad del negocio.
Actualizar, migrar, blindar o replantear: cómo decidir
No hay una única respuesta. Hay cuatro caminos, y en DCisGlobal los elegimos según dos preguntas: cuánto se personalizó el CRM y qué va a necesitar la empresa en los próximos años.
Actualizar a Vtiger 8.x
Conviene cuando Vtiger sigue reflejando cómo vende la empresa y las personalizaciones son pocas. Desde la 7.x el salto es más directo. Desde la 5.x o la 6.x suele haber pasos intermedios y hay que revisar cada módulo propio. Siempre se actualizan a la par el servidor y PHP.
Migrar a otro CRM
Tiene sentido cuando el proceso comercial cambió y Vtiger ya no lo acompaña, o cuando la empresa prefiere no mantener un servidor propio. Lo crítico es la migración de datos: contactos, historial, adjuntos y relaciones entre registros. Vemos lo mismo en ERP como Dolibarr, que tratamos en Dolibarr: actualizar una versión vieja.
Blindar mientras se planifica
El blindaje (hardening) es una medida de transición, no una solución. Se limita quién puede entrar al CRM, se aísla el servidor, se refuerzan los accesos y se arman copias de seguridad probadas. Compra tiempo para decidir sin apuro.
Replantear con un sistema a medida
Aplica cuando el CRM se convirtió en el corazón operativo: lógica propia, integraciones con facturación o producción y flujos que ningún producto estándar resuelve bien. Ahí un desarrollo a medida puede ser más simple de mantener que un Vtiger lleno de parches.
| Si tu empresa… | Camino que suele convenir |
|---|---|
| Usa Vtiger casi estándar y su proceso no cambió | Actualizar a 8.x |
| Cambió su forma de vender o no quiere servidor propio | Migrar |
| Necesita tiempo para decidir o presupuestar | Blindar ya y decidir después |
| Depende de muchas personalizaciones e integraciones | Replantear a medida |
Qué hacer ahora
- Confirmar la versión exacta de Vtiger y la de PHP del servidor.
- Hacer una copia completa (base de datos y archivos) y probar que se puede restaurar.
- Listar personalizaciones, módulos e integraciones: qué se usa todos los días y qué quedó en desuso.
- Reducir la exposición: que el CRM no quede abierto a todo internet.
- Elegir el camino con un diagnóstico tecnológico y un plan por etapas.
- Ejecutar primero en un entorno de prueba y recién después tocar producción.
El panorama general de PHP está en nuestra guía para actualizar PHP en sistemas sin soporte.
Cómo lo resolvemos en DCisGlobal
Empezamos por un diagnóstico del Vtiger y del servidor: versión, personalizaciones, integraciones y nivel de riesgo. Con eso proponemos el camino y un plan por etapas, con el CRM funcionando mientras tanto.
Hacemos la actualización o la migración, el blindaje del servidor y, si hace falta, el desarrollo a medida. Después lo acompañamos con soporte y mantenimiento para que no vuelva a quedar viejo.
