Microsoft Software Assurance: qué incluye y cuándo compensa realmente

Qué es Microsoft Software Assurance en 2026

Software Assurance es una cobertura asociada a determinadas licencias de software de Microsoft adquiridas mediante programas de licenciamiento por volumen. Puede comprarse junto con la licencia, renovarse cuando ya existe cobertura o, en ciertos escenarios expresamente autorizados, añadirse como SA-only dentro del plazo aplicable. No está disponible de la misma forma para todos los canales, productos o mercados.

Open Value incluye SA y Open Value Subscription concede derechos durante la vigencia de la suscripción. En acuerdos como EA, EAS, SCE o MPSA, la disponibilidad depende de la inscripción y del producto. Microsoft indica además que SA como cobertura separada no está disponible bajo Microsoft Cloud Agreement o Microsoft Customer Agreement. Una suscripción puede conceder derechos equivalentes o ser elegible para Azure Hybrid Benefit, pero eso no la convierte en Software Assurance ni en una licencia perpetua.

También conviene separar tres conceptos. Los derechos de licencia determinan qué puede ejecutar la organización. Software Assurance añade derechos mientras la cobertura está activa. Los servicios cloud, por su parte, se rigen por sus propias condiciones y consumo. Mezclarlos conduce a errores de presupuesto y, en una auditoría, a asignaciones que no pueden justificarse.

La licencia perpetua cubierta conserva, al finalizar SA, los derechos perpetuos ya consolidados, incluida la última versión disponible durante el periodo de cobertura. Sin embargo, desaparecen los beneficios que exigen SA activa: futuras versiones, determinadas movilidades, derechos específicos de virtualización o failover y la elegibilidad continuada para Azure Hybrid Benefit, según el producto.

Qué incluye actualmente Software Assurance

No existe un catálogo idéntico para todos los productos. La tabla de beneficios de cada entrada en Product Terms decide qué derechos se conceden. Los siguientes son los más relevantes, siempre sujetos a elegibilidad.

Derechos de nuevas versiones

New Version Rights permite utilizar una versión nueva que Microsoft publique mientras SA esté activa. Si la cobertura termina, una licencia perpetua puede seguir utilizando la versión más reciente que quedó disponible durante ese periodo, pero no versiones publicadas después. Este derecho no garantiza compatibilidad, migración técnica ni soporte indefinido, y tampoco eleva automáticamente la edición. Una licencia Standard no se transforma en Datacenter o Enterprise solo porque aparezca una nueva versión.

Step-up a una edición superior

Las licencias Step-up permiten pasar de una edición inferior a otra superior únicamente cuando la ruta figura como elegible. La licencia base y el Step-up deben mantener cobertura continua de SA o una suscripción que cumpla las condiciones. No se generan dos licencias independientes: el conjunto pasa a representar la edición superior. Antes de presupuestarlo hay que comprobar producto, edición, modelo Core o Server/CAL y programa contractual.

License Mobility y virtualización flexible

License Mobility across Server Farms permite reasignar ciertos productos servidor dentro de la misma granja tantas veces como sea necesario. Entre granjas se aplica normalmente la regla de 90 días. License Mobility through Software Assurance es diferente: permite ejecutar aplicaciones servidor elegibles en servidores compartidos de un Authorized Mobility Partner, con SA activa y un proceso de verificación. La asignación al servidor compartido debe mantenerse al menos 90 días.

Este beneficio general no cubre el sistema operativo Windows Server, Windows client ni aplicaciones desktop. Tampoco debe confundirse con el Flexible Virtualization Benefit para infraestructura compartida de Authorized Outsourcers, que excluye a los proveedores incluidos por Microsoft en su lista de Listed Providers. Para una estrategia multicloud, el nombre del proveedor y el marco jurídico aplicable importan tanto como la tecnología.

Disaster Recovery y failover

Los productos servidor elegibles pueden incorporar derechos de recuperación ante desastres, pero cada familia puede sustituir o ampliar la regla general. Una instancia de DR no equivale por defecto a una réplica activa gratuita. Deben verificarse la actividad permitida, las pruebas, la simultaneidad, el emplazamiento y la cobertura de las licencias primarias. SQL Server, por ejemplo, tiene reglas específicas para alta disponibilidad y OSE de failover que explicamos más adelante.

Azure Hybrid Benefit

