WordPress to Sanity Migration
Move off WordPress onto a typed content model, a Next.js frontend and an editing experience your team actually wants to use — without losing a URL or a ranking.
Why teams leave WordPress for Sanity
Almost never because of one vulnerability. Usually because the content model has become a pile of custom fields nobody can explain, the site is slow in ways plugins cannot fix, and every change needs a developer.
Sanity replaces that with a content model defined in code and an editing Studio shaped around it. The trade-offs are set out in full on the WordPress migration comparison.
How the migration runs
- Content audit and model design — what you have, what earns its place, and the shape it should take.
- Extraction from WXR or the WordPress REST API, converted to Portable Text with formatting and internal links preserved.
- Media migration into the asset pipeline, with alt text carried across.
- URL preservation and a redirect map, verified against your top pages by traffic before launch.
- Frontend rebuild in Next.js, measured against the old site on Core Web Vitals.
- Editor training and handover, with the content model documented.
WordPress and Sanity, side by side
| Criterion | WordPress (today) | Sanity + Next.js |
|---|---|---|
| Content model | Posts/pages + ACF bolt-ons | Typed schemas, defined in code |
| Editor experience | Familiar, plugin-dependent | Studio, real-time, customisable |
| Frontend freedom | Themes; headless possible | Any framework; Next.js default |
| Public attack surface | PHP origin + plugin surface | Static/ISR at the edge; no public DB |
| Who patches, how fast | You — core, plugins and themes | Vendor-run content layer |
| Supply chain | ~60k plugins, uneven quality | Few, mostly first-party |
| EN/AR and RTL | WPML or Polylang add-on | Field-level i18n built in |
| Custom business logic | Hooks; fights the grain | App layer beside the CMS |
| Hosting and ops | Cheap shared through to managed | Vercel + hosted content lake |
| Licence and cost shape | GPL core; plugin licences | Open Studio; usage-based SaaS |
| Team skills | PHP/WordPress, widely available | TypeScript/React |
When this is the wrong choice
If the core of your site is transactional business logic rather than content, an application framework fits better — see WordPress to Laravel Filament. If you run a .NET estate, WordPress to Umbraco will sit more comfortably with your IT governance.
We migrate content-led WordPress sites to Sanity and Next.js: audit what you have, model it properly, move it with its history and media intact, rebuild the frontend, and hand over an editor your team is trained on. URL structure and redirects come first, not last.
What we do
Content audit and model design
We model what the content means, not how the old theme displayed it.
Extraction to Portable Text
WXR or REST export converted with formatting, embeds and internal links intact.
Media and asset migration
Images and files moved into the asset pipeline, alt text preserved.
URL preservation and redirects
A verified redirect map so rankings survive the cutover.
Next.js frontend rebuild
Rendered at the edge, measured against the site it replaces.
Editor training and handover
Your team leaves able to change the site without us.
How it runs
The same transparent shape every engagement follows — you always know where you are and what it costs.
Discover
A short, fixed-price sprint: audit, stakeholder interviews and the questions that decide the shape of the work.
Define
Scope, architecture and a fixed estimate — you know what's being built, why, and what it costs before we start.
Deliver
Tight design-build loops with weekly preview releases. You watch it become real on a URL, not in a deck.
Grow
Launch is the midpoint. Measurement, iteration and support keep the work earning after day one.
Fair questions
How long does a migration take?
For a 50–200 page marketing site, four to ten weeks. Template count, integrations and how clean the existing content is move that more than page count does.
Will we keep our URLs and rankings?
Yes — that is a first-phase deliverable, not an afterthought. Existing URLs are preserved where possible and redirected where not, verified against your highest-traffic pages before launch.
What happens to our plugins?
Each one gets a decision: replaced by a platform feature, rebuilt as code, swapped for a service, or dropped. Most WordPress installs are carrying plugins nobody would choose again.
Can we run both during the cutover?
Yes. We migrate in sections behind the same domain, so the new stack serves some paths while WordPress serves the rest until you are ready to switch fully.