El estado en 2026: qué significa que Pages esté en mantenimiento

Cuando una empresa anuncia que un producto entra en mantenimiento, la reacción típica del equipo que lo usa oscila entre dos extremos igual de improductivos. Unos leen sentencia de muerte y convocan una migración de urgencia para algo que sigue funcionando perfectamente y no tiene fecha de apagado. Otros leen que no pasa nada, porque efectivamente no pasa nada esa semana, y siguen construyendo encima durante dos años más. Las dos lecturas fallan por lo mismo: tratan el anuncio como una afirmación sobre el presente, cuando es una afirmación sobre la derivada. Mantenimiento no dice qué deja de funcionar hoy; dice que la distancia entre este producto y el resto de la plataforma va a crecer de forma monótona a partir de ahora. Entender esa diferencia con precisión, y saber traducirla a un inventario concreto de lo que tienes y lo que nunca vas a tener, es lo que separa una decisión técnica de una corazonada.

Tres estados que no son lo mismo

El vocabulario importa porque cada estado exige una respuesta distinta y un calendario distinto. Confundirlos produce migraciones prematuras o parálisis, y ambas cuestan dinero.

Pages está en el primero. No hay anuncio de retirada, los proyectos existentes compilan y sirven con normalidad, y los fallos que afectan a la corrección o a la seguridad se siguen atendiendo. Lo que se detuvo es la inversión en capacidades nuevas: todo el esfuerzo de producto va a Workers, y esa reasignación no es reversible porque responde a la convergencia técnica de ambos productos, no a una preferencia comercial.

La distinción práctica entre el primer estado y el segundo es la existencia de un reloj. En obsolescencia declarada hay una fecha publicada y, por tanto, un plazo que puedes meter en un plan y defender ante quien aprueba presupuestos. En mantenimiento no hay reloj externo, y ese es precisamente el problema de gestión: sin fecha impuesta, la migración compite cada trimestre con trabajo que sí tiene fecha, y pierde siempre. Los equipos que salen bien de esta situación son los que se fabrican su propio reloj en lugar de esperar a que se lo pongan.

Hay también una asimetría de información que conviene tener presente. Un anuncio de mantenimiento suele llegar bastante después de que la decisión se haya tomado internamente, porque se comunica cuando el sucesor ya está listo. Es decir, cuando lo lees, la divergencia lleva tiempo acumulándose y las plantillas, los ejemplos y la documentación ya se han empezado a mover. Esto no es opacidad ni mala fe; es el orden natural en que ocurren las cosas. Pero significa que la fecha del anuncio no es el punto de partida de la deriva, sino un punto ya avanzado de ella.

flowchart LR
M[mantenimiento] -->|solo si se anuncia| O[obsolescencia declarada]
O -->|fecha publica| F[fin de vida]
M -.puede durar anos.-> M
M --> R[riesgo real: deriva del ecosistema]
style M fill:#f9e2af,color:#11111b
style R fill:#f38ba8,color:#11111b
style F fill:#585b70,color:#cdd6f4

El inventario de lo que sigue en pie

Conviene ser justo con el producto, porque la exageración en sentido contrario también es un error de ingeniería. Un proyecto de Pages en 2026 no está tullido: hace exactamente lo que hacía, y lo hace bien. Un sitio que lleva dos años sirviendo sin incidencias seguirá sirviendo sin incidencias, y decirle a un equipo que su sistema es obsoleto cuando cumple su función es una forma barata de generar trabajo que nadie pidió.

Los bindings que ya funcionaban en Pages Functions siguen funcionando, los dominios propios siguen resolviendo y el certificado se sigue renovando solo. Si tu proyecto es un sitio estático con dos formularios y una redirección, la respuesta honesta es que no tienes ninguna urgencia y que migrar mañana por la mañana no te compra nada que necesites hoy.

Merece la pena subrayar el último punto porque suele leerse mal. Que el comando de compilación de funciones siga disponible de forma indefinida no es un descuido ni una promesa a medias: es una decisión deliberada de dejar abierto el puente. Traduce el árbol de functions/ a un único script de Worker, de modo que un proyecto heredado puede cruzar sin reescribir su enrutado el mismo día del cambio. Reconocer que existe ese puente cambia la naturaleza de la migración: deja de ser una reescritura y pasa a ser un cambio de envase, con la reescritura como trabajo posterior y opcional.

