Setenta y uno por ciento de las top 100 universidades del mundo opera sobre Drupal. La cifra es de la Drupal Association y responde a una pregunta global: cuál es la elección dominante del sector universitario en su conjunto.
La pregunta sectorial LATAM es distinta. ¿Qué llevó a que más de siete universidades enterprise en Colombia, Chile, Perú y Ecuador hayan llegado independientemente a la misma conclusión, en distintos momentos, bajo regulaciones diferentes y con presupuestos y contextos institucionales muy distintos entre sí?
La respuesta honesta, después de operar plataformas universitarias enterprise en LATAM durante varios años, es que Drupal no es la opción más sexy ni la más barata. Es la que envejece bien. Y envejecer bien no es propiedad de catálogo. Es propiedad arquitectónica.
Las tres condiciones simultáneas del sector universitario LATAM
Lo que se ve operando universidades enterprise en LATAM durante varios años son tres condiciones que operan en simultáneo y que muy pocos sectores enfrentan con la misma intensidad.
La primera condición es regulatoria. En Colombia, el Ministerio de Educación Nacional emite lineamientos de acreditación institucional que cambian, se actualizan, y exigen evidencia digital de su cumplimiento. Sumado a accesibilidad WCAG 2.1 AA obligatoria en portales universitarios públicos y muchos privados. Sumado a GDPR cuando la universidad opera programas internacionales o convenios con instituciones europeas. Y a esto se agregan lineamientos de accesibilidad institucional por país en Chile, Perú y Ecuador. La regulación no es una capa que se cumple una vez al lanzar el sitio. Es una condición operativa permanente.
La segunda condición es de volumen real. Los portales universitarios enterprise atraviesan millones de páginas vistas mensuales que reparten cinco audiencias simultáneamente: estudiantes activos en su flujo académico cotidiano, docentes en su flujo de gestión y publicación, postulantes evaluando programas y procesos de admisión, egresados consultando trámites y certificados, y alumni en su flujo institucional. El volumen no es de un sitio. Es de un ecosistema multisitio.
La tercera condición es de ciclo de decisión. Las universidades operan bajo planes de desarrollo institucional plurianuales de cuatro a ocho años, presupuestos plurianuales con cupos por vigencia académica, Rectores con horizonte a cuatro años y Comités Directivos que evalúan plataformas cada cinco a siete años, no cada dieciocho meses como sectores más reactivos.
Estas tres condiciones operan en simultáneo, no por turnos. Pocas industrias enfrentan las tres a la vez con esa intensidad.
Plataforma que envejece bien
Llamamos plataforma que envejece bien a aquella que sostiene cinco años de evolución sin reconstruirse cuando entra cada nueva versión mayor del CMS, cada nuevo Vicerrector, cada nueva resolución del Ministerio o cada nueva capa tecnológica.
La oposición conceptual es plataforma que se lanza bien. La plataforma que se lanza bien tiene buen launch, buen año uno, y deuda técnica acumulada que aparece silenciosamente en el año tres. Justo cuando el patrocinador interno que la aprobó ya cambió de cargo, y nadie en la institución está dispuesto a explicar al Comité Directivo entrante por qué hay que reconstruir el portal después de tres años.
Aplicado a Drupal en sector universitario, plataforma que envejece bien se sostiene sobre cuatro propiedades arquitectónicas: un modelo de entidades nativo que crece sin reconstruir el core, un ciclo de versiones mayores predecible con paths de migración documentados (Drupal 7 a 8 a 9 a 10 sostenido en proyectos reales), un ecosistema multisitio con governance centralizada vía Acquia Site Factory, y una comunidad open source con proceso estructurado de contribución al core, no un mercado de plugins privados que viven o mueren con su mantenedor.
El sector universitario LATAM no puede permitirse plataformas que se lancen bien y envejezcan mal. Sus ciclos plurianuales lo penalizan demasiado. Por eso la elección sectorial converge a Drupal, no porque sea una marca aspiracional sino porque cumple la propiedad arquitectónica de envejecer bien.
Tres patrones observables en universidades operadas en LATAM
Estas no son afirmaciones teóricas. Son patrones que se han observado operando portales universitarios durante varios años en distintos países. Tres patrones se repiten en universidades muy diferentes entre sí.
Multisitio con autonomía editorial
Las universidades enterprise no son un sitio. Son un ecosistema de portales con autonomía editorial por facultad, departamento, programa académico, hospital universitario o centro de investigación.
Universidad El Bosque opera dos portales (institucional y Hospital Universitario El Bosque) sobre un codebase compartido. Acquia Site Studio entregó 40% más velocidad de publicación de páginas frente al modelo manual anterior, sin reconstruir el ecosistema base.
Universidad del Rosario opera seis o más portales sobre dos codebases compartidos. La curaduría editorial centralizada pasó de ocho mil contenidos a seis mil en la migración, no porque se perdiera contenido sino porque se eliminó duplicación arquitectónica acumulada durante años. La operación posterior demuestra cuatro años continuos sin incidentes de seguridad reportados sobre el ecosistema.
Universidad de La Sabana opera cinco sitios sobre tres codebases. Conexión Sabana 360 funciona como medio digital institucional. Unisabana 360 se lanzó recientemente como portal corporativo de la Facultad de Comunicación, sin necesidad de reconstruir el ecosistema base. La arquitectura multisitio admitió el nuevo portal como capa adicional, no como reconstrucción.
El patrón es consistente: autonomía editorial por unidad académica, governance centralizada por institución, sin multiplicar costos de mantenimiento proporcionalmente al número de sitios.
Migración entre versiones mayores sin reconstruir
Drupal libera versiones mayores con cadencia predecible (Drupal 7 a 8 a 9 a 10) y paths de migración documentados. Esto se traduce en operación real así: Universidad El Bosque migró su ecosistema de Drupal 8 a Drupal 9 a Drupal 10 sin re-launch desde cero. La migración es ciclo predecible, no proyecto de reconstrucción.
Lo que esa propiedad arquitectónica le ahorra a la institución es estratégico, no técnico. La universidad invierte el presupuesto plurianual en evolución de funcionalidad pedagógica, integración con nuevas plataformas académicas o expansión de capacidades digitales para estudiantes. No en mantener vivo lo que ya existe.
En el otro extremo de esa decisión está la deuda técnica de portales que se lanzan bien y envejecen mal. Esa deuda termina absorbida por presupuesto que no se invirtió en la próxima generación de capacidad digital universitaria.
Accesibilidad WCAG y cumplimiento MEN sostenido sin retrofits
La accesibilidad WCAG 2.1 AA no es un módulo que se instala al final del proyecto. Es una propiedad que se construye desde el modelo de entidades, los flujos editoriales y la arquitectura de plantillas del portal.
Universidad de La Sabana cumple lineamientos del Ministerio de Educación Nacional y accesibilidad WCAG 2.1 AA como parte de la arquitectura del portal, no como capa posterior aplicada con retrofit. Esa diferencia es operativamente importante. Cumplir la accesibilidad por arquitectura permite demostrar cumplimiento continuo ante el regulador, no solo mostrar evidencia puntual en momentos de auditoría.
El portal que cumple por retrofit pasa cada auditoría con esfuerzo proporcional al volumen de contenido nuevo. El portal que cumple por arquitectura pasa cada auditoría como consecuencia natural de operar el ecosistema.
La siguiente capa, IA aplicada en higher ed LATAM
El sector universitario LATAM está empezando a incorporar IA aplicada como capa adicional sobre plataformas existentes. Universidad de La Sabana es finalista de los Acquia Awards 2026 en la categoría Best Use of AI for Learning and Acceleration con IA aplicada al campus virtual Unisabana.
La razón por la que estas universidades pueden incorporar IA sin reconstruir su plataforma digital es exactamente porque eligieron plataforma que envejece bien hace años. La arquitectura ya admitía esta capa cuando se decidió, sin saber entonces que la IA aplicada iba a ser una capa relevante en el ciclo plurianual siguiente.
Las universidades que no eligieron plataforma que envejece bien tendrán que reconstruir antes de aplicar IA con criterio. Y en el sector universitario LATAM, reconstruir una plataforma cuesta lo que normalmente se invierte en dos o tres años de evolución académica. Es un costo que no se invierte en estudiantes, en docentes, en investigación o en infraestructura física.
La pieza hermana de este artículo, Por qué la IA reduce el costo del código pero no el del criterio, profundiza el principio operativo que aplica esinergia a la incorporación de IA en plataformas digitales enterprise.
La pregunta del Comité Directivo universitario en 2026
La pregunta correcta para un Comité Directivo universitario en 2026 no es qué CMS lanza más rápido el sitio de la universidad. Es qué plataforma sostiene los próximos cinco años de evolución universitaria sin reconstruirse cada vez que entra el siguiente Vicerrector, la siguiente resolución del Ministerio, la siguiente acreditación institucional o la siguiente capa tecnológica.
La decisión silenciosa de la Educación Superior LATAM, vista desde el lado del Operador después de operar varias universidades enterprise durante años, es elegir plataformas que envejecen bien. Eso es lo que explica el patrón de más de siete universidades enterprise operadas por esinergia en cuatro países y, en otra escala, el setenta y uno por ciento de las top cien universidades del mundo.
Si su institución está evaluando plataforma para los próximos cinco años de evolución académica, sentémonos a revisar el ciclo de operación universitario antes que el catálogo de features. No vendemos una respuesta general. Mapeamos su contexto específico.