El bundling de IA: lo que explica el alza del 46 %
Desde finales de 2024, los grandes proveedores de SaaS han adoptado una estrategia común: integrar funcionalidades de IA en cada nivel de suscripción y repercutir después el costo del cómputo GPU sobre el conjunto de los usuarios. El enfoque no distingue entre quienes utilizan esas funciones y quienes no las usan nunca.
Los datos de PricePulse para el H1 2026 ilustran la magnitud del fenómeno. Atlassian registra el alza más marcada, con +153 %, impulsada por la migración forzada de las licencias Server y Data Center hacia Jira Cloud, donde Atlassian Intelligence viene activada de fábrica. Notion muestra +88 % tras rebautizar su oferta «Notion AI» y reposicionar la IA como un componente del plan estándar: ya no existe ningún plan sin ella. Asana avanza un +127 % en sus niveles Business y Enterprise, ahora centrados en los «AI Studio» y los flujos de trabajo automatizados. HubSpot (+50 %) ha introducido Breeze, su motor de IA, en la práctica totalidad de sus hubs.
El mecanismo subyacente es idéntico en cada caso. El proveedor descompone primero la IA en funcionalidades aparentemente opcionales: resúmenes, sugerencias, automatizaciones. Luego las vuelve progresivamente inaccesibles en los niveles de gama baja, forzando un salto de plan. Por último, elimina la posibilidad de contratar un plan sin IA, con lo que el sobrecosto se vuelve estructural y permanente. Para un equipo de 50 personas repartido entre varias herramientas, la factura mensual supera a veces el presupuesto anual de infraestructura que habría requerido una stack autoalojada equivalente.
Lo que el self-hosting cambia para su equipo
- Control de la partida de costos — usted paga el VPS, no una licencia por usuario que sube con cada actualización del roadmap del proveedor.
- Sin bundling impuesto — usted elige qué funcionalidades correrán en su infraestructura, incluido si integra o no un modelo de IA local por su cuenta.
- Datos alojados dentro de su perímetro — cumplimiento del RGPD simplificado: ningún encargado del tratamiento adicional que declarar por cada herramienta, ninguna negociación de DPA que rehacer en cada renovación tarifaria.
- Previsibilidad presupuestaria — un VPS bien dimensionado cuesta lo mismo en enero que en diciembre, sea cual sea la estrategia de precios del proveedor al año siguiente.
- Libertad de versión — usted fija la versión que conviene a sus procesos y actualiza cuando está listo, no cuando el proveedor retira el soporte de la anterior.
- Ninguna dependencia de la supervivencia del proveedor — una adquisición, un giro de estrategia o un cierre no pone sus datos en peligro: siguen en su servidor.
SaaS 2026 vs open source: lo que cambia
Desplace la tabla
| Herramienta SaaS | Alza H1 2026 | Equivalente OSS | RAM mín. |
|---|---|---|---|
| Jira | +153 % | Plane | 2 GB |
| Notion | +88 % | AppFlowy | 1 GB |
| Slack | ~+35 % | Mattermost | 2 GB |
| HubSpot CRM | +50 % | Odoo (CRM) | 4 GB |
Qué herramientas se autoalojan bien
No todas las herramientas se autoalojan con el mismo nivel de madurez. Este es un panorama por categoría.
Mensajería de equipo. Mattermost es la referencia: desplegable con un solo binario o mediante Docker, admite webhooks, integraciones CI/CD y videollamadas a través de un plugin. Element (Matrix) es una alternativa más descentralizada, adecuada para equipos distribuidos entre varias entidades jurídicas.
Gestión de proyectos. Plane ofrece una interfaz cercana a Jira, con sprints, issues y roadmaps. Se despliega con Docker Compose y cuenta con una API documentada. GitLab (edición Community) también cubre los proyectos si su equipo ya trabaja con Git. Forgejo, fork de Gitea, es una opción ligera para los equipos centrados en el código.
Almacenamiento y colaboración documental. Nextcloud sigue siendo la solución más completa: compartición de archivos, edición colaborativa con Collabora u OnlyOffice, calendario, contactos y videoconferencia. Funciona con 2 GB de RAM en configuración mínima y 4 GB para equipos activos.
Analytics. Plausible y Umami se alojan con facilidad y no transmiten ningún dato a terceros. Metabase encaja para la BI interna sobre sus propias bases de datos.
CRM. Odoo Community cubre las ventas, los contactos y la facturación. Consume más recursos (4 GB como mínimo), pero sigue siendo el equivalente funcional más completo frente a HubSpot para equipos comerciales estructurados.
Antes de migrar: tres preguntas que responder
Antes de lanzar nada, tres preguntas estructuran la decisión.
¿Sus datos son críticos y exportables? Compruebe que la herramienta SaaS actual ofrece una exportación completa —CSV, JSON o API— y que el formato es legible por el equivalente open source al que apunta. Algunos proveedores limitan la exportación a los planes superiores o imponen un plazo. Pruebe la exportación antes de comprometerse con la migración, no durante.
¿La migración es reversible? Defina un punto de retorno: ¿durante cuánto tiempo mantiene la suscripción SaaS en paralelo con la instancia autoalojada? De dos a cuatro semanas permiten detectar los usos olvidados (integraciones, notificaciones, accesos móviles) sin quedar atrapado. Una migración irreversible hecha con prisas es la principal causa de fracaso.
¿Su equipo cuenta con las competencias de mantenimiento? El self-hosting traslada a su infraestructura la responsabilidad de las actualizaciones de seguridad, las copias de seguridad y el monitoreo. Si ningún miembro del equipo puede asumir esas tareas, hay que formar, delegar en un proveedor o reconsiderar la decisión. No es un obstáculo insalvable, pero sí un costo real que integrar en la comparación.
Migrar en 6 pasos
Inventario de las herramientas existentes
Enumere cada herramienta SaaS activa, el número de licencias, el costo mensual y el uso real. Una herramienta pagada para 50 usuarios pero utilizada por 10 es una candidata prioritaria a la migración o a la eliminación.
Elección del equivalente open source
Para cada herramienta seleccionada, identifique la alternativa OSS más madura y compare las funcionalidades imprescindibles (no la lista exhaustiva, sino los usos diarios reales). Consulte la documentación de importación para comprobar la compatibilidad de los formatos de exportación del SaaS.
Despliegue de prueba en un VPS dedicado
Monte la herramienta en un VPS de prueba separado del futuro entorno de producción. Compruebe el rendimiento bajo una carga realista, configure HTTPS con un certificado válido y pruebe las integraciones esenciales (email, webhooks, SSO si aplica).
Exportación y limpieza de los datos del SaaS
Lance la exportación desde el SaaS actual, compruebe la integridad del archivo obtenido y limpie los datos si es necesario (duplicados, contactos archivados, tickets cerrados hace más de un año). Una importación de datos limpios evita reproducir el desorden acumulado.
Importación y validación en entorno de preproducción
Importe los datos en la instancia de prueba y valide con un subconjunto de usuarios: al menos un representante por caso de uso de negocio. Documente las diferencias funcionales detectadas y decida si cada una es bloqueante o aceptable.
Cambio de DNS y comunicación a los equipos
Apunte el subdominio de la herramienta al VPS de producción y comunique la fecha del cambio a los usuarios con una guía de primera conexión. Mantenga el acceso al SaaS en modo de solo lectura durante dos a cuatro semanas antes de cancelar la suscripción.
Respalde sus datos del SaaS antes de cancelar la suscripción, no justo antes de la migración. Los proveedores eliminan rápido las cuentas dadas de baja —a veces en un plazo de 30 días— y después la exportación deja de estar accesible. Pruebe siempre la migración completa en un VPS de preproducción distinto antes de tocar el entorno de producción: una importación que falla a medio camino en una base vacía es recuperable; el mismo error en producción no siempre lo es.
Lo que el self-hosting no hace por usted
Migrar al self-hosting reduce la factura del SaaS, pero traslada responsabilidades que hasta entonces asumía el proveedor.
Las actualizaciones de seguridad. Un SaaS parcheado en 72 horas tras la publicación de una CVE crítica es una promesa que asume el proveedor. En su VPS, es su procedimiento de actualización el que determina su ventana de exposición. Hace falta una rutina de seguimiento de los avisos de seguridad de las herramientas desplegadas y un procedimiento de actualización probado, no solo documentado.
El monitoreo y las alertas. Una instancia de Mattermost en silencio desde hace 3 horas porque el contenedor Docker se cayó no avisa por sí sola. Hace falta una supervisión externa (check HTTP, alerta ante ausencia de respuesta) distinta del propio servidor, y una guardia o una notificación configurada para los incidentes nocturnos.
La formación de los usuarios. La interfaz de Plane no es Jira, la de AppFlowy no es Notion. La migración técnica puede ser perfecta y la adopción fracasar por falta de acompañamiento. Prevea como mínimo una guía de inicio rápido y una sesión de familiarización para los usuarios menos cómodos con las herramientas.
Tres frenos habituales y cómo superarlos
Tres obstáculos aparecen sistemáticamente en las primeras migraciones.
La configuración SSL. Obtener un certificado válido para un subdominio alojado en un VPS es sencillo con Let's Encrypt y Certbot, pero la configuración automática de la renovación se olvida a menudo. Configure la renovación automática desde el primer despliegue, compruebe que se ejecuta (cron o systemd timer) y pruebe manualmente el comando de renovación antes de que el certificado caduque.
El rendimiento bajo carga. Una herramienta mal dimensionada se vuelve lenta a medida que el equipo la adopta. La regla general: empiece con el doble de la RAM mínima indicada en la documentación y observe después el uso real durante las dos primeras semanas. Es más sencillo redimensionar un VPS que justificar una degradación de la experiencia ante los usuarios.
El email transaccional. Las notificaciones por email (restablecimiento de contraseña, alertas de asignación, resúmenes diarios) requieren un servidor SMTP configurado. No utilice el servidor de correo del dominio principal para estos envíos: prefiera un servicio dedicado al email transaccional (Mailgun, Postmark, Brevo) que gestione la entregabilidad, los rebotes y la reputación del dominio de forma separada de su correo corporativo.
Qué VPS elegir para empezar
El dimensionamiento depende del número de herramientas desplegadas simultáneamente y del tamaño del equipo.
Para dos herramientas (p. ej. Mattermost + Plane) y menos de 20 usuarios activos, basta un VPS de 4 GB de RAM y 2 vCPU. Docker Compose permite gestionar los dos servicios en la misma máquina con recursos reservados por contenedor, lo que evita que una herramienta monopolice toda la memoria disponible en los picos.
Para cinco herramientas o más, o para equipos de 20 a 50 personas, un VPS de 8 GB de RAM y 4 vCPU ofrece un margen cómodo. Añada un volumen de bloque dedicado al almacenamiento de los datos (separado del disco del sistema): eso simplifica las copias de seguridad y el eventual traslado a un servidor más potente sin tener que migrar el sistema operativo.
En ambos casos, Docker Compose sigue siendo el punto de partida recomendado: los archivos de configuración versionados en un repositorio Git constituyen por sí solos una documentación de infraestructura, y actualizar la versión de una herramienta se reduce a modificar el tag de la imagen y a relanzar el contenedor.
