# Migrating from WordPress to Astro — Bill Erickson > [!question] Lingering Questions > - At what edit frequency does the Git/Markdown editing tradeoff flip back in WordPress's favor? > - Where AI agents become the "editor" of a static site's content, does that re-justify a CMS (structured, queryable backend) even for otherwise-static sites? > [!tip] Article Ideas > - "Is your site actually using its CMS?" — a WordPress-vs-static decision scorecard for client work, using edit frequency as the discriminator instead of content type. #articleseed > [!link] Cross Reference > - [[3. Resources/Permanent Notes/The CMS Decision Turns on How a Site Is Edited Not What It Contains]] — this source's central claim, already captured as a Permanent note with this article as its origin. #xref > - [[3. Resources/MOCs/Product & Startup Instincts MOC]] — the underlying heuristic (match the tool to the actual workflow, not the surface category) generalizes past this one migration. #xref > [!quote] Vocabulary > - **Migration Inventory** — Erickson's practice of cataloging URLs, content types, taxonomies, redirects, embeds, images, templates, and SEO metadata into a `Migration Inventory.md` before any design work starts. ## Bib capsule Bill Erickson, "Migrating from WordPress to Astro," billerickson.net, June 2026. https://www.billerickson.net/migrating-from-wordpress-to-astro/ ## Author's thesis (Adler Q1+Q2) A 20-year WordPress developer and CultivateWP co-founder argues, against his own interest, that WordPress is not the automatic default for every site: for small-business sites that are mostly static and edited only a few times a year, a static Astro build on free Cloudflare hosting removes real maintenance, security, and performance burden that a CMS's editing workflow was never actually using. Using a real client migration (Sundheim Group), he lays out a transferable migration discipline — inventory before design, a preserve-don't-redesign brief, an AI agent for the first rebuild pass, and a mandatory human QA pass that catches the agent's silent failures (features that look present but are dead static markup). ## Key arguments - The deciding factor for WordPress-vs-static is how a site is edited, not what it contains — many "content" sites are really low-change brochures. - Migration discipline is the transferable part regardless of destination stack: inventory first, brief second, AI agent for the mechanical pass, human QA pass to rebuild what the agent silently broke. - The one hard, non-negotiable tradeoff is editing convenience: no admin UI, content lives in Git/Markdown — decide up front and let the client choose. ## Claim atoms ### WordPress is not the automatic default for every site > [!quote] ID:rw_pending > "WordPress is not always the right solution for a website. That is a strange sentence for me to write." **Where/why**: Said against interest by a veteran WordPress developer; reframes WordPress as one tool whose value is the editorial workflow, not a universal default. **Tags**: #xref #aphorisms #share ### Static Astro fits sites that don't need a CMS editing workflow > [!quote] ID:rw_pending > "Astro is a good fit when the public site is mostly static and the editing workflow does not need to happen in a CMS." **Where/why**: Names the actual discriminator — many business sites use WordPress as a database for pages that change a few times a year, paying for managed hosting, plugin updates, and security patching they don't need. Already promoted to a Permanent note. **Tags**: #xref #articleseed ### Start a migration with inventory, not design > [!quote] ID:rw_pending > "The first step is not design. It is inventory." **Where/why**: Catalog URLs, content types, taxonomies, redirects, embeds, images, templates, and SEO metadata into a `Migration Inventory.md` — this is what gives an AI agent a concrete migration target. **Tags**: #xref #aphorisms ### AI agents leave broken features as dead static markup > [!quote] ID:rw_pending > "the first Astro pass moved the visible content over but left broken functionality as static markup in the page." **Where/why**: The QA cleanup pass is the load-bearing step — forms, embeds, and third-party scripts need to be rebuilt as serverless components. This is a silent-failure trap: features look present but are non-functional until a human checks. **Tags**: #xref #addendum ## Permanent candidates - **A CMS is worth its overhead only when its editing workflow is used** — already exists as [[3. Resources/Permanent Notes/The CMS Decision Turns on How a Site Is Edited Not What It Contains]], created from this article. Not duplicated here. - **AI agents silently leave broken functionality as dead markup during migrations** — distinct from the CMS-fit claim (this one is about verifying AI-agent output, not tool selection). Promoted to a new Permanent note: [[3. Resources/Permanent Notes/An AI Migration Agent Leaves Broken Features as Markup That Looks Fine]]. ## Processing checklist - [x] All claim atoms have header + verbatim quote + where/why - [x] Triage callouts populated for every tagged highlight - [x] Checked existing Permanents first — found direct coverage for the primary claim, linked rather than duplicated; promoted one genuinely distinct secondary claim - [x] Connected into MOC — [[3. Resources/MOCs/Product & Startup Instincts MOC]] ## Links - [[3. Resources/MOCs/Product & Startup Instincts MOC]] — tool-fit heuristic: match the platform to the actual workflow, not the content category - [[3. Resources/Permanent Notes/The CMS Decision Turns on How a Site Is Edited Not What It Contains]] — because evidence-for; this article is that claim's origin source - [[3. Resources/Permanent Notes/An AI Migration Agent Leaves Broken Features as Markup That Looks Fine]] — because evidence-for; new Permanent note from this article's secondary claim - [[3. Resources/Readwise/Articles/Migrating From WordPress to Astro]] — source document