Hace un par de años, en el Archivo General de la Nación, actualizamos PHP de la versión 7.2 a la 7.4 en uno de los servidores de desarrollo. Era un salto menor, o eso pensábamos. A la mañana siguiente, tres módulos del portal institucional no respondían y el formulario de consulta de documentos históricos arrojaba un pantallazo blanco. Nada más. Solo blanco.
Este tipo de situaciones son más comunes de lo que parece. Un cambio que en papel es insignificante termina causando caos operativo. Y cuando trabajas con portales del Estado, donde cada minuto fuera de línea significa ciudadanos sin acceso a trámites o información pública, la presión es real.
La ilusión de compatibilidad hacia atrás
PHP tiene fama de mantener compatibilidad con versiones anteriores, pero esa compatibilidad no es absoluta. Entre versiones menores pueden aparecer funciones deprecadas, cambios en el manejo de errores o ajustes en librerías que tu código usa sin que lo sepas.
Cuando actualizas de PHP 7.3 a 7.4, por ejemplo, te encuentras con que cambiaron cómo se manejan ciertos tipos de datos en funciones como array_merge o cómo se comporta el operador de comparación. Si tu CMS o tus desarrollos personalizados dependen de ese comportamiento específico, todo se puede ir al piso.
El problema es que muchas veces confiamos ciegamente en que "es solo una actualización menor". Pero en un portal institucional que lleva años funcionando, con capas de código heredado, plugins viejos y personalizaciones hechas por diferentes proveedores, esa confianza puede salir cara.
Dependencias invisibles que explotan
La mayoría de portales institucionales corren sobre WordPress, Joomla o Drupal. Estos CMS son robustos, pero dependen de cientos de componentes: temas, plugins, librerías externas. Cada uno de esos componentes tiene sus propios requisitos de PHP.
Cuando actualizas PHP, puede que el núcleo del CMS funcione de una, pero un plugin que nadie ha tocado en tres años puede dejar de cargar. Y si ese plugin maneja algo importante como la integración con el sistema de autenticación gubernamental o la API de consulta ciudadana, tienes un problema serio.
En RAP-E Región Central trabajamos con un portal que integraba varios micrositios. Uno de ellos usaba un plugin de formularios que dejó de ser mantenido en 2018. Cuando migramos a PHP 8.0, ese plugin simplemente murió. No había parche, no había actualización. Tocó reescribir toda esa funcionalidad desde cero.
Lo complicado es que estas dependencias no siempre son evidentes. Puedes tener código que llama funciones de PHP que fueron marcadas como obsoletas pero que aún funcionan en modo silencioso. Hasta que un día ya no funcionan más.
El ciclo de actualización forzada
Aquí viene algo que me genera dudas: ¿hasta qué punto es responsabilidad nuestra como administradores mantener versiones viejas de PHP solo para evitar romper cosas? Porque por un lado está la estabilidad operativa, pero por otro está la seguridad.
PHP 7.2, por ejemplo, dejó de recibir actualizaciones de seguridad en 2020. Si lo sigues usando, estás exponiendo el servidor a vulnerabilidades conocidas. Pero si actualizas sin un proceso riguroso de pruebas, puedes tumbar servicios que miles de personas usan a diario.
Este dilema es especialmente difícil en instituciones públicas donde los presupuestos de tecnología son limitados y los proveedores de desarrollo a veces ya no existen o cambiaron de razón social. No siempre hay recursos para auditar todo el código antes de una actualización.
Lo que he aprendido es que necesitas un ambiente de staging que replique exactamente producción. No basta con probar en local o en un servidor "parecido". Tiene que ser idéntico: misma versión de sistema operativo, mismas extensiones de PHP, misma configuración de Apache o Nginx.
Y aun así, vas a encontrar sorpresas.
Estrategias que funcionan en la práctica
Una cosa es la teoría y otra la realidad de los portales del Estado. Mi recomendación, después de tantos años lidiando con esto, es nunca actualizar PHP en viernes. Tampoco en vísperas de fechas clave como declaración de impuestos o períodos de alta consulta ciudadana.
Antes de cualquier actualización, hago un inventario completo de plugins y temas. Verifico cuáles están activos, cuáles son realmente necesarios y cuáles tienen actualizaciones disponibles. Ese solo paso te ahorra muchos dolores de cabeza.
También es clave activar el registro de errores de PHP en modo verbose durante las pruebas. Muchos problemas se pueden detectar antes de que exploten si lees los logs con atención. A veces es solo una función que cambió de nombre o un parámetro que ahora es obligatorio.
Pero lo más importante es documentar todo. Cada cambio, cada error encontrado, cada solución aplicada. Porque dentro de seis meses, cuando tengas que hacer otra actualización, vas a agradecer tener ese registro.
La realidad es que PHP va a seguir evolucionando y los portales institucionales tienen que mantenerse al día. No hay forma de evitarlo. Lo que sí podemos hacer es profesionalizar el proceso, dejar de ver las actualizaciones como trámites menores y tratarlas con el cuidado que merecen. Porque detrás de cada portal hay personas que necesitan acceder a sus derechos, a información pública, a servicios del Estado. Y eso no puede romperse por un descuido técnico.