Microsoft retira Targeted Release: tu anillo de pruebas ahora lo pagan los demás

Si tienes un puñado de usuarios en Targeted release para enterarte de los cambios antes que el resto de la empresa, ese mecanismo se acaba. Lo que casi nadie está contando es cómo propone Microsoft reconstruirlo: no adelantando a tu grupo de pruebas, sino retrasando a todos los demás. Es el mismo efecto, pero ahora lo paga otro.

El 7 de octubre de 2026 apareció en el Centro de mensajes de Microsoft 365 el aviso MC1490899, «Microsoft 365: Targeted Release retirement», con las etiquetas Major change, Admin impact y Retirement, fecha de actuación el 31 de octubre de 2026 y los servicios afectados en la cabecera: Exchange Online, la suite de Microsoft 365, SharePoint Online, OneDrive y Teams. Ese mismo día Microsoft actualizó tres páginas de documentación —el aviso de retirada, la de configuración de Standard y Deferred, y la de Frontier— las tres con el mismo ms.date: 2026-10-07T00:00:00.0000000Z y, lo que es más revelador, el mismo identificador de commit. Se escribieron a la vez y hay que leerlas a la vez.

Tres fechas, y solo una tiene día

La página de configuración lo dice así, literal, en un recuadro de aviso: «In November 2026, administrators can no longer add users to, remove users from, or modify Targeted release enrollment. In January 2027, Targeted release will be retired and no longer available to use.» Noviembre es el cerrojo; enero es el final. Ninguna de las dos lleva día. El único día que Microsoft ha puesto por escrito es el 31 de octubre del aviso del Centro de mensajes, que es la forma que tiene el aviso de decir «antes de noviembre».

Lo que caduca el 31 de octubre es tu capacidad de editar la lista, no el servicio. Después tus usuarios de Targeted release siguen recibiendo lo que recibían —«Users assigned to Targeted release will remain in Targeted release until its retirement»—, pero ya no puedes añadir ni quitar a nadie. Si en diciembre entra gente nueva al grupo de validación, no entra. Esa es toda la urgencia, y basta para mirarlo esta semana y no en la víspera.

Targeted release nunca fue acceso anticipado, y eso cambia la cuenta

Aquí hay un matiz que se nos ha colado a casi todos, a nosotros incluidos hasta que lo leímos en frío. La frase está escondida en la página de Frontier, dentro de un recuadro de aviso, y es la que ordena el resto:

Frontier is for access to pre-GA features and Targeted
release is for access to features early within general
availability.

Targeted release no te daba funciones antes de que existieran para el público: te ponía en la primera ola del despliegue general. Es una diferencia pequeña en el papel y enorme en la práctica, porque significa que el valor de Targeted release nunca fue probar prototipos. Era otra cosa, mucho más humilde y mucho más útil: tener a cinco personas que se tropezaban con el cambio antes que las otras doscientas, con código ya soportado y en producción. Un sistema de alarma temprana hecho de compañeros.

Y ahí está el problema, porque en el modelo nuevo no puedes elegir la primera ola. Las tres opciones, con las definiciones de la página de configuración, son: Frontier, que es anterior al GA pero que la propia tabla comparativa clasifica como «Pre-GA, not fully supported»; Standard release, que es el GA y es el valor por defecto de todo el mundo; y Deferred release, que es «Same functionality as Standard release, delayed 30 days after Standard release (GA) for major updates». No existe el peldaño «GA, pero tú primero». Existe el GA, lo que va antes del GA sin soporte completo, y lo que va después.

La recomendación de Microsoft, leída despacio

La página de retirada trae una tabla de equivalencias para que sepas a qué pasarte. La fila que importa es la segunda, la de quien tenía un grupo de validación, y conviene leerla entera porque es donde está todo:

Targeted release for select users

  To preserve using an early production validation group
  while giving your broader organization additional time
  to prepare:
  - Choose Deferred release
  - Under "Assign users or groups for standard release",
    add validation, support, or pilot users.

Léelo otra vez. Tu grupo de validación no se mueve: se queda en Standard, es decir, en el GA de siempre. Quien se mueve es el resto de la empresa, que pasa a Deferred y recibe los cambios importantes treinta días tarde. Microsoft es honesta y lo escribe en la misma frase —«while giving your broader organization additional time to prepare»—, pero el encuadre comercial es generoso: eso no es «dar tiempo adicional», es la única forma que queda de conservar la distancia, porque si no puedes adelantar a nadie, solo te queda retrasar a los demás.

Y hay una letra pequeña que recorta bastante lo que compras con ese precio. Deferred no retrasa todo: retrasa major updates, y la propia página explica cómo se reconocen: «In the Message center, features included in deferred release are tagged as both Major update and Deferred feature.» Las dos etiquetas, no una. Lo que no las lleve llega el mismo día a tu grupo de validación y a todos los demás, con lo cual para esos cambios tu anillo no existe. Por si queda duda de la amplitud del filtro, la lista de ejemplos que da Microsoft de major update incluye cosas tan de diario como «changing a user's inbox, meetings, delegations, sharing and access that might result in help desk calls» o «a new service or application deployed with default settings turned on». Es ancha, y encima la propia página la abre con un «might include», así que tampoco es cerrada: no puedes dar por hecho que lo que no aparece ahí no cuente como major update, ni al revés.

Cien

Es el número que nos hizo parar al leer el procedimiento de configuración, y es el que más gente va a descubrir tarde. La frase, entera:

You can add up to 100 exceptions to Standard release or
Deferred release. Each user in a security group and each
user added individually count toward the 100-user limit.

