"But My Client Needs to Edit It." What I Actually Hand Them After 3 Astro Migrations.

Every single time I propose moving a client off WordPress, the same sentence arrives within two emails.

"But we need to be able to edit it ourselves."

Fair question. Actually it is not even a question, it is the whole decision. I have done three WordPress to Astro migrations for clients now, and the technical side was the easy part. Redirects, templates, forms, build pipeline: all solvable in a week. What I got wrong the first time was assuming the CMS choice was a detail I could sort out at the end. It is not a detail. It is the thing that determines whether your client is happy in month six or quietly asking another agency to put them back on WordPress.

Most "just use Astro" posts wave this away with a link to the docs page listing forty integrations. That is not an answer. Picking an Astro CMS for clients is the hardest call in the whole project, so here is what I actually hand people, what it costs in 2026, and where each one falls apart.

The Real Problem Is Not the CMS, It Is the Build Step

Here is the thing nobody warns clients about. In WordPress, editing is one action. You change a word, you hit Update, you refresh the tab, the word is different. The whole mental model is "the website is a thing I am typing into."

A static Astro site is not that. Your client hits Save, the CMS commits or writes to an API, a webhook fires, a build kicks off somewhere they cannot see, and 40 to 90 seconds later the change appears. Nothing on their screen tells them any of this is happening. So they refresh. Nothing. They refresh again. Nothing. Then they email me: "I think the site is broken."

It is not broken. It is building. But "building" is not a concept a physiotherapist or a wedding venue owner has any reason to hold in their head, and telling them to be patient is a terrible answer. The fix is boring and it works: put a visible deploy status somewhere in the editing interface, and tell them the number out loud during handover. "You will see it in about a minute." One sentence during training removes most of the support tickets.

The second thing they lose is preview. In WordPress they see the page, roughly, while they write. Most headless setups give you a text field and a promise. Storyblok and Sanity have solved this properly with real visual editing. The git-based tools mostly have not, and that gap matters more to a non-technical editor than any feature comparison table will tell you.

Third, and this is the one I underestimated: drag and drop layout is gone. If your client spent four years building pages in Elementor, they do not think of themselves as writing content. They think of themselves as designing pages. Handing them a structured content editor is not a downgrade in their eyes, it is a removal of the only creative control they had. Sometimes that is exactly what you want. Sometimes it ends the relationship. Decide which one you are dealing with before you scope the project, not after.

Every Astro CMS for Clients, and What It Costs in 2026

I checked all of this in September 2026, because CMS pricing moves and half the comparison posts you will find are quoting 2023 numbers.

Directus is what I build on, so take this with the appropriate pinch of salt. Self-hosting is free for any organisation under $5 million in total annual income, which covers essentially every client I have ever had. The editing interface looks like a database admin panel because it basically is one, and that cuts both ways: clients who came from Excel get it immediately, clients who came from Elementor stare at it. The catch is that self-hosted means you own the server, the backups, the upgrades. That is a real ongoing cost, just not one that shows up on an invoice from a vendor. Directus also retired its cheap Starter cloud tier in December 2025 and moved to a new Monospace Sustainable Core License with v12 in April 2026, so if you were planning to lean on their hosted tier for a small site, that door has closed. Cloud now starts around $99 a month.

Sanity has the best free tier in this list by a distance: 20 seats, live preview, and a genuinely good editing experience. Growth is $15 per editing seat per month, viewers are free. Sanity's visual editing is the closest thing to "the client sees what they are changing" that exists in this category. The cost is that Studio is a React app you configure in code, so every schema change is a developer task. That is fine for me. It is a dependency your client should understand.

Storyblok is the one I recommend when the client's whole objection is visual. Their visual editor lets an editor click a block on a rendered preview of the actual page and edit it there. That is the WordPress feeling, delivered properly. The free plan is one user and one space, which is enough to demo and not enough to run a business. Growth is 99 euros a month for 5 seats, additional seats 15 euros. Growth Plus is $349 a month. For a five-page local business site that is absurd. For a client with three people publishing weekly, it is cheaper than the argument you will otherwise have every month.

Payload is excellent and is not really a CMS decision, it is an architecture decision. Payload 3 ships as a Next.js plugin, so the admin and the front end live in one codebase. If you are on Astro, you are running Payload as a separate app anyway. It is free and MIT licensed, self-hosted infrastructure realistically lands between $25 and $60 a month once you count a Postgres instance and file storage. Payload joined Figma in 2026, which I have no strong opinion about yet, other than noting that "acquired" is information you should factor into a five-year client recommendation.

