NexTool Solutions

GLPI open source no tiene cuota mensual, pero "sin licencia" está muy lejos de "sin costo". Comparar solo el precio de lista de GLPI self-hosted con el de un ServiceNow se equivoca en ambas direcciones: subestima lo que el self-hosted consume en operación y sobreestima lo que el SaaS entrega de fábrica. Esta comparativa pone lado a lado los cuatro modelos que más implantamos - GLPI self-hosted, GLPI Cloud, ServiceNow y Jira Service Management - en el eje que realmente mueve el TCO: la unidad de cobro y el trabajo de operación.

Los cuatro modelos, en una frase cada uno

• GLPI self-hosted (open source): software gratuito, sin límite de usuarios; pagas infraestructura y mano de obra.
• GLPI Cloud (Teclib): el mismo GLPI, alojado y mantenido por Teclib, con suscripción por técnico.
• ServiceNow: plataforma ITSM enterprise, licencia por agente bajo cotización, orientada a automatización y gobernanza a gran escala.
• Jira Service Management: el ITSM de Atlassian, suscripción por agente en planes, fuerte para quien ya vive en el ecosistema Jira/Confluence.

Los tres de pago cobran por agente o técnico: el costo crece de forma aproximadamente lineal con el tamaño del equipo de atención. El self-hosted invierte la lógica - el software es fijo en cero y el costo viene de la operación. Es esa diferencia de naturaleza, y no el precio de un mes aislado, la que decide cuál sale más barato en un horizonte de tres años.

Comparativa directa

Cuántos "agentes" pagas en realidad

Aquí está la trampa que solo aparece en el momento de la factura: en los modelos por agente, quien cuesta es el usuario con interfaz técnica (central), no el solicitante que solo abre tickets por autoservicio. Los solicitantes suelen ser ilimitados y gratuitos en los tres. Es decir, el número que define tu factura no es "cuántas personas usan GLPI", sino "cuántas tienen perfil de técnico".

En self-hosted ese número es invisible - nadie cobra por él, así que las organizaciones reparten el perfil central con holgura: el coordinador que solo quiere ver un dashboard, el gerente que "a veces necesita mirar la cola", el becario que cerró dos tickets el año pasado. Al migrar a cualquier SaaS por agente, cada uno de ellos se convierte en una línea de la factura. Antes de pedir cotización, ejecuta esta consulta en la base de datos de tu GLPI para conocer el número real:

-- ¿Cuántos "agentes" pagarías en un SaaS por agente?
-- Agente facturable = usuario con perfil de interfaz central (técnico),
-- no el usuario de autoservicio (helpdesk), que suele ser ilimitado.
SELECT COUNT(DISTINCT pu.users_id) AS agentes_facturables
FROM glpi_profiles_users pu
JOIN glpi_profiles p ON p.id = pu.profiles_id
JOIN glpi_users     u ON u.id = pu.users_id
WHERE p.interface = 'central'   -- interfaz central (excluye helpdesk)
  AND u.is_active  = 1
  AND u.is_deleted = 0;

Hemos visto ese número volver un 40% por encima de lo que el cliente estimaba "de memoria". Antes de comparar precios con SaaS, haz la limpieza: degrada a autoservicio a quien no atiende de verdad. Eso reduce la factura futura y, de paso, limpia los reportes de productividad dentro del propio GLPI.

El costo oculto que nunca entra en la hoja de cálculo

En el mantenimiento de parques GLPI para clientes, el ítem que más dispara el TCO del self-hosted no aparece en ninguna tabla: es la deuda de actualización. El cliente levanta GLPI, funciona, y nadie lo toca durante dos años. Cuando por fin necesita una función nueva o un plugin compatible, descubre que saltar de una 9.5 a una 11 no es "hacer clic en actualizar" - es migrar el esquema, revisar los plugins que se rompieron y probar en un entorno de pruebas. Lo que era mantenimiento de 2h/mes se volvió un proyecto. El error común es presupuestar el self-hosted solo por el VPS y tratar la actualización como un evento raro; es recurrente y exige una ventana, un backup probado y un entorno de pruebas.

