Cloud: revisa las licencias antes de contratar

Contratar un servidor cloud con licencias correctas empieza por un expediente de derechos, no por una pantalla que diga «activado». La propuesta debe identificar qué productos se usarán, bajo qué modalidad, en qué infraestructura y con qué usuarios o dispositivos. Después se comprueba que esos derechos correspondan al despliegue y al contrato concretos.

La idea útil es sencilla: conserva un inventario, una matriz de asignación y evidencia contractual. Lo que requiere cuidado son los detalles. Una licencia comprada para un escenario no debe suponerse válida para cualquier nube, una suscripción no incluye necesariamente todos los servicios de soporte y una factura no describe por sí sola todos los derechos de uso. Esta guía organiza las preguntas; no emite un dictamen jurídico ni sustituye las condiciones del fabricante.

Resultado que buscas: una propuesta en la que cada producto tenga una modalidad documentada y una persona responsable. Si una fila sigue sin aclararse, registra el pendiente y no lo conviertas en un «incluido» implícito. En el expediente trabajado verás una incompatibilidad de versión que impide aceptar la configuración inicial y cómo se cierra sin confundir una promesa con evidencia.

Consulta por tema: tres comprobaciones · modalidades · matriz de licencias · crecimiento y salida.

El flujo en texto: identifica cada producto y quién aporta sus derechos; contrasta uso, destino y evidencia. Si falta información o existe una discrepancia, no aceptes esa configuración: asigna responsable, obtén respuesta y repite la revisión. Si las filas se resuelven, conserva el alcance y las referencias revisadas. Un cambio posterior de versión, destino o uso vuelve a abrir las filas afectadas.

1. Separa derecho, activación y compatibilidad

El derecho de uso surge de las condiciones aplicables al producto y a su adquisición o servicio contratado. Debe contrastarse con el uso previsto. La activación es un mecanismo técnico que puede formar parte del producto; observar que funciona no resuelve todas las preguntas contractuales. La compatibilidad requiere comprobar versiones y funciones del sistema: disponer de derechos no demuestra que una integración vaya a funcionar.

Las condiciones generales de software de Microsoft separan derechos de uso y medidas técnicas de activación. Escribe las tres conclusiones por separado. Por ejemplo: «documentación pendiente del despliegue alojado», «estado técnico por verificar» y «versión admitida por el fabricante de la aplicación». Eso resulta más claro que marcar todo como aprobado porque el programa abrió una vez.

En productos Microsoft, los Product Terms permiten consultar derechos y modelos de licencia por producto, programa y publicación. La propia página indica que debe seleccionarse el programa y que la aplicación de actualizaciones depende del acuerdo del cliente. No copies la primera ficha que aparezca como si fuera el contrato de todas las empresas.

2. Haz el inventario por producto y función

Empieza por el sistema operativo, el motor de base de datos y la aplicación de negocio. Añade componentes que suelen quedar fuera de una cotización inicial: acceso remoto, módulos adicionales, herramientas de respaldo, agentes y productos de administración. Incluye también entornos de prueba o contingencia que existirán realmente, sin asumir que se cubren igual que producción.

Para cada elemento, distingue lo que ya tiene la empresa de lo que aportaría el proveedor. Indica quién custodia la evidencia y quién puede resolver una duda con el fabricante o distribuidor. No hace falta publicar claves, números de serie ni documentos completos en la matriz que circula para comparar ofertas: usa referencias a un repositorio interno autorizado.

• Producto exacto: nombre, edición y versión; no sólo «Windows», «SQL» o «ERP».
• Uso previsto: producción, prueba, acceso de usuarios, servicio alojado u otra función documentada.
• Destino: proveedor, tipo de entorno y referencia de VM o host según corresponda.
• Métrica: la definida por los términos aplicables, sin convertir usuarios concurrentes en usuarios autorizados automáticamente.
• Responsabilidad: quién contrata, asigna, revisa renovaciones y conserva evidencia.

