Its been seven years since my last post here, this blog had been sitting on a hand rolled WordPress instance since 2012. Fifty-five posts, hundreds of images, a decade of accumulated plugins and hosting complexity for something that was fundamentally just text and pictures. I'd been meaning to move it to a static site generator and add HTTPS for years. The thing that finally made it happen was using Agentic AI (Claude). My blog has always been a place where I can learn and experiment with both writing and technology, I had forgotten how much I like building things.

This isn't a tutorial. There are plenty of WordPress-to-static migration guides out there. This is more of a reflection on what it's actually like to use an AI coding agent for a real, messy, end-to-end project — and what I learned about how to work with it effectively.

The Starting Point

The blog was running on WordPress, hosted on AWS EC2. The content spanned 2012 to 2019 — technical posts about scaling teams, WordPress infrastructure, product development, and engineering leadership. Many posts had embedded images, some had SoundCloud embeds, a couple had image galleries. The URLs had been shared and linked to over the years, so preserving them was non-negotiable.

We chose Eleventy as the target because it's lightweight, flexible, and I didn't need a framework — just a static site generator that could take markdown files and produce HTML.

What Actually Happened

The whole migration took about a week of evening sessions. There were several distinct pieces of work, each with their own challenges. The best part of this was it was like working with an agency doing all of the work in the background. I was able to use my extensive experience to break down the process into chunks and then outsource the doing to Claude. Humans doing the thinking with AI doing the doing is going to become more prevalent in the coming weeks, months and year. Even better the support I got wasn't just for coding but for design, tagging and performance.

Extracting the content. I had a MySQL dump of the WordPress database, so the first job was parsing that to extract the published posts. Claude built a SQL parser in Node.js that could handle WordPress's escaped content, then a migration script that converted the HTML to markdown using Turndown. This gave us the raw material — fifty-five posts converted to markdown, each with structured metadata at the top of the file that tells the site generator how to render it — the title, date, URL, and so on.

Handling the WordPress quirks. This was the bulk of the work. WordPress has years of accumulated implicit behaviour, and migrating content faithfully means dealing with all of it. SoundCloud shortcodes needed converting to iframe embeds. Caption shortcodes wrapping images needed unwrapping. Heading levels were inconsistent across posts and needed normalising. The wpautop function that WordPress uses to add paragraph tags created formatting issues when converted to markdown — walls of text where there should have been paragraphs. Image galleries were particularly fiddly, stored in a WordPress-specific shortcode format that needed converting to a CSS-only lightbox grid.

Migrating images. Hundreds of images were still hosted on the old WordPress CDN. Claude built a download script that pulled each image, saved it locally with the right directory structure, and updated the markdown references to point to the local paths. This ran post-by-post so we could verify nothing was missed.

Preserving URLs. The original WordPress URLs had been shared and linked to over the years. Every single one needed to work on the new site. This meant matching Eleventy's permalink structure to the old WordPress slugs and validating that all fifty-five URLs resolved correctly.

Building the validation suite. A comprehensive script that checked URL preservation, image integrity, internal links, HTML meta tags, RSS feed entries, and sitemap coverage. This became the safety net for the whole project — every change could be verified automatically against it.

Deployment and infrastructure. A GitHub Actions pipeline that builds the site, runs validation, syncs to S3, and invalidates the CloudFront cache. Plus the SEO fundamentals: Open Graph tags, canonical URLs, sitemap, robots.txt, and a 404 page.

By the end: 55 posts migrated, 138 images preserved, all original URLs maintained, automated deployment, and a validation suite that gave me confidence nothing was broken.

What I Learned About Working with AI Agents

Batch and iterate, don't try to do everything at once

The most effective pattern was migrating posts in small batches — typically five at a time — visually checking the output, then fixing whatever was wrong before doing the next batch. Each batch surfaced new edge cases, and fixing them improved the migration script for all subsequent batches.

When I tried to do too many posts at once, the problems compounded and it was harder to see what had gone wrong. Small batches with fast feedback loops worked much better.

Invest in validation early

The validation script was one of the best decisions of the project. Once it existed, every subsequent change could be verified automatically. It checked things I would never have manually tested — every single URL preserved, every image reference resolving, every post appearing in the RSS feed.

Building that kind of safety net early freed me up to move faster on everything else. It's the same principle as writing tests before refactoring, applied to a migration.

The AI is excellent at the tedious parts

Parsing WordPress SQL dumps. Converting shortcodes. Downloading and re-referencing hundreds of images. Generating consistent content structures. These are the kinds of tasks that would have taken hours of manual effort and been incredibly error-prone. Claude handled them reliably and fast.

But you need to stay in the loop on decisions

The places where things went wrong were almost always about context that I hadn't communicated. WordPress has a lot of implicit behaviour — the way wpautop adds paragraph tags, the way galleries are stored, the way internal links are structured. Claude doesn't know your specific WordPress setup unless you tell it, and even then, some things only become apparent when you look at the rendered output.

The most productive pattern was: let Claude do the implementation, but review the output yourself. Not the code — the actual rendered blog posts in the browser.

The long tail is where the time goes

The initial migration — getting posts from WordPress into markdown — was maybe 20% of the total effort. The other 80% was everything else: fixing formatting edge cases, handling embeds, getting images right, setting up deployment, SEO, validation. This is true of most software projects, but it's worth remembering when you're estimating how long an AI-assisted project will take.

Would I Do It Again This Way?

Without question. What would have been a tedious multi-weekend project became a fun background task across a week. The migration scripts, the validation suite, the deployment pipeline — none of these are things I'd have built if I were doing it manually. I'd have done it by hand, made mistakes, and not had the safety net to catch them.

The experience also changed how I think about using AI for engineering work more broadly. The key insight isn't that AI can write code — it's that AI changes what's worth automating. Tasks that would previously have been too small to justify writing a script for suddenly become worth scripting, because the cost of creating that automation has dropped so dramatically.

That's the real shift. Not "AI writes code for me" but "the economics of automation have fundamentally changed." And I think we're still in the very early days of understanding what that means.

Claude also wrote this post for me (promise that this won't be the case in the future) based on the existing content and our conversations together.