From WordPress to Astro: Why We Rebuilt Our Own Site

The site you're reading runs on Astro. Until recently it ran on WordPress with Elementor, served from an EC2 instance we kept patched and paid for every month. We rebuilt it from scratch — and because helping other people modernize software is literally what we do, we figured the honest, gotchas‑included version of that decision might be useful to anyone weighing the same move.

Short version: for a mostly‑static marketing or content site, Astro gets you a faster, cheaper, more secure, more maintainable site — if you have (or can hire) a developer. WordPress still wins when non‑technical people need to publish every day through an admin panel. The rest of this post is the long version, including the parts nobody warns you about.

First, be honest about what your site actually is

Before choosing any technology, we wrote down what the site really was. Ours came out to about six pages — Home, How We Work, Why Us, Clients, Careers, Contact — updated once or twice a month. No store, no logins, no user accounts, no dynamic content. A copyright date that still said 2021. In other words:

It was a brochure site, not a web app. That single fact drives the whole tech decision.

WordPress is a genuinely great tool — it powers a huge share of the web for good reasons. But it's built to be a dynamic content‑management platform: a database, a PHP application server, an admin UI, plugins, themes. A six‑page brochure uses almost none of that capability — and pays every one of its costs anyway.

What WordPress was quietly costing us

None of these are WordPress "bugs." They're the price of running a dynamic app platform to serve what is, functionally, static HTML:

• A server to babysit. An EC2 instance, an OS, PHP, and a MySQL database — all needing updates, backups, and a caching story, just to render a handful of pages.
• A standing security surface. WordPress core, the theme, and every plugin are code you didn't write, on an update schedule you don't control, that you're nonetheless responsible for keeping patched.
• Performance overhead. Each page is assembled by PHP hitting the database on request (unless heavily cached), and Elementor ships a lot of CSS and JavaScript to render a layout that is ultimately just text and images.
• Real monthly cost for the instance and its upkeep — to serve content that could live on a free static tier.

To be fair to WordPress: if non‑technical editors own the site day‑to‑day, or you lean on its ecosystem (WooCommerce, memberships, complex forms), those "costs" buy you things you actually need. We didn't need them.

Why Astro fit

Astro is built for exactly this: content‑driven marketing sites, blogs, and docs. The properties that made it the obvious choice for us:

• Static‑first, so it's fast. Astro ships plain HTML and CSS with essentially zero JavaScript by default. Pages are built once at deploy time and served straight from a CDN — quick, everywhere, with nothing to render on request.
• You own the markup. There's no page‑builder abstraction between you and the output. That's what let us match the old site pixel‑for‑pixel first, then redesign it freely into the dark theme you're looking at.
• A tiny security surface. No server, no database, no plugin admin to exploit. A static site is about as hard to attack as a folder of files.
• Git push → auto‑deploy. The site lives in a Git repo; a push builds and deploys it (Cloudflare Pages, in our case) with no server to manage — and a free tier that easily covers a site this size.
• Content as files. Copy lives in Markdown/components, which suits an "I describe the change, it gets built and I review it" workflow far better than clicking around a page‑builder UI.

We paired it with Tailwind CSS for a consistent design system we could adjust quickly, and deployed to a static host on the free tier. Git push, auto‑deploy, no server, near‑zero cost.

The honest trade‑off

Astro isn't free of downsides — it just moves them somewhere that suited us. The real one: there's no CMS admin panel. Editing content means editing files (or a pull request), which is fine when a developer or partner makes the changes, and a genuine loss if non‑technical people need to publish on their own every day.

That's not a dead end, though. If you later want dashboard‑style editing without touching code, you can wire in a lightweight headless CMS (Decap, TinaCMS, and friends) that gives editors a UI while writing changes back to the same Git repo — so the site stays static and fast underneath. WordPress for the editors, static output for everyone else, in effect.

How we migrated — with zero downtime

The migration itself was low‑drama by design, and it rhymes with how we modernize larger systems: treat the thing that's live as the specification, reach parity first, and only then improve.

1. Leave the old site running. The WordPress/EC2 site kept serving real traffic the entire time.
2. Build the new site in parallel — carrying the content across, re‑hosting the images, rebuilding the structure as reusable components instead of duplicated widgets.
3. Verify the new site on a preview URL until it matched.
4. Flip DNS to the static host once it was right — the cutover is just a DNS change.
5. Decommission the EC2 instance and stop paying for it.

Nobody visiting the site saw a maintenance window, because the old site never went down before the new one was ready.

The gotchas nobody warns you about

From doing it for real, here's where the time actually went:

• Fonts. Page‑builder sites tend to pull several typefaces from a font CDN, and the count creeps up as different widgets get added over the years — we found the old site loading a handful. Audit which faces you actually use, then self‑host the woff2 files: faster, consistent, and no third‑party request on every page load.
• Anything dynamic needs a plan. A static site can't run PHP's mail(). Our contact form now posts to a small serverless function that sends the message through Amazon SES. Forms, search, gated content — each becomes a function or a hosted service rather than a plugin (see Fig. 2).
• You now own the SEO and redirect plumbing. There's no Yoast doing it for you: you add the sitemap, robots.txt, canonical and social tags, and — importantly — the redirects from old URLs to new ones, yourself. Keep that list honest. (We learned this the pointed way: a leftover /about → / line in our redirects file quietly sent one page to the homepage until we spotted it. You own these now, so audit them.)

# public/_redirects — you own these now
/what-we-do   /why-us    301
/book-a-call  /contact   301

• Secrets are picky, and bind at deploy time. On Cloudflare Pages, environment variables are baked in when a deployment builds — change one and you must redeploy. And a stray trailing space in a variable's name will silently break a lookup while everything looks correct in the dashboard. That one cost us an hour.

So which should you choose?

Stay on WordPress if non‑technical people publish frequently through an admin UI, you rely on its plugin ecosystem (a store, memberships, complex integrations), or you have no developer capacity and won't hire it out.

Move to Astro if it's a mostly‑static marketing, content, docs, or blog site; performance, security, and low cost matter; and you have a developer or a partner to build and maintain it. And if you want the best of both, the middle path is real: Astro for speed and safety, a headless CMS on top so editors still get a dashboard.

The payoff

The site you're on now is a set of pre‑built static pages on a global CDN. No database or plugins to patch, no EC2 instance to maintain, near‑zero hosting cost, a Git‑based deploy pipeline, and a codebase we fully control. The contact form still sends email; analytics still works; the SEO is intact — all without a server to babysit. For a brochure site, that's not a compromise. It's just the right shape.

If you're staring at your own aging WordPress install wondering whether it's worth it: that's the honest picture. And if you'd like help making the move, that's exactly the kind of work we do.