Azure Hybrid Benefit, o AHB, permite aplicar licencias core elegibles de Windows Server o SQL Server con SA activa, o determinadas suscripciones, a recursos Azure compatibles. Reduce el componente de licencia incluido en el servicio; no elimina el coste de cómputo, almacenamiento, red, reserva ni otros consumos. La cobertura debe mantenerse y las cantidades asignadas deben respetar cores, vCores, ratios y mínimos.

Durante una migración existe una concesión general de uso simultáneo on-premises y Azure de 180 días. Fuera de esa ventana no debe asumirse doble uso indefinido. Si SA deja de renovarse, Azure indica que debe retirarse la selección AHB de los recursos afectados.

Otros derechos dependientes del producto

Algunas entradas pueden conceder Self Hosting, virtualización avanzada, equivalencias o derechos ampliados de CAL, Windows VDA, MDOP o Extended Security Updates bajo condiciones específicas. ESU no debe describirse como un suministro gratuito e ilimitado de parches para cualquier producto con SA. Su disponibilidad, compra y alcance dependen del producto al final de soporte y de los términos vigentes.

Beneficios históricos que ya no deben incluirse

Muchas páginas, presentaciones y comparativas antiguas siguen mostrando un catálogo más amplio. Para una decisión en 2026 hay que retirar de la ecuación los siguientes elementos:

• Planning Services: retirado el 1 de febrero de 2021.
• Training Vouchers: retirado el 1 de febrero de 2021.
• 24x7 Problem Resolution Support: Microsoft anunció su retirada a partir del 1 de febrero de 2023, con desaparición progresiva al vencer los acuerdos.

La organización puede tener soporte, formación o consultoría por contratos separados, servicios de partner o suscripciones distintas. Lo que no debe hacer es atribuirlos automáticamente a SA. Lo mismo aplica a referencias históricas a Home Use Program o e-learning. Una página comercial heredada no amplía los derechos concedidos por Product Terms.

Coste de Software Assurance y cómo calcular el ROI

No existe un precio universal que pueda aplicarse con rigor a todas las organizaciones. El coste depende del producto, la edición, las unidades, el programa, el acuerdo, la duración, el mercado, la moneda y las condiciones negociadas. Por esa razón, una evaluación seria utiliza la cotización real de renovación y no un porcentaje genérico encontrado en internet.

El ROI tampoco debe basarse en la posibilidad abstracta de usar todos los beneficios. Debe valorar los derechos que la organización probablemente ejercerá durante el periodo contractual. Un modelo práctico puede estructurarse así:

1. Coste incremental: importe neto de SA, administración contractual y trabajo necesario para mantener inventario y evidencias.
2. Valor de actualización: coste evitable de adquirir licencias nuevas si aparece y se desplegará una versión durante la cobertura.
3. Valor de arquitectura: coste de licencias que sería necesario sin movilidad, virtualización, failover o DR elegibles.
4. Valor cloud: reducción real del componente de licencia mediante AHB, calculada con recursos, regiones, uptime y reservas previstos.
5. Valor de flexibilidad: coste y riesgo evitados al poder hacer un Step-up o reorganizar cargas dentro de las reglas.
6. Riesgo de no uso: probabilidad de retrasar proyectos, mantener versiones actuales o no consumir Azure como se había previsto.

Conviene modelar al menos un escenario base, uno conservador y uno de transformación. El ahorro de AHB debe obtenerse de la calculadora y factura Azure de la organización, no de una cifra promocional. El valor de una actualización debe compararse con la fecha probable de lanzamiento, pruebas, compatibilidad y despliegue. Un derecho que existe pero no puede implementarse dentro del ciclo de SA tiene valor financiero limitado.

Tres casos donde SA exige un análisis distinto

Windows Server: edición, cores y ubicación

En Windows Server, SA puede aportar nuevas versiones, AHB, DR y derechos de virtualización vinculados a modelos concretos. No concede movilidad general del sistema operativo mediante License Mobility through SA. Además, Standard y Datacenter conservan diferencias fundamentales: con licenciamiento físico, Standard permite dos OSE por cada conjunto completo de licencias, mientras Datacenter permite OSE ilimitados en el servidor correctamente licenciado.

