Two sites came off WordPress in the same month.They needed opposite answers.
One is an archive: 376 recipe posts and 499 images that nobody will ever edit again. The other is a working sailing club site with volunteers posting to it. The platform decision was the same both times. Almost nothing else about the two builds was.
August 2026 · one live on Netlify, one on staging behind noindex while the client decides when to cut over
The question is never WordPress. It is whether the site needs a database.
A WordPress site is a running cost before it is a website. There is hosting to pay for every month, a PHP version that goes end of life on somebody else's schedule, a plugin list that has to be patched forever, and a login page that is attacked continuously by people who have never heard of the site and do not care what is on it.
Static hosting removes all four by construction. There is no database to breach, no admin to brute force, no plugin to patch, and Netlify serves the files for nothing at this size. What it removes along with them is the thing WordPress was bought for: somebody who is not a developer being able to change the site.
So the real question is who still needs to edit it, and how often. Answer that honestly and the two builds fall out in opposite directions.
A recipe archive
Written over years by one author, finished. Nobody is going to add a post. The content is worth keeping and reading, and every hour spent maintaining an editing system for it is wasted.
Answer: no CMS, no database, no accounts. Markdown files in a repository, a static site generator, and search that runs in the reader's browser.
A sailing club
Four volunteers who each do one job a few times a year: the bar times, the news, the noticeboard, the sailing programme. Take the editing away and the site is dead within a season.
Answer: keep the editing, drop the platform. A git-backed CMS that writes markdown, so every change made by a volunteer is a commit with an author and a diff.
Everything WordPress was doing, minus the WordPress.
doubleyummy.uk is a baby weaning recipe blog by a registered dietitian. The content was the asset and the platform was the bill. A scraper walked the site's own WordPress REST API, converted every post to markdown, downloaded every image and resized it, and the result builds with Eleventy into plain files.
Search was the only feature that looked like it needed a server, and it did not. Pagefind builds a search index at the same time as the site and runs it in the reader's browser, so the whole thing is still a folder of files being served.
A migration is easy to declare finished and hard to prove finished. The check that matters is not "the site builds", it is "every URL that used to work still works", and that is a script, not a feeling.
The other one still has to work on Monday.
The second site belongs to a sailing club and is still running on WordPress today. The rebuild started with an audit rather than a rewrite, because "we should move off WordPress" is an opinion until somebody lists what is actually wrong. The audit found eight security, seven performance and eight usability problems, and most of them were properties of the platform rather than bugs anybody had introduced.
The rebuild is Astro, with the content as markdown validated by schemas, and a git-backed CMS at its own address so a volunteer signs in and sees the two collections they actually edit. That is not a permission boundary and the repository says so in as many words: anyone who can sign in can edit anything. What protects the site is that every change is a commit with an author and a diff, and a bad one is one revert away, which is a stronger position than the site was in before.
Route pairs mapping each old WordPress URL to its replacement, so links that people have bookmarked and search engines have indexed survive the cutover.
Pages archived from the live site as HTML and screenshots before anything was rebuilt, as the baseline the new pages are compared against.
Checks gating the build, including links, redirects, image sizes, events, and whether the CMS configuration still agrees with the content schemas.
Cutover so far. The new build is on staging behind noindex and the live site is untouched. When a club changes its website is the club's decision, not the developer's.
The check that keeps this honest is the parity harness. The old pages were captured first, and the new ones are compared against that capture rather than against what anybody remembers the site looking like. A migration that quietly loses a page is the normal failure, and it is only normal because nobody was looking for it.
Faster, cheaper, and nothing to patch.
Whatever the answer on editing, the platform change buys the same four things. The hosting bill goes away, because static files at this size are free on Netlify. The pages get faster, because they are already built when the request arrives. The plugin patch treadmill stops, because there are no plugins. And there is no login page, so the continuous background attempt to log in to it stops mattering.
One more thing comes with it that nobody asks for and everybody wants the first time they need it: a deploy is a commit, so a rollback is one click, and a build that fails leaves the last good version serving rather than taking the site down.
Most content sites are paying for a database they stopped using.
The shape repeats: a site on a platform it has outgrown, a monthly bill for a server that serves the same bytes to everybody, and an editing workflow that either three people use every week or nobody has touched since 2019. Which of those two it is decides the whole build, and it is worth an hour to find out before anyone writes any code.
The work is not the conversion, which is mostly a script. It is the redirect map, the verification that every old URL still answers, and being straight about who is going to edit the thing afterwards.