Cuando la nube suena a hosting más barato

13 min de lectura

La ilusión de la infraestructura

La conversación casi siempre empieza igual.

El dueño habla con un cliente que pregunta: “¿Tienen una versión en la nube?” Alguien de ventas pierde un contrato porque “TI no quiere otra instalación on-prem”. Un consultor suelta “cloud migration” como si fuera un trabajo de fin de semana. Alguien reenvía un gráfico sobre márgenes de SaaS (Software as a Service: usted lo opera para sus clientes). Un competidor lanza una versión SaaS.

Luego llega la pregunta real, de la persona que tiene que pagar sueldos: “¿Nos estamos quedando atrás?”

El mismo malentendido termina en el foso regularmente, vea Es Solo una Reescritura Simple — Una Historia de Estimaciones, Egos y Éxito Eventual.

El primer pensamiento es tentador. Ya tiene software que funciona. Ya tiene clientes. Los proveedores de nube ofrecen infraestructura. Así que mueve la aplicación de los servidores del cliente a sus servidores en un centro de datos. Listo. ¿No?

No. Y el error es predecible.

Cuando lleva años vendiendo software on-premise, la nube parece un detalle de infraestructura. Su software funciona. Sus clientes lo usan. Moverlo a infraestructura centralizada se siente como una tarea técnica, no como una transformación del negocio.

Instalar no es operar

On-premise no se “lanza” desde su lado en el sentido moderno. Lo instala el cliente.

Alguien ejecuta un instalador. Un administrador programa una ventana de mantenimiento. Un usuario clave prueba. Luego se quedan en una versión durante mucho tiempo porque actualizar se siente como riesgo.

Esa gravedad de las actualizaciones no es un detalle. Define el producto.

Realidad on-premise:

• El cliente decide cuándo instalar una versión nueva.
• Muchos clientes no lo hacen hasta que algo se rompe o una función importante los obliga.
• Usted mantiene varias versiones en paralelo porque no tiene opción.
• Puede corregir un defecto y aun así seguirá vivo en producción, porque los clientes van meses o años atrasados.

Realidad SaaS:

• Usted decide cuándo una versión entra en producción.
• Cada lanzamiento afecta a todos.
• Usted opera CI/CD (integración continua y entrega continua) y despliegue continuo como modo normal de trabajo. Muchos equipos publican cambios varias veces al día.
• Compatibilidad hacia atrás y migración de datos pasan a ser su problema, cada vez.
• “Publicamos y que el cliente actualice” deja de ser una estrategia.

Cuando esto se entiende, la nube deja de sonar a ganga y empieza a sonar a una segunda empresa.

Lo que realmente está proponiendo

Cuando dice “vamos a la nube”, esto es lo que realmente está diciendo, le guste o no:

Está pasando de vender un producto a operar un servicio. El software on-premise se entrega una vez por cliente. Usted entrega, el cliente instala, y corre en su infraestructura. Su responsabilidad suele terminar en el soporte de instalación.

El software en la nube corre continuamente en su infraestructura para todos los clientes. Ahora usted es responsable de disponibilidad, rendimiento, seguridad, copias de seguridad, recuperación ante desastres y respuesta a incidentes. 24 horas al día. 7 días a la semana. Para siempre.

Se convierte en custodio de datos. Antes, los datos vivían en servidores del cliente. Si perdían datos, era su problema de backups. Si sufrían una brecha, era su problema de seguridad.

Ahora usted guarda todos los datos del cliente. Usted es responsable de protegerlos, respaldarlos y cumplir.

En Europa eso significa GDPR, más lo que aplique a sus clientes (reglas sectoriales, expectativas de residencia de datos, requisitos de auditoría). En Estados Unidos puede significar HIPAA (salud), PCI DSS (pagos), GLBA (servicios financieros) y un montón creciente de leyes de privacidad estatales.

Si hace esto mal, no recibirá solo un correo desagradable. Recibirá reguladores, penalizaciones contractuales y clientes que no volverán a confiar.

