Migrating the Blog from WordPress to Hugo with OpenCode
My last post was published in March 2021, and since then, almost nothing has happened with the blog - despite moving, server changes, and numerous other developments. WordPress had been more irritating than helpful for returning to writing posts: it was slow, required constant plugin updates, and security vulnerabilities kept pouring in, while for a blog that only publishes a few posts per year, it was overly complex.
For years I had been considering switching to a static site generator, but the thought of migration - 87 posts, lots of HTML remnants, media files - always deterred me. Then I discovered OpenCode, and everything changed.
Migration Plan#
OpenCode is a terminal-based AI tool that allowed me to automate most of the migration process. The plan consisted of five main steps:
- WordPress content export and Markdown conversion to Hugo structure
- Removal of old HTML remnants
- Relocation of PrivateBin (ZoliBin) service
- Configuration of multilingual Hugo site
- Translation of all posts into four languages
The last two points seemed particularly ambitious, but ultimately I managed to implement them.
Content Export and Conversion#
Using WordPress’s built-in export function, I extracted all content in XML format. I tasked the AI with writing a script that converted this to Hugo-compatible Markdown format, preserving titles, dates, categories, and tags. Shortcodes were converted to HTML/Markdown equivalents, and Disqus comment identifiers remained in the front matter.
Media files were copied to Hugo’s static/ folder, so old links continue to work.
HTML Cleaning#
WordPress content contained numerous HTML remnants that Hugo couldn’t handle properly: unnecessary characters, special code blocks, WordPress-specific image tags, and other formatting.
The AI reviewed all posts and converted HTML to Markdown where possible. More complex formatting was preserved thanks to the unsafe = true parameter set in Hugo’s config.toml. This allowed old HTML content to still display without having to manually rewrite everything.
ZoliBin Relocation#
I kept the ZoliBin (PrivateBin) paste service in its original location, still accessible through nginx reverse proxy. Since Hugo is a static site, it doesn’t require PHP, but the paste functionality was still needed. The configuration remained unchanged: file-based storage, 1-week expiration, password protection.
Multilingual Setup#
I configured Hugo’s multilingual support for four languages: Hungarian (default), English, Portuguese, and German. The defaultContentLanguageInSubdir = true setting allowed Hungarian content to remain accessible under the root domain.
Menu items were translated into all languages, but URL slugs remained in Hungarian for migration simplicity. Media files continue to be available at the old paths thanks to Hugo’s static/ folder.
Translation Process#
The translation went quite uneventfully, it was just a simple prompt (of course the AI continuously updated the AGENTS.md, and the documentation also ended up there regarding the site structure).
Homepage Issues#
An interesting bug emerged with Hugo version 0.146: the content/index.md file created a leaf bundle that prevented other content from rendering. The solution was to delete the file and move homepage configuration entirely to config.toml.
The Terminal theme template also had to be modified because the multilingual homepage didn’t filter posts correctly. Using .Site.RegularPages solved the problem, so only Hungarian content appears on the Hungarian homepage.
Results and Lessons#
The migration took a few hours, with most time spent on re-prompting the AI agent while watching how the migration progressed and seeing various problems on the building site.
The result is a fast, static Hugo site that doesn’t require PHP and consumes minimal resources. Automatic updates ensure the latest version always runs.
All this made it possible for 261 translations and HTML cleaning to be a few hours’ work instead of a month’s. The GLM 5.1 model produced good translations, and where it erred, it did so consistently, enabling quick fixes. Unfortunately, the translation quality wasn’t always perfect, so I had to run the deepseek-v3.1.671b model afterwards for final touches.
Honestly, I didn’t think an AI agent would be capable of such a complex migration, and it makes me wonder how much need there will be for sysadmins in the future. Reading programming subreddits, it’s already visible that instead of simple coding, people are moving more into project manager/product owner positions.
The question is, how will the profession produce future IT professionals if there’s no longer a need for entry-level (1st level) helpdesk staff. I don’t think we’ll have to wait long for the answer…