La capacidad técnica se estudia por separado. Reducir recursos para que una cifra parezca más barata puede perjudicar el funcionamiento y no necesariamente cambiar la métrica contractual como esperas. No hay un porcentaje universal de holgura de CPU o memoria que determine si una licencia es correcta.

3. Compara modalidades sin asumir portabilidad

Los nombres comerciales ayudan a orientar la conversación, pero el derecho concreto depende del producto y del acuerdo. Pide al oferente que identifique la modalidad y sus límites con evidencia, no que sólo escriba «licencias incluidas» al final de la propuesta.

Licencias aportadas por el proveedor

Pregunta qué producto, edición y uso cubre la cuota, quién es el licenciatario y qué ocurre al terminar el servicio. En Microsoft SPLA, el proveedor obtiene derechos para ofrecer determinados servicios de software; la guía oficial identifica al proveedor, no al usuario final, como licenciatario en ese escenario. No equivale a que el cliente reciba una licencia perpetua transferible.

La guía oficial de SPLA remite a los SPUR para derechos por producto y establece condiciones del programa. Tampoco debe presentarse como un permiso para alojar cualquier producto en cualquier nube: el proveedor debe confirmar la elegibilidad del despliegue y de los terceros que participan.

Licencias propias de la empresa, o BYOL

BYOL describe que pretendes aportar derechos existentes; no demuestra que sean elegibles para el destino. Comprueba producto, programa, modalidad de adquisición, condiciones de externalización y requisitos adicionales que correspondan. La orientación oficial de Microsoft sobre outsourcing distingue escenarios y proveedores, así como opciones específicas de movilidad y virtualización. No todos se aplican a todas las licencias.

Una respuesta útil identifica el supuesto que se está usando y la evidencia pendiente. «Ya pagamos el software» o «el servidor es dedicado» no deberían cerrar la revisión sin examinar los términos aplicables.

Suscripción directa o combinación de esquemas

Documenta duración, renovación, cambio de cantidad y derechos al terminar. No presupongas descuento, soporte técnico completo o actualización a cualquier versión por el hecho de pagar una suscripción. Si combinas productos del proveedor con licencias propias, cada fila necesita su propia evidencia; no basta una etiqueta general para todo el servidor.

Qué pedir según la ruta elegida

1. Todo lo aporta el proveedor: solicita un anexo por producto, su modalidad y los límites de uso. Si la respuesta es sólo «licencias originales», todavía faltan alcance y responsabilidad.
2. La empresa aporta licencias: primero identifica el producto y acuerdo; después contrasta su elegibilidad con el destino exacto. No empieces por instalar para ver si activa.
3. Hay una mezcla: une ambos expedientes y comprueba las dependencias. Por ejemplo, que la versión del host aportado sea compatible con el acceso remoto que pretende aportar la empresa. Una fila válida por separado puede no servir en la combinación propuesta.

La salida de este recorrido es una lista de evidencias y decisiones pendientes, no un resultado automático de cumplimiento. La distinción entre externalización y movilidad está desarrollada en la guía de outsourcing de Microsoft; los términos concretos siguen dependiendo del producto y programa.

El acceso remoto merece una comprobación específica. Microsoft distingue CAL por usuario o dispositivo y SAL en escenarios de proveedor. Evita traducir «diez sesiones simultáneas» a «diez licencias» sin verificar el modelo. Tampoco asumas que una licencia de acceso de cualquier versión sirve para cualquier host: revisa la compatibilidad de versiones de RDS CAL documentada por Microsoft. La cantidad y la compatibilidad deben validarse para la modalidad real.

4. Usa una matriz que deje visibles los pendientes

La matriz no es un certificado. Sirve para enlazar uso, condiciones y evidencia, y para que un responsable resuelva discrepancias antes de contratar. Repite esta ficha por producto y modalidad; si un mismo producto tiene usos diferentes, separa las filas en lugar de esconderlos en una nota.

Abrir ficha de derechos y asignación