Acepta una carga operativa continua. En on-premise, el producto puede acumular defectos. Los clientes los reportan. Usted los corrige en la siguiente versión. La urgencia suele ser baja porque los clientes usan versiones estables y deciden si actualizan.

En SaaS hay que vigilar todo el tiempo. Problemas de rendimiento afectan a todos a la vez. Vulnerabilidades se parchean inmediatamente. Migraciones de base de datos deben ocurrir sin interrupciones. Cada cambio introduce riesgo para toda su base de clientes.

Pasa de licencias perpetuas a suscripciones. No es solo un cambio de precio. Es un cambio de relación con el cliente, flujo de caja y reconocimiento de ingresos.

En on-premise, el cliente compra una licencia, a menudo paga mantenimiento anual y trata grandes saltos de versión como una compra nueva o un proyecto. El atraso de versiones es normal.

En SaaS, el cliente paga continuamente. Espera mejoras continuas. También espera que usted no rompa sus flujos de trabajo un martes por la mañana. “Actualice cuando quiera” deja de existir. La cancelación es una métrica que ya no puede ignorar.

Nada de esto es obvio cuando mira precios de AWS y piensa: “Podemos operar esto más barato que nuestros clientes sus propios servidores”.

La brecha de habilidades que nadie presupone

Su equipo de desarrollo ha estado construyendo funcionalidades para un producto on-premise. Conoce el dominio. Conoce la base de código. Publica dos versiones al año.

Operar un servicio en la nube requiere habilidades distintas:

Lanzamientos continuos. Ya no puede publicar dos veces al año. Necesita pipelines automatizados, despliegues graduales, feature flags y procedimientos de rollback. Los lanzamientos deben ser seguros varias veces al día.

Observabilidad. Necesita logs, métricas, trazas y alertas en todo el stack. Cuando algo falla, tiene minutos para diagnosticar y arreglar, no días. Debe saber cómo se ve lo normal.

Respuesta a incidentes. A las 03:00 de un domingo, cuando la base de datos empieza a expirar, alguien debe investigar, mitigar y corregir. Necesita guardias, runbooks, revisiones post incidente y la disciplina para usarlos.

Operación de seguridad. Parchear vulnerabilidades de inmediato. Gestionar secretos de forma segura. Rotar credenciales. Monitorear intrusiones. Responder incidentes. Pasar auditorías. No es opcional. Es el precio de manejar datos de clientes.

Ingeniería de rendimiento. Cuando todos comparten infraestructura, el pico de un cliente afecta a los demás. Necesita aislamiento, planificación de capacidad, autoescalado y monitoreo de rendimiento. “Funciona en mi laptop” deja de ser aceptable.

Operación de bases de datos. Migraciones de esquema sin interrupciones. Verificación real de backups. Monitoreo de replicación. Optimización de consultas bajo carga. Recuperación a un punto en el tiempo. Son habilidades especializadas que quizás su equipo no tenga.

¿Sus tres desarrolladores que publicaban dos veces al año? No saben hacer esto por arte de magia. Su soporte tampoco. Y usted probablemente tampoco.

La entrega predecible requiere prácticas técnicas que generen resultados de negocio, no solo buenas intenciones.

El modelo de soporte se transforma

El soporte on-premise es reactivo. Un cliente llama con un problema. Usted ayuda a diagnosticar. Si es un defecto, se corrige en la próxima versión. Si es configuración, se guía al cliente. El problema queda aislado.

En SaaS, el soporte es proactivo y universal. Usted debe detectar problemas antes de que los clientes los reporten. Cuando publica una versión con defectos, todos los clientes la sufren al mismo tiempo.

Para sobrevivir a ese ritmo, necesita orquestación: actualizaciones progresivas sin tiempo de inactividad, lanzamientos por cohortes de clientes, canary releases, feature flags, pruebas A/B y la capacidad de revertir rápido cuando la realidad contradice el plan.

Cuando el rendimiento cae, todos se enteran.

Su equipo de soporte, acostumbrado a incidentes de clientes individuales, debe pensar en salud de plataforma. Dashboards con métricas globales. Distinguir entre problema de un cliente y un incidente general. Coordinar con desarrollo durante los lanzamientos.