Decap CMS deserves a correction. The internet has decided Decap is abandoned, and I half believed it too. It is not. The repo shipped 3.14.0 in June 2026, 3.15.0 in July, and 3.16.0 on August 31, 2026. That is a real cadence. It is still the descendant of Netlify CMS with the technical debt that implies, and Sveltia CMS is the faster modern rewrite people migrate to, but "Decap is dead" is a 2024 opinion that people are still repeating in 2026. Check the releases page yourself before you take anyone's word for it, mine included.

Keystatic is free, MIT, from Thinkmill, and is the cleanest git-based option for a developer. TinaCMS is the git-based one with actual visual editing, free for 2 users, with TinaCloud plans starting at $24 a month and editorial workflow at $49. Both are lovely. Both still put a build step between Save and live.

EmDash, Cloudflare's open-source WordPress successor, is built on Astro, which makes it the most interesting entry here. I reviewed it properly in I Tried Cloudflare's EmDash CMS So You Don't Have To. Short version: the sandboxed plugin model is genuinely the right idea, and it was a v0.1.0 preview in April 2026 with a marketplace that basically nobody has published to. I am watching it. I am not putting a client's revenue on it this year.

The Options Nobody Wants to Admit Are Correct

Two of my three migrated clients edit their sites less than once a month. One of them has updated content twice in fourteen months. Both times it was a phone number.

For that client, every option above is wrong. Standing up a CMS, training them on it, maintaining it, and paying for it, so they can change a phone number twice a year, is me solving my own discomfort rather than their problem. What actually works:

"Email me the change." Include a small monthly retainer that covers content edits, say 30 minutes. The client gets a human who does it correctly, you get a recurring relationship, and nobody maintains a CMS nobody opens. This is the right answer more often than the web development industry is willing to say out loud.

A markdown file in the repo, edited through GitHub's web editor. Free, versioned, and if the client is technical enough to use Google Docs comments they can usually manage it after one screen share. Fragile if they are not.

A Google Doc or a Sheet as the source, pulled at build time. Genuinely great for a site where the changeable content is a menu, a price list, opening hours, or a team roster. Your client already knows how to use it, which is the entire point, and you skip the training session completely.

There is no rule that says an Astro CMS for clients has to be software. The threshold I use: under one content change a month, do not build a CMS. One to four a month, git-based or Google Sheets. Weekly or more, or more than one person publishing, buy a real CMS with preview.

What I Would Recommend, by Client

No shrugging. Here is the actual call.

Five-page local business, edits twice a year. No CMS. Retainer plus email, or a Google Sheet for the handful of fields that change. Free, and they will thank you.

Small business with a blog they update monthly. Keystatic or Decap, git-based, free, hosted alongside the site. Set expectations about the build delay during handover.

Content-led site, one or two editors, publishing weekly. Sanity. The free tier covers 20 seats, the preview experience is good, and $15 a seat if you outgrow it is not a hard conversation.

Marketing team who came from a page builder and will not let go of visual editing. Storyblok, and price the 99 euros a month into the proposal from day one rather than surprising them in month two.

Client with structured data, multiple content types, and things that are not really pages. Directus, self-hosted. This is why I use it. It stops being a CMS and starts being their backend, and once you cross that line the rest of the comparison stops being relevant.

Client who cannot let go of Update-and-it-is-live. Keep them on WordPress. Genuinely. I wrote more about how I make that call in WordPress, Next.js, or Astro? Here's How I Actually Decide for Client Projects, and my broader take on whether WordPress is still the right call in Should I Still Use WordPress in 2026?. A migration that makes your client's daily work worse is a failed migration no matter what the Lighthouse score says. If speed is the argument you are making, the honest version of those numbers is in Astro vs WordPress: The Performance Numbers.

What I Still Get Wrong

I do not have this fully solved. The part that still bothers me is that the person picking the CMS, me, is never the person who has to live in it. I optimise for how it feels to wire up in an afternoon. They live with it for three years.

So the last two migrations, I did something obvious that I should have done from the start: before committing to a stack, I sat with the client and had them make one real content change while I watched and said nothing. Not a demo. Their hands, my silence. It is uncomfortable for about ninety seconds and it tells you more than any comparison table.

Choosing an Astro CMS for clients is not a technical decision with a technical answer. It is a guess about how a specific person will behave when you are not in the room. Everything else, the forms, the redirects, the contact form on a static Astro site, is straightforward by comparison.

If you are staring down a WordPress migration and the "but they need to edit it" question is the thing blocking you, that is the right thing to be stuck on. It is the only part that is genuinely hard. Come tell me about the client and I will tell you which of these I would actually pick.