For the past few weeks we kept a spreadsheet of every public request we could find from people trying to leave WordPress: freelance job posts, Reddit and Hacker News threads, GitHub issues, agency RFPs. 96 requests in total, most of them real budgets and real deadlines.
We read every one and tagged what people were actually worried about. The result surprised us less than it should have:
- One in three (33%) named keeping their URLs, SEO or redirects as a hard requirement — or as the thing they were most afraid of losing.
- 30% were built on a page builder (Elementor alone: 19%).
- 21% said non-developers must still be able to edit the site after the move.
- 19% mentioned a hack, malware or a plugin vulnerability. In unprompted social posts it was 44%.
The numbers come from a small, keyword-sourced sample that leans towards Astro. Read them as "requests we tracked", not as market share.
This post is about what those people are running into, why most WordPress migrations go wrong in the same three places, and how we built Contentrain Migrate around them.
The three places migrations break
1. URLs and SEO — the silent loss
The most common story in our sheet isn't "the new site looked bad". It is "we moved a few sites off WordPress and took a six-week SEO hit".
The reasons are boring and devastating: date-based permalinks that change shape on import, redirects that lived inside a plugin nobody exported, canonical tags and schema that a Markdown exporter never saw, /?p=12 links that still circulate in old newsletters. One public importer issue we tracked calls dropped permalinks simply "a migration blocker". Agencies told us they build redirect maps by hand from the sitemap, a crawl and Search Console — for every site.
2. Page builders — moving the mess instead of the content
Builders are where WordPress content stops being content. A heading is a widget, a section is a JSON blob, a layout is three nested containers with inline styles. People reported Elementor updates that broke almost every page, and migrations that failed because the builder "mess" was copied across instead of remodelled.
Exporting builder output to HTML gives you a static snapshot. It doesn't give you a model of the page — and without a model, nobody can edit it later.
3. The day after — who edits the site now?
This one is the quiet deal-breaker. One in five requests said a non-developer must keep editing. One team in our sample went back from headless WordPress + Astro to plain WordPress because the marketing team couldn't edit every section anymore. A static export that only a developer can change is not an exit; it is a different lock-in.
And then there are the security posts — a site hacked twice with hundreds of injected spam posts, a form plugin that let malware in, a cyber insurer telling health-sector clients to leave WordPress "ASAP". People want out. They just don't want to lose what they built.
What we built: AI understands, the engine executes
Migrate takes a live WordPress site and delivers a real Astro project in a Git repository you own. The design principle that shaped everything is one sentence:
The AI understands the site. A deterministic engine moves the content. Gates prove it.
Discovery, before you pay
Discovery crawls the site and counts what is actually there: template families, posts, pages, media, languages, live features like forms and search. That count is the price — a one-time price computed from your site, starting at $50. No account needed to see it.
The AI step is narrow on purpose
Claude looks at each template (not every page) and answers one question: what is this page made of? It names the bands — hero, feature grid, testimonial slider, FAQ — and their slots. Every answer is grounded against the captured page and validated.
What the model never does is write your content. In the delivered project, the AI can only touch views, site components and styles. The content itself — every post, page, menu, redirect and SEO field — is moved by a deterministic engine into typed content models under .contentrain/.
That split is the whole point. A model is good at recognising that a block of three cards with icons is a feature grid. It is not something you want deciding whether paragraph four of a 2019 blog post survived.
Gates: the fear becomes a test
After the build, 25 gates check the result — against the source where that makes sense, and against the project itself. Twelve of them are hard: if one fails, the site doesn't ship until a person has looked at it. Some of the hard ones:
| Hard gate | What it checks |
|---|---|
| Text | Every page's text matches the source |
| Status | Every public URL still exists |
| Redirects | Every redirect still redirects — same target, same permanence |
| SEO | Title, description, canonical and robots are kept per page |
| Language / hreflang | Locales and their alternates survive |
| Listings | Archives and category pages still list the same items |
| Editability | Change content → rebuild → the output changes |
Redirects ship as a _redirects file for Netlify or Cloudflare, including old WordPress query addresses. Sitemaps, robots.txt, RSS and JSON-LD come with the project.
Interactions are measured too: on a sample of pages, a browser clicks menus, tabs, accordions, sliders and forms at phone and desktop widths and flags any control that does nothing. The WordPress runtime scripts don't come along — the components that need behaviour ship their own small, bundled code.
The design is modernised, not pixel-copied. Visual similarity is measured and reported to you; it is not promised.
What about the plugins only WordPress can see?
Public WordPress endpoints don't expose plugin redirects, SEO-plugin fields or URL rules. For those we have Contentrain Bridge, a free GPL plugin that exports them, checked file-by-file with hashes. Without Bridge, an application password covers the rest — but plugin redirects and SEO-plugin data move only with Bridge, and we say so up front.
When a check needs a human
If a check doesn't pass, you don't get an error page. The job goes to us, we finish it, and we email you when it's ready.
After the move: two ways to keep editing
This is where the third pain gets solved, and where Migrate stops being a one-off tool.
Every delivered project is a Contentrain project: content lives as typed models in Git, and the site reads it through a generated, typed client. You can edit it two ways — and both end up as commits in the same repository.
Contentrain Studio — an AI- and Git-native CMS. Your marketing team gets a web editor with roles, review and publishing rules. Writers draft, owners and admins publish, and every change is a Git commit on your repo. It also exposes a remote MCP endpoint, so the same team can ask Claude to "add a German version of this author" or "publish the three draft posts" — with the same role rules as the UI.
A local MCP agent — if you are a developer, open the repo in Claude Code or Cursor. The project ships an MCP config and agent instructions, so your agent starts the Contentrain MCP server on its own and edits content through validated tools instead of hand-editing JSON.
Either way, the site you got is not a frozen export. It is a content system you and your agents can keep working on.
Where Contentrain fits
Contentrain is not one product. It is an ecosystem for the content flows around a site, built to be AI-native and Git-native:
- Migrate — get off WordPress with your URLs, SEO and content intact.
- Studio — the CMS for teams: web editing, roles, review, publishing, media.
- MCP + CLI — local, open tools that let any AI agent read and write governed content.
- SDKs and starters — typed content in Astro and beyond.
You can start with any piece. Most people we talk to start with the exit.
The honest limits
- Shops stay put. If a WooCommerce shop is the business, we don't make an offer. Membership systems stay on WordPress too.
- Comments, forms and search each get an explicit choice: Studio, an adapter, or keep the WordPress endpoint.
-
Very large or locked sites — beyond our size limits, or blocked by
robots.txt— get a quote from a person, not an automatic price. - Design is modernised. If you need a pixel-perfect clone, this isn't it.
Wrapping up
The people in our spreadsheet weren't asking for a new framework. They were asking for three things: don't lose my URLs, don't keep the builder mess, and let my team edit tomorrow. We tried to turn each of those into something you can check rather than something you have to trust.
If you're sitting on a WordPress site you've been meaning to leave, run a discovery on it — it is free, needs no account, and tells you what moves, what stays and what it costs: migrate.contentrain.io.
We'd love to hear what's kept you on WordPress. The comments are open.
Top comments (0)