Esto requiere herramientas nuevas, procesos nuevos y habilidades nuevas. El soporte deja de ser “El cliente A no puede imprimir facturas” y pasa a ser “El rendimiento de la base de datos cayó 40% en la última hora: ¿qué clientes están afectados?”

La estructura de costos de la que nadie habla

El discurso comercial de la nube promete infraestructura más barata. Nada de servidores caros en el cliente. Operación centralizada significa economías de escala. Menos costos, mejor margen.

Hay que ser precisos con ese discurso y con quién fue diseñado.

“La nube es más barata” es la historia del hyperscaler para proveedores de software que ya operan SaaS y ya cargan con el peso operativo. Ellos comparan su propio centro de datos con alquilar capacidad.

Si usted viene de on-premise, no está haciendo esa comparación. Está comprando la entrada a una nueva línea de negocio: operaciones.

La realidad es más cara de lo que casi cualquiera presupone:

Costos de infraestructura. No solo hospeda la aplicación. Necesita producción, staging, desarrollo y recuperación ante desastres. Necesita monitoreo, logging, almacenamiento de backups y redundancia. La factura mensual de AWS crece más rápido que el número de clientes.

Personal operativo. Necesita DevOps, administradores de base de datos, especialistas de seguridad y capacidad de SRE. No es opcional. Es lo mínimo para operar un servicio con seguridad.

Seguridad y cumplimiento. Obligaciones de GDPR. Auditorías ISO 27001 (o equivalentes, según sus clientes). Pruebas de penetración. Escaneo de vulnerabilidades. Cifrado. Controles de acceso. Consultoría. Todo suma.

Compensación por guardias. Si espera que la gente responda a las 03:00, tiene que pagar disponibilidad. Las guardias no son voluntariado.

Mayor velocidad de desarrollo. Dos lanzamientos al año ya no alcanzan. Competidores publican diariamente. Necesita integración continua, pruebas automatizadas y ciclos más rápidos. Eso exige herramientas mejores y mucha más disciplina.

La infraestructura puede ser más barata por cliente. El costo operativo total es mucho más alto.

Lo que sus clientes realmente obtienen

Usted vende esta transición como “el mismo software, ahora en la nube”. Los clientes escuchan “comodidad” y “menos carga de TI”.

Lo que realmente obtienen:

Pérdida de control. No pueden elegir cuándo actualizar. No pueden personalizar la instalación. No pueden correr versiones modificadas. Dependen por completo de su competencia operativa.

Destino compartido. Si su servicio cae, su negocio se detiene. Si su base de datos tiene problemas, sus datos quedan inaccesibles. Si usted envía defectos, ellos sufren las consecuencias.

Dependencia de suscripción. No pueden dejar de pagar sin perder acceso a sus datos. Quedan atados a su precio. Son vulnerables a aumentos.

Su estrategia de precios puede empujar igual. Espere cancelaciones de clientes que valoraban más el control.

La migración que nadie planeó

Mover instalaciones on-premise existentes a su servicio SaaS suena simple. El cliente exporta datos, usted los importa y listo.

En la práctica, migrar es una pesadilla:

Consistencia de datos. Cada cliente tiene años de datos, a menudo con esquemas ligeramente distintos por versiones instaladas a lo largo del tiempo. Necesita scripts de migración para cada versión, cada caso borde y cada personalización.

Ventanas de interrupción. Clientes con operación 24/7 no toleran cortes. Necesita estrategias de migración en línea con ambos sistemas corriendo durante la transición.

Pruebas. ¿Cómo verifica que los datos migrados están correctos? Las pruebas automatizadas solo cubren una parte. Verificación manual sobre cientos de clientes es irreal.

Rollback. Cuando la migración falle a mitad de camino, y va a fallar, ¿cómo revierte sin perder datos?

Carga de soporte. Cada cliente migrando necesita acompañamiento. Su soporte, ya saturado, ahora carga también con migraciones.

Gobernar la modernización de sistemas legados con éxito requiere tratar la migración como un proyecto serio, no como una tarea de fin de semana.

