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

Tengo un proyecto al que le tengo un cariño especial. Hace quince años hice un portal de noticias para una pequeña ciudad: un sitio regional habitual que durante varios años funcionó correctamente, publicaba noticias y poco a poco se fue llenando de contenido. Luego el proyecto como medio cerró: el equipo se dispersó, las noticias dejaron de publicarse y el sitio quedó colgado en Internet como testigo silencioso de aquella época.

Su valor ya no está en las noticias — ¿a quién le interesa un artículo sobre la reparación de la red de calefacción de hace diez años? El valor está en otra cosa: es un molde de todo un período de la vida de la ciudad, registrado de una forma que nadie más volverá a registrar. Y la Internet moderna, en general, no sabe conservar la memoria: los sitios se cierran, los dominios no se renuevan y capas enteras de historia local desaparecen sin dejar rastro. No podía resignarme a abandonar algo así.

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 seis— no se había actualizado en muchos años, porque no había realmente a dónde actualizar: la rama está muerta, la comunidad hace tiempo que avanzó. Y el sitio, además, seguía siendo bastante voluminoso y antiguo, es decir, un bocado apetecible para los bots de búsqueda, scrapers y demás fauna automática que adora precisamente esos recursos de archivo con una rica historia de enlaces.

Y aquí empezaba un círculo vicioso. Los bots machacaban el sitio sin parar, la caché de la base de datos se hinchaba hasta tamaños indecentes, la tabla de sesiones se desbordaba, el servidor de vez en cuando caía bajo la carga —y yo otra vez tenía que arreglar lo que se rompía por sí solo, sin ninguna acción mía. La lógica sugería una conclusión sencilla: mantenerlo como estaba es caro, sin sentido y cada año peor. Pero tampoco quería simplemente dejar que el sitio muriera.

Por qué las soluciones evidentes no servían

Si no hay actualizaciones a la vista, entonces el motor no sirve —hay que pasarlo a estático. Lógico. Pero cómo obtenerlo no es tan trivial como parece.

La vía más simple es descargar el sitio tal cual, página por página. Rápido, pero chapucero: en un Drupal antiguo seguro se había acumulado una montaña de duplicados —los mismos materiales disponibles en varias direcciones, con diferentes parámetros, a través de taxonomías y sin ellas. Con ese enfoque la búsqueda dentro del sitio simplemente dejaría de funcionar, y cualquier pequeña corrección en el futuro —si acaso fuera necesaria— con alta probabilidad rompería algo, porque la estructura resultaría una papilla opaca de HTML raspado.

La segunda opción es trasladar el contenido a un motor nuevo por completo, con la base, con las taxonomías, con un modelo de datos normal. Suena correcto, pero en términos de esfuerzo es un proyecto completo por sí solo, no una tarde de trabajo. Y lo más importante: el riesgo de perder lo más valioso —la estructura de enlaces—. A ese archivo llegaban enlaces durante años desde redes sociales, foros, otros sitios e incluso desde los resultados de búsqueda. Romper las URLs es borrar precisamente esa memoria por la que todo comenzó.

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

Al final encargué a Claude Code que desentrañara el sitio por partes: analizar plantillas de presentación, estructura de la base de datos y lógica de formación de direcciones, y después trasladar todo eso a Hugo —un generador estático ligero sin servidor, base ni PHP debajo del capó.

El trabajo llevó unas horas en modo semiautomático: el modelo revisó el volcado de la base, extrajo los artículos, restauró las relaciones entre entidades, generó plantillas lo más parecidas posible a las originales y lo organizó todo en una estructura que replica punto por punto las antiguas direcciones. Tras la primera pasada hubo varias iteraciones de corrección —a veces la maquetación se descolocaba, otras la taxonomía no se mostraba como debía—, pero eso ya se parecía más a una lectura de pruebas que a desarrollar desde cero.

Qué salió al final

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

La moraleja es bastante simple. A veces merece la pena dedicar unas horas de trabajo precisamente para ahorrar recursos durante años y no perder lo que realmente quieres conservar. Y este es exactamente el caso en el que la IA no sustituye al pensamiento ingenieril, sino que le quita la rutina: pensar la arquitectura de la migración y la conservación de la estructura de enlaces aun correspondía a una persona, pero la parte mecánica —analizar el volcado, generar las plantillas, distribuir los archivos— se puede entregar con confianza al modelo y ocuparse de la revisión del resultado, no de escribir código línea por línea.