• Producto, edición y versión: ___
• Función y entorno de uso: ___
• Titular o licenciatario y modalidad contratada: ___
• Proveedor y destino VM/host, mediante referencia interna: ___
• Métrica aplicable y cantidad justificada: ___
• Usuarios, dispositivos u otros elementos cubiertos, según el modelo: ___
• Programa, documento de términos y publicación consultados: ___
• Evidencia de adquisición o inclusión en servicio, mediante referencia: ___
• Renovación, vigencia y responsable de seguimiento: ___
• Condiciones relevantes para pruebas, contingencia o traslado: ___
• Estado: comprobado, pendiente o no aplicable con justificación: ___
• Pregunta pendiente, destinatario y fecha de resolución: ___

Expediente trabajado: una propuesta mezclada que todavía no puede aceptarse

Ejemplo completamente hipotético, no cliente ni validación real. Una empresa quiere alojar un ERP, un motor SQL Server comercial y acceso remoto para doce personas que trabajan en dos turnos. Su propuesta inicial indica Windows Server 2025 aportado por el proveedor; la empresa pretende usar derechos propios del motor y doce RDS CAL 2022 por usuario. El ERP tiene una suscripción separada. Los datos son entradas del ejercicio, no una recomendación de arquitectura ni una cuenta universal de licencias.

La responsable interna reúne contratos y coordina respuestas; el proveedor identifica su oferta; el fabricante o canal competente aclara las condiciones que le corresponden. Que sólo seis personas se conecten a la vez no transforma automáticamente las doce identidades en seis licencias: la métrica debe corresponder al modelo contratado. Microsoft explica la diferencia entre RDS CAL por usuario y por dispositivo; aquí el supuesto elegido es por usuario, no concurrencia.

Fila 1. Sistema operativo aportado por el proveedor

• Entrada: cotización que dice «Windows Server 2025 incluido», sin identificar todavía edición, modalidad ni condiciones de salida.
• Pregunta y responsable: el proveedor debe precisar esos elementos y confirmar el escenario alojado y sus obligaciones.
• Evidencia solicitada: anexo identificable de la oferta, que conecte producto y despliegue con la modalidad aplicable. No se pide compartir claves en una hoja pública.
• Resultado inicial: pendiente documental. Que la máquina esté activada no reemplaza el anexo. Si se usa SPLA, los derechos del proveedor y los SPUR deben revisarse en su contexto, como explica la guía oficial del programa.

Fila 2. Motor SQL Server aportado por la empresa

• Entrada: existe una factura antigua, pero falta confirmar edición, versión, programa, métrica y derechos para ese destino.
• Pregunta y responsable: la persona que custodia las licencias debe localizar el acuerdo y obtener la aclaración de elegibilidad con el canal competente; el proveedor aporta la identidad y características del alojamiento necesarias para contrastarlo.
• Evidencia solicitada: referencia del acuerdo, producto y derechos aplicables; cálculo de cantidad según esa métrica, no según una cifra improvisada de memoria o sesiones.
• Resultado inicial: no se acepta la suposición BYOL. La documentación de externalización diferencia opciones que no son intercambiables. No elegimos un modelo de SQL Server en este ejercicio porque las entradas todavía no lo justifican.

Fila 3. Acceso remoto con discrepancia decisiva

• Entrada: RDS CAL 2022 por usuario frente a un host Windows Server 2025.
• Comprobación: la matriz oficial de compatibilidad indica que las CAL 2022 no habilitan acceso a un host 2025. Disponer de doce no corrige esa diferencia de versión.
• Resultado inicial: la configuración propuesta no se acepta en esos términos. Hay que revisar una alternativa compatible y su modalidad, o una plataforma diferente que también admita el ERP. No se cambia la versión del servidor por intuición.
• Qué cambia la decisión: una propuesta revisada con acceso de versión compatible y derechos aplicables documentados, no una prueba de inicio de sesión. Si el servicio pasa a una modalidad del proveedor, se vuelve a comprobar esa modalidad; no se llama CAL a cualquier acceso contratado.