El inventario de lo que no llegará

La otra mitad del balance es más larga, y crece cada trimestre. Todo lo que la plataforma añade desde la convergencia nace en Workers y se queda ahí. No hay un mecanismo de retroalimentación hacia Pages, ni lo habrá, porque construirlo consumiría precisamente los recursos que se decidió no gastar.

Esa última fila es la que más pesa a largo plazo, porque no es una lista cerrada. Cada vez que la plataforma incorpora algo —una nueva forma de servir modelos, un nuevo tipo de binding, una mejora de observabilidad— la distancia aumenta sin que nadie haya tocado tu proyecto. Tu código no se degrada; se queda quieto mientras el suelo se mueve.

Lo mismo vale para la segunda fila, que es la que produce más sorpresas al migrar en sentido inverso a lo esperado. El control sobre si se evalúa primero el archivo estático o primero tu código es hoy una opción del bloque assets, y en Pages era un comportamiento fijo con un archivo de exclusiones encima. No es que Pages lo haga peor: es que hace lo que hacía y ya no cambiará, mientras que el otro lado sigue ganando finura en cada versión.

Hay además una categoría que no aparece en ninguna tabla oficial y que conviene añadir por tu cuenta: las plantillas, los adaptadores de framework y los ejemplos. Ninguno de ellos es un compromiso de soporte, así que nadie anuncia cuándo dejan de cubrir un camino; simplemente el ejemplo nuevo se escribe para el manifiesto nuevo y el viejo deja de actualizarse. Esa erosión es silenciosa, no tiene fecha y es, en horas de ingeniería, mucho más cara que cualquiera de las filas anteriores.

Por qué congelarlo era la conclusión y no un capricho

Ayuda a decidir con la cabeza fría entender que el congelamiento no fue una decisión comercial contra los usuarios de Pages, sino la consecuencia aritmética de que los dos productos hubieran convergido. Mientras Workers no supo servir archivos estáticos con hosting gratuito, Pages tenía una razón de ser irreemplazable: cobrar por cada imagen servida habría hecho inviable mover cualquier sitio de tráfico alto. En cuanto los assets dejaron de contar como invocación, esa razón desapareció y quedaron dos productos resolviendo lo mismo con dos configuraciones, dos superficies de herramienta y dos conjuntos de errores.

{
  "name": "mi-app",
  "compatibility_date": "2026-07-30",
  "main": "src/index.ts",
  "assets": { "directory": "./dist", "binding": "ASSETS" },
  "d1_databases": [{ "binding": "DB", "database_name": "app", "database_id": "..." }],
  "triggers": { "crons": ["0 3 * * *"] }
}

Vale la pena leer ese fragmento con el ojo puesto en lo que no aparece. No hay una dirección de API que sincronizar entre proyectos, no hay una política de cruce de origen, no hay un segundo juego de secretos y no hay un orden obligatorio de publicación entre dos mitades. Todo eso desaparece no porque se haya resuelto, sino porque deja de existir el problema que lo generaba.

Ese manifiesto describe en diez líneas lo que la era dividida necesitaba en dos proyectos: front-end estático servido sin coste, lógica de servidor, acceso a datos y una tarea programada, todo versionado y publicado como una sola cosa. Mantener en paralelo un segundo producto que hace un subconjunto de eso, con su propio modelo de precedencia y su propio vocabulario de configuración, es un impuesto que paga el proveedor en esfuerzo y el usuario en confusión. Congelarlo fue reconocer que la duplicidad ya no compraba nada.

Entender esto tiene un valor práctico inmediato y no solo consolador: te dice que la migración no va a encontrarse con sorpresas conceptuales. No estás cruzando hacia un modelo distinto que habrá que aprender desde cero, sino hacia el modelo general del que el tuyo era un caso particular. Todo lo que tu proyecto de Pages sabe hacer tiene un equivalente exacto del otro lado, y además tiene otros veinte que aún no necesitas. Las migraciones difíciles son las que cambian de paradigma; esta cambia de envase, y esa diferencia es la que permite planificarla en semanas en vez de en trimestres.

Como la deriva no dispara alarmas, conviene tener a mano un puñado de señales concretas que sí se pueden observar. Ninguna es grave por sí sola; la que importa es su acumulación trimestre a trimestre.