The NimblePros blog, which you are reading at this very moment, is a static site. There are a lot of advantages to not using a CMS like WordPress, Wix, or Sitecore. While those dynamic, database and server driven sites are great for certain purposes, they come with a lot of overhead. If all you want is a blog, they’re massive overkill.
On the other hand, it can be difficult to maintain a blog, even a simple one, by hand, especially if you add or change content frequently. Therein lies the advantage of static site generator tools like Hugo and Gatsby. You add and update your content, then these JavaScript driven tools turn that content into static web pages with all the proper links, optimized images, updated search indexes, and so forth. You focus on the content and the static site generator does the rest.
A Tale of Two Site Generators
We’ve used Gatsby for quite a while, but we weren’t entirely happy with how it was working for us, and for some time now we’ve wanted to migrate to using Hugo to generate the site. Unfortunately, while most all of the static site generator tools use Markdown files as the source files for the content, each tool tends to use them in a slightly different way. The Markdown file has a header at the top, called the ‘frontmatter’ that holds all the metadata the tool uses to generate certain parts of the page content. This tends to include things like the title, the author, the publish date, a summary description, and so forth. While the general details are usually the same, the implementation can change from tool to tool.
Not only that, because the frontmatter templates are completely customizable, various themes in the same tool could have completely different frontmatter structures. It’s entirely up to the author of the theme how they want to implement it, within certain general guidelines. For someone migrating a site, you’re left with the options of either converting all of your posts to the structure the theme you pick uses, or coding your own theme that uses the structure you already have in place. For a site with a couple of hundred existing blogs posts, either option is an arduous task to undertake.
The Great AI Experiment
It is all just an experiment, right?
As mentioned, we had been discussing migrating our blog to Hugo for a little while now. It was one of those to-do tasks that someone might get around to at some point, in their spare time, if they ever have any. I don’t think anyone was looking forward to converting all those blog post headers, or writing a custom theme, or whatever solution it ended up being in the end.
As I was wrapping up a particular client task one morning, a thought hit me: There must be an easier way to automate converting all those headers. Or maybe there would be a really easy way to convert the entire site and keep the existing structure. That seemed like the perfect job to test against AI.
I opened up Claude and entered a simple prompt:
“I have a Gatsby based blog site in folder A. Convert it to a Hugo based site in a new folder”.
With a press of the Enter key, Claude was off and running. In under 15 minutes it had generated a hugo base site in another folder, including all the project templates and folder structure appropriate to a Hugo based website. It even recognized that as an active site with content getting added regularly, there should be an easy way to migrate blog posts. As such, it included a Powershell script to compare the two site content folders and migrate any missing posts from the Gatsby folder to the Hugo folder.
It also structured the templates and layout in Hugo to match nearly exactly the way that it was set up in Gatsby, including the structure of the frontmatter headers. That’s not to say that everything went perfectly. Of course it didn’t. This is AI we’re talking about. But it got us 90% of the way there in a very short amount of time.
Take this example from our own site, in 2 versions:
```Hugo Version
title: Enhancing Telemetry in Aspire
authors: [barretblake]
date: "2026-02-19T00:00:00.000Z"
description: "Aspire has basic support for OpenTelemetry out of the box. But what about when we're ready to do more."
featuredImage: ./aspire-telemetry-hero.webp
categories: [software-development]
series: aspire
```Gatsby Version
title: Enhancing Telemetry in Aspire
author: barretblake
date: "2026-02-19T00:00:00.000Z"
description: "Aspire has basic support for OpenTelemetry out of the box. But what about when we're ready to do more."
featuredImage: ./aspire-telemetry-hero.png
category: software-development
series: aspire
They look the same, right? Well, no, they’re not. Look at author/authors, and category/categories. In Gatsby, they’re a single entry. In Hugo, they’re treated as arrays internally. We ended up having to tweak the headers across the posts anyway, but that was a relatively minor fix to make.
It also failed entirely to implement the search functionality. The input box was there, and entering a value opened the “search” page, but that was it. Nothing would appear. I tried initially to have GitHub Copilot generate a search function. And it worked all right, but in the end we decided it would be a good time to upgrade the search functionality and we implement Pagefind, which is a pretty good Javascript based search tool for static sites.
Again, I let AI do the work. A simple command to Copilot to replace the custom search function with Pagefind and in just a few minutes, our search feature was greatly enhanced. All that was left was to fix a little bit of the styling and we were good to go.
Another initial miss was that the dark mode button didn’t work. It took a couple of prompts to Claude to completely address the issue, but again, it only took a couple of minutes, where it might have taken me 15 or 20 minutes of stepping through and debugging Javascript code to track down the issue and fix it.
And there-in lies a benefit of having AI as your wingman. Sometimes it does a pretty good job of rapidly diagnosing the issue and devising a resolution. Sometimes… Ok, well, probably about 70% of the time. The rest of the time it will still wander off into the hedges on some side-quest only it can understand and you have to guide it back onto the path and you’ll get to the hear the worst words AI can say to you: “You’re right!”. Any time you get a response like that you know something has gone really, really wrong.
Conclusion
There were various other fixes and tweaks we needed to make. For the most part I let AI do the work. For example, for the authors that had no blog posts currently, the site refused to show their profile page. I asked Copilot to figure out why, and a minute later the issue was fixed. As another example, we needed a build and setup script. The AI wrote what we needed in Powershell in just a minute or so, then later converted that script from Powershell to bash automagically so we could set up the development environment in a dev container.
In the end, migrating our blog is a task that would have taken a developer at least a couple of days worth of hours to complete was accomplished in just 3 or 4 hours of actual effort total, with much of that time being spent prompting the AI, letting it run, then checking back in a few minutes to verify the result. In the end, prompting AI is essentially the same as managing a junior level developer. I’ve done both.
AI can be a great thing, properly implemented. For this task, it worked quite well. It’s still not going to create an enterprise level application for you. At least, not one that will work well. But for this, it worked pretty well. The result for us was a blog site migrated quickly and easily. It matches the previous version nearly exactly, with a few improvements thrown in for good measure. You’re reading the proof.