La segunda frase es la importante y es la que desarma el reflejo de todo administrador. El reflejo es: «pongo un grupo de seguridad y así lo gestiono desde Entra ID sin volver a entrar aquí». Puedes hacerlo, y es buena idea por mantenimiento, pero no te compra escala: los miembros del grupo se cuentan de uno en uno contra el mismo tope de cien. Un grupo de seguridad con ciento veinte personas no es una excepción, son ciento veinte, y veinte sobran.

Para la mayoría de las empresas con las que trabajamos, cien da de sobra: un anillo de validación sano son entre diez y treinta personas. Muerde en dos sitios. Si tenías Targeted release puesto para un departamento entero —comercial, o toda la delegación de Barcelona— y ese departamento pasa de cien, la lista actual no cabe y hay que decidir a quién dejas fuera. Y como la lista es un presupuesto de personas y no de grupos, deja de ser gratis meter a alguien «por si acaso»: hay que elegir, y elegir obliga a tener un criterio escrito, que es justamente lo que casi nadie tiene.

Dónde está el interruptor ahora (y por qué no lo vas a encontrar)

Las dos rutas no están en el mismo sitio, y la segunda no está donde la buscarías. Para ver quién tienes hoy en Targeted release, la página de retirada manda a Settings > Org settings > Organization profile > Release preferences. Para configurar el sustituto, manda a Copilot > Settings > View all > Copilot Release preferences: General availability; y para Frontier, a Copilot > Settings > View all > Copilot Frontier.

El control que decide cuándo recibe tu empresa los cambios de Teams, OneDrive, SharePoint Online, Outlook en la web, Office para la web y el propio centro de administración vive, hoy, dentro del menú de Copilot y se llama Copilot release preferences. Importa por una razón práctica y no estética: quien lleva la gestión del cambio va a abrir Org settings, ver que Release preferences sigue ahí, y marcharse convencido de que no hay nada que hacer. Y la misma documentación avisa de que esta pantalla también es provisional —«The current experience for managing Standard release and Deferred release preferences will be retired when the unified release preferences experience becomes available», en noviembre—. Vas a configurarlo en un sitio para que en un mes esté en otro.

La página de configuración añade tres cosas cortas y con consecuencias. Los roles que pueden tocarlo son Office Apps Admin, Security Admin o AI Admin; si en tu organización el calendario de cambios lo lleva alguien que no tiene ninguno de los tres, el cambio no tiene dueño. Tarda: «It can take up to 24 hours for the following changes to take effect in Microsoft 365», que es la razón para no dejarlo para el día 31 a las seis de la tarde. Y la nota del final, que es la que menos gracia hace: «If you move users from Standard release to Deferred release, they might lose access to features that aren't available yet in Deferred release» —mover a alguien al anillo prudente puede quitarle algo que ya tenía—.

Lo que NO entra (y es donde mucha gente va a perder la tarde)

Antes de que nadie entre en pánico con el parque entero: esto es más pequeño de lo que parece. La página de retirada acota el alcance con nombres y apellidos, y la frase que más tranquilidad da es la de lo que no toca:

Queda Frontier, la opción que más gente va a marcar por curiosidad y la que peor encaja como anillo de validación. No porque sea mala, sino porque está diseñada para otra cosa, y su propio recuadro legal lo dice sin rodeos: «As preview features, Frontier experiences may be modified, suspended, or discontinued, may not be covered by standard support commitments or service level agreements», con la coletilla de que «Certain Frontier experiences may only be available on a paid basis». Algo que puede suspenderse y puede quedar fuera del acuerdo de nivel de servicio sirve para evaluar y opinar; no sirve para decidir si tu proceso de facturación sobrevive al cambio. Un requisito más que conviene saber antes de prometerle nada a nadie: las funciones de Frontier relacionadas con Copilot piden licencia de Copilot —«Users without a Microsoft Copilot license aren't presented with Copilot-related Frontier features»—.

El entregable: media hora antes del 31

No hace falta un proyecto. Hace falta una persona con el rol adecuado, media hora y dejarlo escrito. En este orden:

En una semana hemos escrito tres veces sobre la misma forma de cambio: un valor por defecto que se mueve solo y que únicamente duele donde nadie había escrito una decisión. El 2 de octubre, memory integrity activándose sola justo en los equipos donde nadie había tocado nada; el 3, las alertas de DLP saliendo de la cola de incidentes. Que el fabricante cambie cosas es lo normal, para eso es un servicio. Lo que conviene recordar es que el valor por defecto se calcula para la media de millones de inquilinos, y tu empresa no es la media. El fallo es inevitable; la avería es una decisión de diseño. Aquí ni siquiera hay fallo: hay un aviso publicado el 7 de octubre, veinticuatro días hasta la fecha de actuación y una pantalla con dos desplegables.

Lo que no afirmamos

Conflicto de interés por delante: cobramos por esto. Dicho lo cual, la parte cara no es la configuración. Son dos desplegables y los mueve tu gente en media hora. Lo que cuesta dinero es contestar quién va primero y quién va detrás cuando esa pregunta no se ha respondido nunca por escrito, y eso no lo resuelve una pantalla. Sentarse con el parque delante y los nombres encima de la mesa es modern workplace; convertir el resultado en un calendario de cambios que siga vivo cuando quien lo montó esté de vacaciones es consultoría. Si en tu empresa esa respuesta ya está escrita, hoy tienes media hora de trabajo y no necesitas a nadie. Si al leer «Copilot > Settings > View all» has pensado que ahí no habéis entrado nunca, escríbenos.

Fuentes