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

I have a 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 reliably for several years, published news and gradually accumulated materials. Then the project, as a media outlet, shut down: the team dispersed, news stopped coming out, and the site remained on the internet as a testament to that time.

Its value has long ceased to be in the news — who cares about a ten-year-old note about repairing the heating main? The value is elsewhere: it’s a snapshot of an entire period of the city’s life, recorded in a way no one else will record it. And the modern internet is poor at preserving memory: sites shut down, domains aren’t renewed, and whole layers of local history disappear without a trace. I couldn’t abandon it.

When the old engine starts to retaliate

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 has long since moved on. Meanwhile the site remained large and old, which made it an attractive target for search bots, scrapers and other automated clients that especially like archival resources with a rich history of links.

A vicious circle began. Bots loaded the site non-stop, the cache table grew to indecent sizes, the sessions table overflowed, the server would periodically crash under load — and I would once again go and fix what had broken without any action on my part. The conclusion was obvious: maintaining it further in its current form was expensive, pointless and getting worse every year. But I didn’t want to let the site die.

Why the obvious solutions didn’t fit

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

The simplest route is to crawl the whole site, page by page. Fast, but sloppy: an old Drupal will inevitably have accumulated a heap of duplicates — the same materials available under multiple addresses, with different parameters, through taxonomies and without. With that approach site search would stop working, and any small edit in the future would very likely break something, because the structure would become an opaque mass of downloaded HTML.

The second option is to migrate the content to a new engine in full, with the database, taxonomies and a proper data model. Sounds right, but in terms of labor this is a full-blown project, not an evening’s work. And the main risk is losing the most valuable thing: the link structure. For years social networks, forums, other sites and search results linked to that archive. Breaking the URLs would mean destroying the very memory this was all about.

The solution was found at the intersection of analysis and automation

In the end I entrusted Claude Code to dissect the site in parts: analyze the display templates, the database structure and the logic of URL formation, and then port all of that to Hugo — a lightweight static site generator that doesn’t need an application server, a database or PHP.

The work took a few hours in semi-automatic mode: the model parsed the database dump, extracted the content, restored relations between entities, generated templates as close as possible to the originals, and laid everything out into a structure that exactly reproduces the old URLs. After the first pass a few iterations of fixes were needed — somewhere the layout broke, somewhere a taxonomy was rendered differently than needed — but that already resembled normal proofreading rather than development from scratch.

What came out the other end

The result exceeded expectations. Instead of a heavy stack of MySQL and ancient PHP code — a light, fast site, visually almost indistinguishable from the old one. Memory and CPU load on the server dropped by orders of magnitude: nginx simply serves static files. The size of the data was reduced by an order of magnitude: instead of gigabytes of obscure Drupal cache in the database there is now a set of lightweight HTML files that you can copy to a flash drive and keep for twenty years — they don’t need a single running process to live.

The takeaway is simple. Sometimes it’s worth spending a few hours specifically to save resources for years ahead and not lose what you truly want to preserve. And this is exactly the case where AI doesn’t replace engineering thinking but removes the routine from it: designing the migration architecture and preserving the link structure still had to be done by a person, while the mechanical part — parsing the dump, generating templates, laying out files — could confidently be handed to the model, leaving you to verify the result rather than write code line by line.