Windows Server 2025 incorpora el modelo por Virtual OSE únicamente para suscripciones o licencias con SA activa. Exige un mínimo de ocho licencias core por Virtual OSE y que las CAL correspondientes también estén cubiertas por SA o suscripción. En el modelo físico siguen aplicando mínimos de ocho cores por procesador y dieciséis por servidor. Por tanto, SA puede ser valiosa en clústeres dinámicos, pero no elimina el recuento de cores, OSE y CAL.

Para AHB en una máquina virtual Azure, ocho licencias core elegibles cubren hasta ocho vCores y dieciséis cubren hasta dieciséis; por encima se asignan cantidades adicionales en incrementos de ocho. Windows Server Standard debe utilizarse on-premises o en Azure, salvo la concesión de migración de 180 días. Datacenter ofrece modalidades adicionales, pero no debe resumirse como doble uso ilimitado.

SQL Server: virtualización, alta disponibilidad y ratios

SQL Server suele concentrar el ROI más visible y también el mayor riesgo de simplificación. Enterprise Core con SA puede habilitar virtualización ilimitada cuando se licencian correctamente todos los cores físicos. El licenciamiento por Virtual OSE requiere SA o suscripción activa y un mínimo de cuatro cores por OSE. Si la densidad de máquinas cambia, ambas alternativas deben compararse con un inventario real de hosts y cargas.

Por cada Primary Workload, los términos actuales contemplan un Fail-over OSE para cualquier propósito, incluida alta disponibilidad, y dos OSE de failover específicamente para DR: uno en cualquier servidor y otro en Microsoft Azure, sujeto a las reglas y proporciones de AHB. Las instancias no pueden convertirse en cargas activas ordinarias ni servir datos a usuarios fuera de lo expresamente permitido. Hay simultaneidad limitada para pruebas breves una vez cada 90 días, durante un desastre y durante la transición entre OSE.

En Azure SQL Database y SQL Managed Instance, AHB se aplica al modelo vCore con provisioned compute, no a DTU ni serverless. Para destinos elegibles, Enterprise con SA puede tener una relación de un core a cuatro vCores en General Purpose y de uno a uno en Business Critical. Standard utiliza uno a uno en General Purpose y cuatro cores por un vCore en Business Critical. No todas las licencias SQL reciben una relación uno a cuatro, y Server/CAL no debe tratarse como Core sin una regla expresa.

Azure: ahorro condicionado, no nube gratuita

En Azure, la pregunta correcta no es “¿tenemos SA?”, sino “¿qué licencias elegibles, en qué cantidad y durante cuánto tiempo podemos asignar a qué recursos?”. Hay que mapear cada licencia a una VM o servicio admitido, mantener cobertura activa y documentar la asignación. AHB puede combinarse con reservas, pero ambos mecanismos resuelven componentes diferentes del coste.

License Mobility y AHB tampoco son sinónimos. AHB aplica ratios y ventajas económicas en destinos Azure, incluidos escenarios PaaS. License Mobility permite asignar determinadas aplicaciones servidor a infraestructura compartida de partners siguiendo verificación y permanencia. Elegir el mecanismo incorrecto puede inflar el ahorro esperado o dejar una arquitectura sin respaldo contractual.

Si estás comparando escenarios híbridos, consulta también nuestra guía de Azure Hybrid Benefit, la explicación de licenciamiento de Windows Server y el análisis de licencias de SQL Server.

Cuándo compensa realmente Software Assurance

Situaciones favorables

• Existe una actualización probable dentro del periodo y la organización tiene capacidad real para desplegarla.
• La arquitectura de Windows Server o SQL Server depende de derechos activos de virtualización, movilidad o failover.
• Hay consumo Azure estable y medible al que pueden asignarse licencias elegibles mediante AHB.
• Se prevé un Step-up concreto y la ruta elegible cuesta menos que una relicencia independiente.
• La infraestructura cambia con frecuencia dentro de una granja y la movilidad permitida reduce fricción operativa.
• La continuidad de cobertura evita perder derechos que serían caros o imposibles de reactivar más adelante.

Situaciones donde puede no compensar

• La versión actual permanecerá en uso durante varios años y no se necesitan beneficios condicionados a cobertura activa.
• El supuesto ahorro depende de beneficios retirados, como formación, Planning Services o soporte 24x7.
• No hay inventario fiable de cores, OSE, CAL, vCores o asignaciones, por lo que el beneficio no puede ejecutarse ni demostrarse.
• La migración cloud prevista utiliza servicios, proveedores o modelos no elegibles.
• La organización compra principalmente suscripciones cloud con derechos propios y está duplicando cobertura sin una necesidad identificada.
• El caso financiero presupone doble uso on-premises y Azure más allá de los 180 días o réplicas activas sin licencia.

