I had been talking about moving to Astro for months before I actually did it. The conversation usually went: "Yes, Astro is faster, cleaner, cheaper, and more portable than WordPress. I should migrate." Then I would open WordPress and publish another post because the migration felt enormous and the current system, while frustrating, was working.
What changed was building a proof of concept that took less than a day.
The proof of concept
I took the design system from Vatican Bulletin, a site I was already rebuilding, and stood it up in Astro as a test. Same colours, same typography, same layout. The question was simple: does this look and feel as good as the WordPress version?
It looked better. The CSS that had been fighting Twenty Twenty-Five's theme.json for weeks rendered perfectly first time. No cascade conflicts, no block editor overrides, no specificity wars. Just clean CSS doing what CSS is supposed to do.
Every time I asked my code client to write CSS for an off-white heading against a dark background, the master CSS rewrote it. It looked right in the CSS I wanted, even looked right in the heading settings, but it was always overwritten. Here I was spending too much time wrangling settings, rather than creating content (again). When I sent my CSS design into Astro, it just rendered.
The build time was under 10 seconds. The page load was instant. The Lighthouse score was effectively perfect. And the entire hosting cost was zero because Cloudflare Pages serves static sites for free.
The actual steps
Here is what the migration to PatrickHughes.ai as the first live Astro site involved. Not the theory, the reality.
Setting up the infrastructure took about an hour. Create a GitHub repository. Sign up for Cloudflare Pages (free). Connect the repo to Cloudflare. Point the domain. Every push to the main branch now auto-deploys the site to a global CDN. That is the entire deployment pipeline. No server to configure, no PHP, no database server, no cPanel.
Scaffolding the Astro project was a terminal command: npm create astro@latest. Choose the minimal template. Install Tailwind if you want it (I did not for this build, preferring vanilla CSS with custom properties for portability).
Translating the design was where the real work happened. I had already designed the homepage and article page as React mockups in conversations with Claude. Those JSX components translate almost directly to Astro components because Astro's template syntax is essentially HTML with a data section at the top. The colour tokens, font stacks, and spacing values copy across unchanged. I spent an hour or so finagling and cogitating about the design (fonts are a bugbear for me), but the actual build out to JSX is pretty quick (minutes).
Content setup for PatrickHughes.ai started with markdown files in the repository. Each post is a .md file with frontmatter for title, date, category, tags, and excerpt. Astro's content collections handle the rest: it validates the frontmatter against a schema, generates types, and gives you a clean API to query posts by date, category, or tag. This is where I spent some time, maybe 2 hours total.
The Supabase connection came later. For a small site with manual publishing, markdown files in the repo are simpler. But the plan was always to connect to Supabase so that Mission Control (my custom CMS) could write posts that appear on the site automatically. That integration is a single utility file that creates a Supabase client, and the page templates swap from reading markdown to querying the database. The template HTML stays identical.
What was harder than expected
Images. Astro's built-in image handling is excellent (automatic WebP conversion, responsive sizes, lazy loading), but moving from WordPress's media library to a file-based system requires thinking about where images live and how they are referenced. For PatrickHughes.ai this was straightforward because the site is typography-driven with minimal imagery. For IrelandExplore with hundreds of photos, this will be a bigger consideration and I've taken the opportunity to take an alt text and captioning tool as part of the process.
RSS and sitemaps. WordPress generates these automatically. In Astro, you install the official plugins (@astrojs/sitemap and @astrojs/rss) and configure them. It takes ten minutes but it is ten minutes you would not have thought about if you are used to WordPress doing it silently.
The mental shift. The biggest adjustment was not technical. It was accepting that there is no admin panel. No login screen on your domain. No familiar WordPress dashboard. You write content, push it, and the site rebuilds. For someone who has used WordPress in some form for just over 20 years, that feels exposed at first. There is no "save draft" button in the browser. There is no media library to drag images into. (Unless you build it!).
This is exactly why I am building the TipTap editor into Mission Control. The editing experience matters, especially for the travel properties where I produce content at volume. But for PatrickHughes.ai, where I publish a few posts a month, the simplicity of markdown files or a Supabase entry is a feature, not a limitation.
What was easier than expected
CSS. After months of fighting WordPress themes, writing CSS that just works felt like coming home. No cascade from a parent theme. No block editor injecting styles. No !important arms race. You write a class, it does what you said. That is it.
Deployment. Push to GitHub. Site is live in 30 seconds. No FTP, no cPanel, no "clear cache and pray." Cloudflare Pages handles SSL, CDN distribution, and build automation. The entire DevOps layer is someone else's problem.
Performance. I did not have to optimise anything. A static Astro site on Cloudflare is fast by default because there is nothing to slow it down. No PHP execution, no database queries, no JavaScript framework loading. Just HTML files served from the nearest edge node.
Claude Code. Having an AI that can write and modify Astro components, CSS, and configuration files made the build dramatically faster than it would have been if I were learning Astro from documentation alone. I described what I wanted, Claude Code wrote it, I reviewed, tweaked it and pushed. The learning curve for Astro is gentle anyway, but with AI assistance it is nearly flat.
The score card
<h3>The score card</h3>
<table>
<thead>
<tr>
<th></th>
<th>WordPress</th>
<th>Astro</th>
</tr>
</thead>
<tbody>
<tr>
<td>Hosting cost</td>
<td>$240 a year</td>
<td>Free (Cloudflare Pages)</td>
</tr>
<tr>
<td>Page load</td>
<td>2-4 seconds typical</td>
<td>Under 1 second</td>
</tr>
<tr>
<td>Build/deploy</td>
<td>Instant (dynamic)</td>
<td>10-30 seconds (static rebuild)</td>
</tr>
<tr>
<td>CSS control</td>
<td>Fighting the theme</td>
<td>Complete</td>
</tr>
<tr>
<td>Content editing</td>
<td>Browser-based admin</td>
<td>Markdown / CMS / TipTap</td>
</tr>
<tr>
<td>Plugin ecosystem</td>
<td>Thousands</td>
<td>None (you build what you need)</td>
</tr>
<tr>
<td>Vendor lock-in</td>
<td>Theme + plugins + hosting</td>
<td>None (standard HTML/CSS)</td>
</tr>
<tr>
<td>Security surface</td>
<td>PHP + database + plugins</td>
<td>Static files only</td>
</tr>
</tbody>
</table>
The migration order
PatrickHughes.ai was the right first site because it is new, low-traffic, and content-light. The stakes were zero.
Vatican Bulletin is next because it is a new site with minimal existing content. The WordPress version was always temporary.
The established travel properties (Planet Patrick, IrelandExplore, CruiseDirector) will follow once the CMS editor is solid and the content pipeline can write directly to Supabase. Those migrations carry real risk because they have traffic, revenue, and indexed content. The lesson from the first two builds will de-risk them.
When I'm confident enough to move a revenue-maker, I'll do so cautiously and watch the ad program and affiliate links like a hawk. But I'd expect to have my entire blog network on Astro by mid-2026.
Should you do this?
If you are running a single WordPress blog and it works, no. WordPress is fine. The ecosystem is mature, the editor is familiar, and the hosting is solved.
If you are running multiple content properties with automated pipelines, custom designs, and a growing dependency on AI tools that prefer clean HTML, then the move to a static site generator like Astro starts to make financial and architectural sense. The trigger for me was realising that my page builder had become the most expensive, least portable, and most fragile layer in the stack.
The build itself is not difficult. The mental shift is the hard part. Once you accept that "no admin panel" is a feature rather than a gap, everything else falls into place.