Y está el otro costo que nadie contabiliza: el backup que existe pero nunca se restauró. En self-hosted, el DR es responsabilidad tuya por completo - y un volcado que nadie probó es un backup que no tienes. El mínimo viable es un volcado diario de la base de datos y de los archivos, con verificación periódica:

# /etc/cron.d/glpi-backup - volcado diario de la base de datos + archivos de GLPI.
# En self-hosted, el backup y el DR son 100% tuyos; un volcado nunca restaurado no cuenta.
30 2 * * *  root  mysqldump --single-transaction glpi | gzip > /backup/glpi-$(date +\%F).sql.gz
45 2 * * *  root  tar czf /backup/glpi-files-$(date +\%F).tar.gz /var/www/glpi/files
# Guarda una copia FUERA del host y prueba la restauración al menos una vez por trimestre.

En GLPI Cloud, ServiceNow y Jira SM, la actualización, el backup y la disponibilidad entran en el precio de la suscripción - eso es exactamente lo que compras al pagar por agente. La pregunta correcta no es "cuál es más barato", sino "¿ese trabajo operativo queda en mi equipo o tercerizado en la mensualidad?".

Veredicto por escenario

• Usa GLPI self-hosted cuando tienes (o contratas) a alguien que opere Linux, la base de datos y los backups, valoras la soberanía de datos y quieres un techo de costo previsible aunque dupliques el equipo de agentes. Es imbatible en costo por agente a medida que el equipo crece; si ese es tu camino, empieza por la instalación con Docker.
• Usa GLPI Cloud cuando quieres el mismo GLPI - misma base, mismos conceptos, mismos plugins compatibles - sin mantener infraestructura, y el equipo de técnicos es lo bastante pequeño para que la suscripción aún salga por debajo de un sysadmin dedicado.
• Usa ServiceNow cuando la necesidad real es automatización y gobernanza enterprise (flujos complejos, integraciones corporativas, compliance) y hay presupuesto para el nivel más alto del mercado. Contratar ServiceNow solo para abrir tickets es pagar por un avión para cruzar la calle.
• Usa Jira Service Management cuando la empresa ya funciona en Jira/Confluence y quiere el ITSM pegado a ese ecosistema, aceptando el cobro por agente y los límites de inventario/CMDB frente a GLPI.

Costo y esfuerzo, con rangos honestos

El eje de la decisión no es la licencia - es adónde va el trabajo de operación. En self-hosted, el desembolso en dinero es bajo (un VPS de unas pocas decenas a unos pocos cientos por mes, según la escala), pero exige horas técnicas recurrentes: una implantación bien hecha rara vez cabe en menos de unos pocos días de trabajo, y el mantenimiento pide una ventana mensual para actualización y verificación de backup. En los modelos por agente, el desembolso es mayor y crece linealmente con el equipo, pero las horas de operación de infraestructura tienden a cero. La cuenta de tres años suele favorecer al self-hosted cuanto mayor es el equipo de agentes y más barata es la hora técnica disponible; favorece al SaaS cuando el equipo es reducido y no hay quien opere infraestructura. No fijes un número de TCO cerrado antes de tener el total de agentes facturables y el costo real de tu hora técnica - sin esos dos, cualquier comparación es un tiro al aire.

En NexTool implantamos y mantenemos los cuatro escenarios en clientes - desde GLPI self-hosted ligero hasta el migrado a Cloud - y la decisión que más rinde es siempre la misma: dimensionar el costo por la unidad correcta (agentes facturables) y por el trabajo de operación que tu equipo puede absorber. Si quieres un TCO honesto para tu caso, sin adivinanzas de precio de lista, nuestra consultoría arma esa comparativa con tus números.

Este contenido fue producido con ayuda de inteligencia artificial y revisado por el equipo de Nextool Solutions.