La decisión puede variar incluso dentro de la misma empresa. Es razonable renovar SA para SQL Server Enterprise en hosts densos y no hacerlo para un producto estable sin plan de actualización. Segmentar por pool, SKU y función suele producir una respuesta mejor que renovar o cancelar todo de forma uniforme.

Checklist antes de comprar o renovar

• Confirmar país, tipo de organización, programa y acuerdo vigente.
• Identificar SKU, edición, versión y modelo: Core, Server/CAL, usuario o dispositivo.
• Distinguir licencia perpetua con SA de suscripción con derechos equivalentes.
• Registrar fecha de expiración y ventana contractual de renovación.
• Contar cores físicos, procesadores, hosts, OSE, vCores y CAL.
• Documentar qué beneficios se usarán y en qué proyecto o recurso.
• Comprobar proveedor: Azure, Authorized Mobility Partner, Authorized Outsourcer o Listed Provider.
• Validar reglas de 90 días y concesión de migración de 180 días.
• Clasificar cada failover como HA, DR pasivo, prueba o uso durante desastre.
• Completar la verificación de License Mobility cuando corresponda.
• Comparar cotización de SA con escenarios conservador, base y transformación.
• Guardar Product Terms del mes, contrato, pedidos y evidencias de asignación.

Para preparar una revisión más amplia, puede resultar útil nuestra checklist de auditoría de licencias Microsoft. La validación debe repetirse antes de renovar, después de una migración y cuando cambien hosts o proveedores.

Preguntas frecuentes sobre Microsoft Software Assurance

¿Software Assurance incluye soporte 24x7?

No como beneficio general actual. Microsoft retiró progresivamente 24x7 Problem Resolution Support desde el 1 de febrero de 2023. Puede existir soporte por otro contrato, pero no debe presupuestarse como parte automática de SA en 2026.

¿Puedo actualizar a cualquier edición nueva?

No. New Version Rights cubre nuevas versiones de la edición licenciada durante la cobertura. Para subir de edición se necesita una ruta Step-up elegible u otra licencia.

¿SA permite mover Windows Server a cualquier nube?

No. License Mobility through SA no cubre de forma general el sistema operativo Windows Server. AHB se aplica a destinos Azure elegibles y otros marcos de outsourcing tienen sus propias restricciones.

¿Puedo usar la misma licencia en local y Azure?

Existe una concesión de migración de 180 días para uso simultáneo en escenarios elegibles. Fuera de ella hay que aplicar las reglas del producto y la modalidad; no se presume doble uso permanente.

¿Qué ocurre si no renuevo SA?

Una licencia perpetua conserva los derechos consolidados y la última versión disponible durante la cobertura. Terminan los beneficios que exigen cobertura activa. Una licencia de suscripción, en cambio, finaliza según su contrato y no se vuelve perpetua.

¿Dónde se comprueban los derechos definitivos?

En los Product Terms del mes, seleccionando programa y entrada del producto, junto con el contrato y los pedidos del cliente. Microsoft Learn ayuda a implementar, pero no sustituye las condiciones de licencia.

Conclusión: comprar derechos que vayan a utilizarse

Software Assurance puede proteger una inversión de licencias y habilitar diseños que, sin cobertura activa, exigirían otra estrategia. Su valor no reside en acumular una lista larga de ventajas, sino en conectar derechos concretos con proyectos reales: una versión que se desplegará, una granja que necesita movilidad, una topología SQL con failover correctamente diseñada o recursos Azure a los que se aplicará AHB.

La decisión debe rehacerse con cada renovación. Los términos cambian, los beneficios históricos desaparecen y la arquitectura evoluciona. Una revisión por SKU, acompañada de una cotización real y un modelo de consumo, permite saber qué cobertura compensa y cuál solo añade coste.

¿Quieres validar tu escenario antes de comprar o renovar? Solicita a Licendi una revisión de Software Assurance. Analizaremos productos, cobertura, infraestructura y uso previsto para construir una recomendación trazable, sin asumir beneficios que no correspondan.