Migration to Sanity
Leave WordPress or Contentful without losing content or rankings.
Best for — Teams stuck on WordPress, Contentful, or a brittle custom CMS
Book a scope call →Move your content, assets, and URLs to Sanity without losing your editors' work or your search rankings.
I run migrations to Sanity as a fixed-price package: a content model audit, a scripted import, a 301 redirect for every legacy URL, and a Next.js front end built on the new content, or your existing front end re-pointed to Sanity.
Starts at $3,000, typically 4–8 weeks. Based in Surat, India (IST), with working-hour overlap for EU and US East Coast teams.
If your current CMS works and your editors are happy, you probably don't need to move. A migration pays off when the CMS itself is the bottleneck: every change needs a developer, the site is slow, or the bill keeps climbing for features you don't use.
WordPress content comes out through the REST API or a WXR export. The real work is everything around posts and pages: custom post types, ACF fields, taxonomies, shortcodes, and page-builder HTML. I map each post type to a typed Sanity schema, convert post HTML to Portable Text, decide case by case what happens to shortcodes and embeds, and carry over SEO titles and descriptions from your SEO plugin where they're available.
Webflow CMS collections can be exported as CSV or read through the Webflow API, and rich text fields arrive as HTML. Static pages built in the Designer have no structured content behind them, so those become Sanity page types with sections your editors can rearrange. Because Webflow also hosts your front end, a Webflow migration almost always includes a new Next.js front end.
Contentful is the closest to Sanity structurally: content types, entries, assets, and references map across cleanly. I export the space with the Contentful CLI, convert Rich Text JSON to Portable Text, move assets along with their metadata, and keep document IDs deterministic so references survive and the import can be re-run safely. Localised fields need a decision up front: field-level or document-level localisation in Sanity, depending on how your editors translate.
Every document, with the references between them kept intact: authors, categories, related posts, and nested page sections.
Images and files uploaded to Sanity's asset pipeline, with alt text where your old CMS had it, and links in your content rewritten to point at the new assets.
Translated content mapped to field-level or document-level localisation, chosen around how your team actually translates.
HTML or rich-text JSON converted to Portable Text, with custom blocks for images, embeds, and callouts, so content is structured data rather than a blob of markup.
A 301 redirect for every legacy URL, plus meta titles, descriptions, canonical URLs, and social images carried into Sanity fields.
A Sanity Studio (v6) set up around your team, with previews and validation, and a training session before you switch over.
Before quoting, I go through your current CMS: content types, volume, unused fields, broken references, and URL structure. Messy source data is where migration timelines usually slip.
Your old content types are mapped to typed Sanity schemas. This is usually a chance to fix the model rather than copy it: merging duplicated types, dropping dead fields, adding validation. You sign off before any import script is written.
Migration scripts run into a staging dataset, repeatedly, until the output is right. I spot-check documents against the source and fix edge cases in the script rather than by hand, so the final run is predictable.
Either a Next.js App Router front end built on the new content model, or your existing front end re-pointed to Sanity. A staging URL goes live early so you can review real migrated content in the real design.
The redirect map covers every legacy URL. Before launch I crawl the old site and the staging site, compare metadata and structured data, and make sure nothing important returns a 404.
A short content freeze, a final import, the DNS switch, and post-launch checks in Search Console. Your editors get a walkthrough of the new Studio, and 30 days of post-launch support is included.
Leave WordPress or Contentful without losing content or rankings.
Best for — Teams stuck on WordPress, Contentful, or a brittle custom CMS
Book a scope call →Included
Where a project lands within 4–8 weeks depends on content volume, the number of content types and locales, how clean the source data is, and whether the front end is rebuilt or re-pointed.
You get a written fixed-price proposal after a 30-minute scope call. Prices exclude Sanity and hosting plan fees, which you pay directly. See every package on the services page.
Longer write-ups on keeping traffic and content intact when you change CMS or rebuild the front end.
My migration package starts at $3,000. The final fixed price depends on how much content you have, how many content types and locales are involved, and whether the front end is rebuilt on Next.js or re-pointed to Sanity. I look at your current CMS before quoting, then send a written fixed-price proposal. Sanity's own plan fees are separate and paid directly to Sanity.
Typically 4–8 weeks. A blog-style site with a few content types sits at the short end. Several locales, lots of custom content types, or a full front-end rebuild push it toward the long end. The timeline is written into the proposal before any work starts.
Any migration carries some risk, but most ranking drops come from avoidable mistakes: missing redirects, dropped meta titles and descriptions, or URLs that changed without anyone tracking them. I map a 301 redirect for every legacy URL, carry SEO fields across, and check the staging site against the old one before launch. I can't promise rankings won't move, but I can remove the usual causes of a drop.
Often, yes. If your current CMS has an API or a structured export, the same process applies: audit, content model, scripted import, redirects. A custom database or a system that only gives you rendered HTML takes more transformation work, and I'll flag that before quoting.
Not always. If your front end is already a modern framework reading from an API, it can sometimes be re-pointed to Sanity. Coming from WordPress or Webflow, where the CMS also renders the site, you need a new front end, and I build it on the Next.js App Router.
Yes. They keep working in the old CMS until a short content freeze just before cutover, and the final import picks up everything published until then. After launch they get a training session on the new Sanity Studio.
Book a free 30-minute call. Tell me what you're on now and roughly how much content you have. I'll tell you honestly whether a migration makes sense and send a written fixed-price proposal within 48 hours.