Microsoft ha reconocido que borró datos de clientes del sector no lucrativo antes de que terminara el periodo de retención, que no se pueden recuperar y que —esto es lo grave— no puede decir qué se borró, ni siquiera si a un cliente concreto le falta algo. Lo cuenta The Register, con el correo a un afectado delante y con la confirmación de la propia compañía.
Qué ha pasado
El contexto es un cambio de programa comercial. Microsoft tenía una donación de diez licencias gratuitas de Microsoft 365 Business Premium para entidades sin ánimo de lucro elegibles. En mayo de 2025 anunció que no se renovaría a partir del 1 de julio de ese año, y la sustituyó por hasta trescientas licencias gratuitas de Business Basic más precios con descuento en otros planes, incluido Business Premium. Lo puedes ver en su página para organizaciones sin ánimo de lucro.
El aviso incluía lo que suele incluir: mueve a los usuarios a otro plan antes de que se cancele la suscripción, y exporta lo que no vayas a conservar dentro de Microsoft 365. Hasta aquí, un cambio de licenciamiento normal y bien comunicado.
El problema vino después de la desactivación. Según el correo que Microsoft envió a un afectado, «debido a un error» se eliminaron los datos que quedaban antes de que se cerrase la ventana de retención y exportación. Investigaron cómo recuperarlos y no hubo forma. Y encima:
No podemos facilitar en este momento una lista de qué datos pueden haberse eliminado, ni si se eliminó algún dato.
Microsoft confirmó el borrado prematuro y dijo que el contenido afectado sería el asociado a suscripciones Business Premium ya caducadas. No ha dicho cuántas organizaciones están afectadas, cuánto se adelantó el borrado respecto al plazo, ni qué causó el error. Como compensación ofrece un servicio de acompañamiento gratuito: una reunión con un especialista para montar el entorno nuevo y responder dudas. Útil si lo que necesitas es un entorno nuevo. Bastante menos si lo que querías era lo que había en el viejo.
Por qué importa
El periodo de retención no es una copia de seguridad
Esto es lo que me llevo. Todos nos hemos apoyado alguna vez en la ventana de gracia del proveedor: «si se cancela, hay noventa días para reactivar y exportar». Ese plazo es una cortesía comercial gobernada por procesos de facturación, no una garantía de recuperación. Y los procesos de facturación se tocan: cambia un programa de licencias, se retira una donación, se migra un catálogo de SKUs, y en medio hay un trabajo automático que decide qué tenants están «terminados». Un error ahí borra de verdad.
La regla práctica: si un dato solo existe porque el proveedor todavía no lo ha eliminado, ese dato no está respaldado. Está pendiente de borrado.
El momento peligroso es el cambio de plan, no el incidente
Hace poco escribí sobre la caída de AWS en Baréin y la lección era parecida: hay datos que no vuelven. Pero ahí el disparador fue un fallo de infraestructura. Aquí el disparador es administrativo, que es peor, porque nadie lo mete en el análisis de riesgos. Nadie escribe un plan de contingencia para «nos cambian el programa de licencias».
Si mantienes sistemas de alguien, los eventos que deberían activar una copia completa y verificada son estos:
- Fin de una promoción, donación o descuento.
- Bajada de plan o reducción de puestos.
- Cambio de partner o de método de pago.
- Fusión o migración de tenants.
- Cualquier correo del proveedor con la palabra «retirada» o «no se renovará».
En todos esos casos hay un proceso automático tocando el ciclo de vida de tus datos. Y ese proceso no sabe quién eres.
Si no sabes qué tenías, nadie te lo va a decir
La parte que más debería doler a cualquiera que administre sistemas no es el borrado: es que el proveedor no puede enumerar lo perdido. O sea que, aunque quisieras reclamar, no tienes ni la lista. La única forma de saber qué te falta es tener tú el inventario de antes.
Eso es barato de hacer y casi nadie lo hace. Un listado periódico de buzones con su tamaño, de sitios de SharePoint, de bibliotecas de OneDrive por usuario, de equipos de Teams y sus canales, guardado fuera del propio tenant. No son los datos: es el índice de los datos. Con eso puedes decir «faltan cuarenta y un buzones y tres sitios» en lugar de «creemos que nos falta algo».
Lo que yo haría esta semana
- Exportación real, no confianza en la retención. Copia de buzones, OneDrive, SharePoint y Teams a un almacenamiento que no dependa de la misma factura ni del mismo proveedor de identidad.
- Prueba de restauración. Coge un buzón al azar y recupéralo. Una copia que no se ha restaurado nunca es una hipótesis.
- Inventario firmado y con fecha, guardado fuera.
- Alerta en el buzón de facturación. Los correos de cambios de plan no son spam administrativo: son avisos de riesgo técnico. Que los lea alguien que entienda qué se borra.
- Si gestionas entidades pequeñas o ONGs, revisa hoy si alguna se quedó con la suscripción caducada en lugar de migrarla. Ahí es donde ha pegado.
Qué no cambia
Seamos justos, que aquí es fácil pasarse. Microsoft avisó con antelación, ofreció una alternativa gratuita más amplia en número de licencias y pidió expresamente que se migrara antes de la cancelación. Quien movió a los usuarios a tiempo no tiene problema. El fallo está en el tramo final del proceso, no en la comunicación.
Tampoco sabemos el tamaño del desastre. No hay cifra de afectados, ni de cuánto se adelantó el borrado. Puede ser un puñado de organizaciones o muchas más; con lo publicado no se puede afirmar ninguna de las dos cosas, y quien te diga que «Microsoft ha borrado los datos de las ONGs» está contando más de lo que hay.
Y esto no es un argumento para volverse al servidor del armario. La nube sigue perdiendo menos datos que un NAS sin monitorizar en la sala de reuniones. Lo que cae es otra idea, más cómoda y más falsa: que el proveedor es también tu copia de seguridad. No lo es, no lo dice en ningún sitio, y este caso lo demuestra de la peor manera posible: sin poder decirte qué has perdido.
Cualquier duda me dices y lo vemos.
Un saludo, Vicente.