Fila 4. ERP con suscripción independiente

• Entrada: suscripción de la aplicación, pero sin confirmación de uso alojado, componentes requeridos ni compatibilidad de la versión propuesta.
• Pregunta y responsable: el fabricante o responsable contractual del ERP debe confirmar derechos y condiciones; el equipo técnico revisa por separado la matriz de compatibilidad y funciones necesarias.
• Evidencia solicitada: contrato o términos de la aplicación, documentación de versión e identificación de módulos cubiertos.
• Resultado inicial: pendiente. No se atribuyen reglas de Microsoft a una aplicación de otro fabricante ni se da por hecho que la cuota del ERP cubra Windows, SQL Server y acceso remoto.

Decisión de la primera revisión: no aceptar la propuesta tal como está. Hay una discrepancia objetiva de versión en RDS y tres filas con información que falta. «Cuatro productos instalados» no equivale a «cuatro productos documentados». Un pendiente documental no prueba por sí solo un uso ilegal; sí impide concluir que el expediente está completo.

Cómo cerraría el mismo ejercicio: el proveedor entrega un anexo revisado del sistema operativo; la revisión de SQL Server concluye que no puede darse por acreditado el BYOL con lo disponible y se solicita otra modalidad documentada en la oferta; la propuesta conserva el host 2025 y sustituye las CAL 2022 por CAL 2025, con cantidad, elegibilidad y derechos documentados para el escenario concreto; el fabricante del ERP confirma el escenario y versión. La responsable interna registra las referencias y verifica que la nueva cotización corresponde a esas cuatro decisiones. En el caso ficticio, ése sería el punto para aceptar el alcance documentado, sujeto a la revisión contractual autorizada, no para emitir un certificado universal.

Contraprueba: si sólo se cambia la versión de las CAL y SQL Server continúa sin modalidad acreditada, se cierra la discrepancia de versión de la fila 3, pero la decisión conjunta sigue pendiente. Si, por el contrario, el proveedor propone un host 2022, la matriz RDS deja de mostrar esa incompatibilidad concreta; todavía se deben comprobar los demás derechos y que el ERP admita ese host. Ninguno de los dos cambios aprueba automáticamente las otras filas.

Qué obligaría a abrir el expediente otra vez: cambiar el destino del alojamiento, agregar un entorno, alterar los usuarios o la métrica aplicable, renovar bajo condiciones distintas o instalar una versión no contemplada. Conserva la versión aceptada de la propuesta; no la sobrescribas con una lista sin fecha que impida reconstruir la decisión.

La plantilla no envía datos ni valida licencias automáticamente. Conserva documentos y claves por los canales internos autorizados; las personas que comparan propuestas no siempre necesitan acceso a todos los secretos o datos contractuales.

5. Revisa crecimiento, migración y salida

Una matriz correcta hoy puede quedar incompleta después de un cambio. Antes de ampliar, pregunta qué sucede si aumentan recursos, usuarios o dispositivos; si se mueve una VM; si aparece un entorno adicional; o si cambia el proveedor que aloja el servicio. No todas las métricas siguen el mismo evento y no todas las reasignaciones tienen las mismas condiciones.

Incluye la salida del servicio. Aclara qué datos y configuraciones pueden recuperarse, qué derechos dejan de estar disponibles y qué tendría que contratarse para operar en el siguiente destino. La exportación de una máquina o de una copia de datos no debe confundirse con la transferencia de todas las licencias que hacían posible usarla.

También distingue una renovación comercial de una actualización técnica. Tener derechos para una versión no significa que la aplicación la soporte; continuar con una versión antigua puede plantear otras preguntas de soporte. El plan necesita responsables de ambas verificaciones.

6. Pide evidencia y servicio con alcance claro

