Microsoft ha anunciado un cambio que afecta a todas las organizaciones que todavía utilizan SharePoint Online en su versión Classic. El objetivo declarado es reducir los riesgos de seguridad y gobernanza asociados a los modelos de personalización más antiguos, empujando a las empresas hacia la experiencia moderna de SharePoint, pensada para ser más segura, más sencilla de administrar y preparada para los dispositivos móviles.
El proceso de retirada sigue dos fases diferenciadas, con fechas ya definidas, y afecta a los sitios de publicación Classic, a las páginas creadas por los usuarios y a los scripts personalizados. No se trata de un cambio repentino, ya que Microsoft deja un margen de un par de años antes de que los efectos se vuelvan irreversibles, pero precisamente por eso conviene empezar a pensarlo ya, sobre todo si tu intranet todavía arrastra la herencia de años de personalizaciones acumuladas.
Qué vas a encontrar en este artículo
- Los plazos fijados por Microsoft para decir adiós a SharePoint Classic
- Qué páginas y qué entornos se ven afectados
- Por qué Microsoft decidió actuar ahora
- Los 4 pasos que recomienda Microsoft para modernizar SharePoint Classic
- Un tema que afecta sobre todo a los tenants más grandes y más estratificados
Los plazos fijados por Microsoft para decir adiós a SharePoint Classic
Fase 1, a partir del 1 de marzo de 2027
A partir de esa fecha, en todos los tenants ya no será posible crear nuevos sitios de publicación Classic, ni como colecciones de sitios ni como subsitios. Del mismo modo, tampoco se podrá activar la función de publicación Classic donde todavía no esté habilitada. La configuración de tenant que permite crear estos sitios quedará bloqueada de forma permanente.
Para los tenants creados a partir del 1 de marzo de 2027, la restricción es más amplia, ya que los usuarios no podrán crear nuevas páginas Classic en absoluto, y la incorporación o modificación de scripts personalizados quedará desactivada de forma predeterminada.
Fase 2, a partir del 1 de octubre de 2028
A partir del 1 de octubre de 2028, las restricciones introducidas en la primera fase se extienden a todos los tenants existentes, incluidos los que llevan años activos. Las páginas Classic creadas por los usuarios pasan a ser de solo lectura, por lo que ya no será posible crear otras nuevas ni modificar las existentes. También en este caso se desactivará la posibilidad de añadir o actualizar scripts personalizados.
Microsoft aclara que las páginas siguen siendo accesibles para su visualización incluso después de este segundo plazo, un detalle que merece destacarse porque elimina la ansiedad de la eliminación, aunque no reduce la urgencia de planificar, ya que una página que ya no se puede modificar deja, en la práctica, de ser útil como herramienta de comunicación interna.
Vea intranet.ai en acción
Una intranet lista para usar en SharePoint Online, operativa en pocos días. Reserve una demo gratuita con nuestro equipo.
Reservar una demoQué páginas y qué entornos se ven afectados
La retirada afecta específicamente a ciertos tipos de páginas Classic creadas por los usuarios: las páginas wiki, las páginas de web parts, las páginas de blog, las páginas de publicación y las páginas ASPX personalizadas, creadas con SharePoint Designer o con soluciones de terceros. Quien trabaja a diario con SharePoint reconocerá en esta lista gran parte de las páginas que componen una intranet construida con el enfoque más antiguo, el basado en diseños fijos e inserción de código en lugar de web parts configurables.
Quedan fuera de este alcance las vistas de listas y bibliotecas documentales y las páginas de formularios asociadas, aunque los scripts personalizados que puedan estar incorporados en ellas siguen sujetos a las nuevas restricciones sobre creación y modificación de scripts. Es una distinción técnica que vale la pena tener en cuenta al hacer el inventario: no todo lo “antiguo” en un tenant de SharePoint entra dentro de esta retirada, y no todo lo que queda fuera está a salvo de las reglas sobre scripts.
El cambio se aplica a todos los entornos de Microsoft 365, incluidos los de Government (GCC, GCC High y DoD), los entornos air-gapped de Office 365 y Microsoft 365 operado por 21Vianet. Por tanto, no hay excepciones relacionadas con el tipo de plan o el sector de la organización.
Por qué Microsoft decidió actuar ahora
Las páginas Classic y los modelos de personalización heredados se basan en el renderizado del lado del servidor y en scripts personalizados, tecnologías que, según Microsoft, aumentan el riesgo de seguridad, la complejidad administrativa y los costes de mantenimiento a largo plazo. Un sitio construido con páginas maestras personalizadas o con scripts añadidos años atrás por un proveedor que quizá ya no trabaja con la empresa se convierte, con el tiempo, en algo que nadie quiere volver a tocar por miedo a romperlo, y es exactamente este tipo de deuda técnica la que Microsoft quiere reducir.
También hay una cuestión de velocidad de innovación. El modelo Classic limita la coherencia con la que se pueden introducir nuevas funciones, mientras que la experiencia moderna de SharePoint ofrece un entorno de colaboración más seguro y gobernado, una gestión de permisos más sencilla a través de los grupos de Microsoft 365, una interfaz pensada desde el origen para dispositivos móviles y, de cara al futuro, la base sobre la que se sustentan las funciones más recientes relacionadas con la inteligencia artificial. Quien se mantiene anclado a las páginas Classic corre el riesgo, por tanto, no solo de un problema de seguridad, sino también de quedar excluido de este tipo de evolución.
Quien ya ha profundizado en las diferencias entre ambas experiencias lo sabe bien, porque el salto de SharePoint Classic a SharePoint Modern no afecta solo a la estética de las páginas, sino también a la gestión de permisos, la integración nativa con Teams y Outlook, y la posibilidad de automatizar flujos de trabajo con Power Automate, todos ellos ámbitos en los que el modelo Classic muestra ya sus límites.
Los 4 pasos que recomienda Microsoft para modernizar SharePoint Classic
La documentación oficial sugiere un enfoque gradual, pensado para reducir los riesgos asociados a la migración y dar a los propietarios de los sitios tiempo para validar las páginas modernizadas.
1. Identificar y evaluar el entorno Classic existente
El primer paso, y probablemente el más importante, es entender cuántos sitios y páginas Classic siguen activos en el tenant. Microsoft pone a disposición los eventos de auditoría de Microsoft Purview en la categoría dedicada a las actividades Classic, que incluyen la creación, modificación y visualización de páginas Classic, además del Microsoft 365 Assessment Tool, pensado específicamente para identificar páginas, web parts y patrones de personalización que todavía están presentes en el entorno. El resultado de esta herramienta incluye un inventario detallado de cada página encontrada, con un indicador de lo compleja que sería su transformación a la experiencia moderna.
Si la evaluación no detecta sitios de publicación Classic, páginas creadas por los usuarios ni scripts afectados por las nuevas reglas, no se requiere ninguna acción adicional. Pero este resultado es menos predecible de lo que parece, porque algunas organizaciones que creían estar ya totalmente modernizadas han descubierto, tras una revisión exhaustiva, que todavía tenían decenas o cientos de páginas Classic olvidadas en sitios secundarios, a menudo creadas años antes por equipos que mientras tanto han cambiado.
2. Priorizar según la importancia para el negocio
Conviene empezar por las páginas más utilizadas, las que se modifican con más frecuencia o las más relevantes para la actividad de la empresa, agrupándolas por complejidad y por tipo de intervención necesaria, de modo que se pueda reutilizar lo aprendido en las fases siguientes. Una página de noticias visitada a diario por cientos de personas merece un tratamiento distinto al de una página estática que nadie abre desde hace años.
3. Transformar las páginas a la experiencia moderna
Para la transformación propiamente dicha, Microsoft indica la guía oficial de modernización y PnP PowerShell como herramienta para una conversión determinista de las páginas que siguen un patrón recurrente. Para los escenarios más complejos, con HTML personalizado o contenido de editor de scripts que requiere criterio humano, Microsoft también señala el SharePoint Page Migration Agent, un proyecto de código abierto actualmente en vista previa. Vale la pena recordar que las herramientas de código abierto y en vista previa no cuentan con cobertura de SLA del soporte de Microsoft, y que las páginas más personalizadas pueden requerir igualmente una revisión o una reconstrucción manual.
4. Proceder por oleadas
La indicación final es combinar una planificación centralizada con la ejecución por parte de los propios propietarios de los sitios, modernizando grupos sucesivos de páginas en lugar de todas a la vez. Este enfoque por oleadas permite validar contenidos, enlaces, permisos, web parts y diseño en un número reducido de páginas antes de extender la intervención al resto del tenant, limitando el riesgo de tener que corregir el mismo error en cientos de páginas distintas.
Un tema que afecta sobre todo a los tenants más grandes y más estratificados
Las organizaciones que a lo largo de los años construyeron su intranet sobre SharePoint Server on-premises y después migraron a SharePoint Online tienden a tener un número más alto de sitios, páginas y personalizaciones Classic todavía activos, a menudo sin que el departamento de TI tenga un mapa completo y actualizado de ellos. Es un patrón recurrente, porque cada cambio de responsabilidad entre equipos distintos, cada proveedor externo que trabajó en el tenant en un momento dado y cada reorganización de la empresa dejan detrás algún sitio que ya nadie supervisa activamente, pero que sigue existiendo y siendo accesible.
Cuanto más grande y más estratificado en el tiempo es el tenant, más atención requiere la fase de censo, porque las páginas y personalizaciones pueden estar distribuidas en sitios distintos, gestionados por equipos distintos, con niveles de documentación muy desiguales entre sí. Los dos plazos fijados por Microsoft, marzo de 2027 y octubre de 2028, ofrecen una ventana de tiempo útil para abordar el problema con orden, pero es precisamente la fase de análisis inicial, la que permite entender realmente cuántas páginas Classic siguen en uso y con qué nivel de complejidad, la que exige la planificación más cuidadosa, porque es el momento en que se descubre la dimensión real del trabajo por hacer, incluso antes de empezar a modernizar nada.
Por dónde empezar si todavía no tienes una visión clara
Para las empresas de tamaño medio-grande, por encima de unos 300 usuarios, el primer obstáculo es casi siempre entender si el problema les afecta realmente, más que una cuestión técnica. Un buen punto de partida es hacerse, o pedirle al propio departamento de TI que responda, tres preguntas sencillas.
- ¿La empresa ha utilizado en el pasado SharePoint Server o SharePoint on-premises?
- ¿Se ha realizado una migración a SharePoint Online?
- ¿Se sabe con certeza si en el tenant quedan páginas, sitios o personalizaciones Classic?
Si la respuesta a la tercera pregunta no es segura, conviene implicar directamente al responsable de TI para una verificación puntual, en lugar de quedarse con una impresión preliminar. Ocurre con más frecuencia de lo que se piensa que empresas convencidas de no tener ya nada Classic descubren, tras un control más exhaustivo, más de 120 páginas todavía activas y olvidadas en sitios secundarios. Una verificación hecha a tiempo, aunque sea solo cualitativa, permite planificar con margen, en lugar de descubrir la dimensión real del trabajo justo antes de los plazos.