Las licencias perpetuas generan ingresos grandes al inicio. Un cliente paga 50.000 € una vez. El ingreso se reconoce de inmediato. El flujo de caja es predecible. El mantenimiento anual da una base estable.

El ingreso por suscripción es lo contrario. Un cliente paga 500 €/mes. Usted no recibe el dinero por adelantado. La cancelación siempre acecha. Necesita más clientes para reemplazar el mismo ingreso de licencias.

Muchos proveedores subestiman el periodo de transición. Durante dos a cinco años sostienen ambos modelos: clientes on-premise con mantenimiento y nuevos suscriptores. Los ingresos bajan. Los costos suben. Y deja de ser teoría: se vuelve flujo de caja.

Todavía tiene nómina. Todavía tiene obligaciones de soporte. Todavía tiene clientes en versiones viejas que llamarán el viernes por la tarde con un problema en producción y esperan que usted responda.

Si esto se siente como fracaso, es porque durante un tiempo se ve como fracaso. Es la curva J de una transformación de modelo de negocio. Requiere reservas y disciplina que muchos dueños subestiman, porque el día a día ya consume todo.

Lo que realmente se necesita

Pasar de on-premise a la nube es posible. Solo que no es barato y no es un proyecto secundario. Para que funcione, hay que dejar de engañarse sobre lo que implica:

Inversión operativa. Presupueste DevOps, administradores de base de datos, especialistas de seguridad y capacidad de SRE antes de salir a producción. Operar un servicio con un equipo dedicado solo a funcionalidades es una receta para el desastre.

Desarrollo de habilidades. Invierta en formación sobre arquitectura en nube, observabilidad, respuesta a incidentes y seguridad. No es formación opcional. Es supervivencia.

Cambio cultural. Su cultura de ingeniería debe pasar de “dos lanzamientos al año” a “operar un servicio continuamente”. Eso requiere incentivos nuevos, procesos nuevos y liderazgo.

Doble pista. Planee operar on-premise y SaaS en paralelo durante años, no meses. Presupueste la carga duplicada.

Paciencia financiera. La suscripción tarda años en superar la licencia. Asegure runway.

Empatía con el cliente. No todos quieren nube. Ofrezca opciones híbridas. Respete preocupaciones sobre control y soberanía de datos.

Experiencia en migración. Contrate especialistas en migración de datos. Construya pruebas robustas. Planifique fallos. No trate la migración como un detalle.

El camino hacia adelante

La nube no es simplemente hosting más barato. Es una transformación de empresa: de proveedor de producto a operador de servicio.

Si va a hacer este cambio, entienda esto:

Es más difícil de lo que parece. La infraestructura es la parte fácil. La disciplina operativa, el cambio cultural y el modelo de negocio determinan el éxito.

Su equipo actual no está listo. Es bueno construyendo funcionalidades. Operar un servicio requiere otras habilidades. Invierta en formación o contratación antes de salir.

La transición financiera duele. Presupueste años de doble operación y presión de ingresos antes de que la suscripción supere a las licencias.

No todos los clientes seguirán. Algunos prefieren control. Algunos legalmente no pueden usar servicios en la nube. Planifique la pérdida.

Los competidores que nacieron en la nube tienen ventaja. Construyeron disciplina operativa desde el día uno. Usted la está incorporando a un producto y una cultura existentes. Eso es más difícil.

Las empresas que ganan dejan de fingir que es solo infraestructura. Invierten en operación. Entrenan equipos. Hablan con honestidad a los clientes. Se tragan dolor a corto plazo para sobrevivir a largo plazo.

Las empresas que fracasan lo tratan como migración técnica. Subfinancian operación. Subestiman el cambio cultural. Creen que las capacidades existentes alcanzan. Luego se sorprenden cuando el servicio es inestable, los clientes se van y los costos se disparan.

La nube no es magia. Es otro modelo de negocio con otras exigencias, otra economía y otros riesgos. Respételo, o terminará en el cementerio de empresas tradicionales de software que creyeron que el hosting era lo difícil.