Una propuesta comparable desglosa infraestructura, licencias y administración. Debe identificar qué está incluido, cómo se calcula, qué se renueva y qué queda pendiente. Las condiciones de soporte, parches y mantenimiento se pactan expresamente: el licenciamiento correcto no hace que los parches se instalen solos ni garantiza una respuesta del fabricante en un tiempo determinado.

Compara una VM sola con un servicio, no dos cifras incompletas

Antes de elegir, iguala el alcance: mismos productos y modalidad válida, condiciones del alojamiento, responsabilidades y tratamiento de cambios. Si una propuesta deja por resolver SQL Server o acceso remoto, su importe no es todavía comparable con una oferta que sí los incluye. Agrega esos costes comprobados o mantén la comparación como incompleta; no rellenes el hueco con cero.

Ejemplo de coste hipotético, no tarifa ni ahorro medido: después de igualar infraestructura y licencias, un servicio de administración cuesta 900 MXN mensuales más e incluye el inventario, seguimiento de renovaciones y coordinación de cambios descritos. Si valoras el trabajo interno en 300 MXN por hora, 900 ÷ 300 = 3 horas mensuales. Ése es el tiempo que tendría que ahorrar para compensar por sí solo la diferencia en este modelo simple. Con una hora evitada, el valor sería 300 MXN; con cuatro, 1,200 MXN. No se ha demostrado que el servicio ahorre esas horas.

Usa importes sobre la misma base de impuestos y periodicidad, y añade costes iniciales cuando existan. No conviertas menor carga administrativa en una garantía de uptime ni asignes a una interrupción evitada un valor inventado. Si los derechos y servicios no son equivalentes, primero resuelve la diferencia de alcance y luego calcula.

Si tu equipo ya mantiene el inventario, tiene acceso al fabricante o canal competente y puede revisar cambios y renovaciones, quizá no necesites contratar administración adicional. También puedes pedir una revisión puntual, trabajar con otro proveedor o, si la aplicación lo permite y satisface tu necesidad, comparar su modalidad SaaS. Esta última no elimina toda responsabilidad: cambia qué administra cada parte y debe contrastarse con sus condiciones.

Para separar las licencias de la capacidad y del alcance operativo, consulta la comparación de dedicado y VPS para escritorio remoto. No uses esa comparación como una regla de licenciamiento.

El acompañamiento experto puede justificar un coste mayor cuando reduce horas de inventario, coordina preguntas con los responsables y mantiene el expediente actualizado. Compara ese trabajo concreto frente a una oferta que sólo entrega una VM. No compres una promesa genérica de quedar protegido frente a cualquier auditoría.

Puedes pedir a Cobalt Blue Web u otro proveedor una propuesta que explique licencias y responsabilidades para tu escenario. Solicita confirmación escrita de lo que pueden revisar y de las dudas que requieren al fabricante o a un asesor especializado. Para iniciar esa conversación, comparte productos, versiones, modalidad que aporta cada parte y la pregunta pendiente. No envíes claves, credenciales ni contratos completos por un formulario general.

7. Usa IA para revisar coherencia, no para inventar derechos

Una herramienta de IA puede ayudar a detectar filas incompletas, comparar descripciones depuradas o convertir una duda en una pregunta para el proveedor. No le entregues claves, credenciales o acuerdos confidenciales por un canal no aprobado. Trabaja con referencias y ejemplos sintéticos siempre que sea suficiente.

Una instrucción útil sobre datos sintéticos sería: «Compara estas cuatro filas con los documentos que adjunto. Para cada diferencia, cita la sección exacta, separa lo demostrado de lo pendiente y redacta la pregunta que falta responder. Si el documento no permite concluir, escribe “no determinado”. No deduzcas derechos a partir de activación». Revisa después que las citas existan y correspondan al programa y fecha adecuados.

Exige que cualquier conclusión señale el producto, programa, documento y supuesto en que se basa. Una respuesta sin esos elementos puede sonar precisa y seguir siendo inaplicable. La decisión final debe apoyarse en los términos correspondientes y en la revisión de las personas autorizadas, no en una afirmación automática de cumplimiento.