How I put Drupal to rest and didn’t lose fifteen years of a small town’s history

I have one project that I treat with particular care. Fifteen years ago I built a news portal for a small town — a typical regional site that ran faithfully for several years, published news, and slowly accumulated content. Then the project as a media outlet folded: the team dispersed, news stopped being published, and the site remained on the Internet as a silent witness of that time.

Its value long ago ceased to be in the news — who cares about a note on heating-pipe repairs from ten years ago. The value is different: it’s a snapshot of an entire period of the town’s life, recorded in a way that nobody else will record. And the modern Internet generally doesn’t know how to preserve memory — sites shut down, domains aren’t renewed, and whole layers of local history simply disappear without a trace. I couldn’t bring myself to abandon it.

When the old engine starts to take revenge

The trouble is that time is merciless to technical debt. The site engine — Drupal 6 — hadn’t been updated for many years, because there was nowhere to update to: the branch is dead, the community moved on a long time ago. Meanwhile the site remained quite large and old, which made it a tasty target for search bots, scrapers, and other automated creatures that love exactly these archival resources with rich link histories.

That’s where the vicious cycle started. Bots hammered the site non-stop, the cache store swelled to obscene proportions, the sessions table overflowed, the server would periodically crash under load — and I found myself once again fixing things that broke by themselves without any action on my part. Logic suggested a simple conclusion: keeping it as it was is expensive, pointless, and gets worse every year. But I didn’t want to just let the site die either.

Why the obvious solutions didn’t fit

If no updates are forthcoming, the engine isn’t needed — we need static. Makes sense. But how to get it is not as trivial a question as it seems.

The easiest path is to download the site as-is, page by page. Fast, but crude: an old Drupal inevitably accumulated a mountain of duplicates — the same materials are available under multiple addresses, with different parameters, via taxonomies and without. With that approach site search will simply stop working, and any small edit in the future — if needed — will very likely break something, because the structure will be an opaque mush of scraped HTML.

The second option is to migrate the content to a new engine entirely, with the database, taxonomies, and a proper data model. Sounds right, but in terms of effort that’s a full project, not an evening’s work. And most importantly — the risk of losing the most valuable thing: the link structure. For years links from social networks, forums, other sites, and even search results pointed to that archive. Breaking URLs means erasing exactly the memory we were trying to preserve.

The solution was found at the intersection of analysis and automation

In the end I tasked Claude Code with dissecting the site in parts: analyzing the display templates, the database structure, and the URL formation logic, and then translating all of that to Hugo — a lightweight static generator with no server, database, or PHP under the hood.

The work took several hours in a semi-automated mode: the model parsed the database dump, extracted the materials, restored relationships between entities, generated templates as close as possible to the original, and laid everything out into a structure that reproduces the old addresses exactly. After the first pass there were several iterations of fixes — sometimes the layout broke, sometimes a taxonomy displayed incorrectly — but that was more like ordinary proofreading than development from scratch.

What came out

The result exceeded expectations. Instead of the heavy combination of MySQL and ancient PHP code — a light and fast site, visually almost indistinguishable from the old one. Server load in terms of memory and CPU dropped by orders of magnitude — a fast nigix serves the static files and that’s it. The data size was reduced by an order of magnitude: instead of gigabytes of obscure Drupal cache in the database there is now just a set of lightweight HTML files that can be copied to a USB stick and stored for twenty years — they don’t need any running process to live.

The moral is fairly simple. Sometimes it’s worth spending a few hours of work precisely to save resources for years ahead and not lose what you really want to keep. And this is exactly the case where AI doesn’t replace engineering thinking but relieves it of routine: a person still had to think about the migration architecture and preserving the link structure, while the mechanical part — parsing the dump, generating templates, laying out files — could safely be handed to the model so I could focus on proofreading the result rather than writing code line by line.