Cómo enterré Drupal y no perdí quince años de historia de una pequeña ciudad

Tengo un proyecto al que trato con especial cuidado. Hace quince años hice un portal de noticias para una ciudad pequeña — un sitio regional habitual — que durante varios años funcionó correctamente, publicaba noticias y poco a poco fue acumulando contenidos. Luego el proyecto como medio cerró: el equipo se dispersó, las noticias dejaron de salir y el sitio quedó en Internet como testimonio de aquella época.

Su valor hace tiempo que no está en las noticias — ¿a quién le interesa una nota sobre la reparación de la red de calefacción de hace diez años? El valor está en otra cosa: es una instantánea de todo un período de la vida de la ciudad, registrada de una manera que nadie más repetirá. Y el Internet moderno conserva mal la memoria: los sitios se cierran, los dominios no se renuevan y capas enteras de historia local desaparecen sin rastro. No podía dejar que eso muriera.

Cuando el motor antiguo empieza a vengarse

El problema es que el tiempo es implacable con la deuda técnica. El motor del sitio — Drupal de la rama 6 — no se había actualizado en muchos años, porque no había a dónde actualizar: la rama está muerta, la comunidad hace tiempo que siguió adelante. Al mismo tiempo el sitio seguía siendo voluminoso y antiguo, lo que lo convertía en un objetivo apetecible para bots de búsqueda, raspadores y otros clientes automatizados, que especialmente adoran los recursos archivados con una rica historia de enlaces.

Se iniciaba un círculo vicioso. Los bots cargaban el sitio sin pausa, la tabla de caché se expandía hasta tamaños indecentes, la tabla de sesiones se saturaba, el servidor de vez en cuando caía por la carga — y yo una vez más iba a arreglar lo que se rompía sin que yo hubiera hecho nada. La conclusión era obvia: mantener esto tal cual es caro, sin sentido y cada año peor. Pero tampoco quería dejar que el sitio muriera.

Por qué las soluciones obvias no servían

Si no hay actualizaciones previstas, entonces el motor no hace falta — hace falta estático. Lógico. Pero cómo obtenerlo es una cuestión no tan trivial como parece.

La vía más simple es descargar el sitio entero, página por página. Rápido, pero torpe: en el viejo Drupal seguro se había acumulado una montaña de duplicados — los mismos contenidos accesibles por varias direcciones, con distintos parámetros, a través de taxonomías y sin ellas. Con ese enfoque la búsqueda en el sitio dejará de funcionar, y cualquier pequeña corrección en el futuro con alta probabilidad romperá algo, porque la estructura se convertirá en una masa opaca de HTML descargado.

La segunda opción es migrar el contenido a un motor nuevo por completo, con base de datos, taxonomías y un modelo de datos correcto. Suena bien, pero en esfuerzo es un proyecto completo, no una tarde de trabajo. Y lo principal: el riesgo de perder lo más valioso —la estructura de enlaces—. Durante años redes sociales, foros, otros sitios y los resultados de búsqueda habían enlazado ese archivo. Romper las URLs sería destruir precisamente la memoria por la que todo se había emprendido.

La solución se encontró en la intersección del análisis y la automatización

Al final encargué a Claude Code descomponer el sitio por partes: analizar las plantillas de presentación, la estructura de la base de datos y la lógica de formación de URLs, y luego convertir todo eso a Hugo — un generador de sitios estáticos ligero que no necesita ni servidor de aplicaciones, ni base de datos, ni PHP.

El trabajo llevó varias horas en modo semiautomático: el modelo procesó el volcado de la base de datos, extrajo los contenidos, restauró las relaciones entre entidades, generó plantillas lo más parecidas posible a las originales y colocó todo en una estructura que replica punto por punto las antiguas URLs. Tras la primera pasada hizo falta varias iteraciones de correcciones —en algún sitio la maquetación se descuadró, en otro la taxonomía no se mostró como debía—, pero eso ya se parecía a una revisión habitual, y no a desarrollar desde cero.

Qué se obtuvo al final

El resultado superó las expectativas. En lugar de la pesada combinación MySQL y código PHP antiguo, un sitio ligero y rápido, exteriormente casi indistinguible del antiguo. La carga en memoria y CPU del servidor cayó varios órdenes de magnitud: nginx simplemente sirve archivos estáticos. El volumen de datos se redujo un orden de magnitud: en lugar de gigabytes de caché incomprensible de Drupal en la base, ahora hay un conjunto de archivos HTML ligeros que se pueden copiar a una memoria USB y conservar durante veinte años —no necesitan ningún proceso en ejecución para vivir.

La moraleja es bastante sencilla. A veces merece la pena invertir unas horas precisamente para ahorrar recursos durante años y no perder aquello que realmente quieres preservar. Y este es exactamente el caso en el que la IA no sustituye al pensamiento ingenieril, sino que le quita la rutina: el diseño de la arquitectura de la migración y la preservación de la estructura de enlaces todavía tuvo que hacerlo una persona, mientras que la parte mecánica —procesar el volcado, generar las plantillas, distribuir los archivos— se pudo confiar con seguridad al modelo, dedicándose uno a verificar el resultado y no a escribir código línea por línea.