Sanity migration specialist
Sanity CMS migrations, done right.
Content migrations, schema restructuring, and platform transitions — handled by a specialist who works in the Sanity ecosystem every day.
Why a specialist
Migrations have more moving parts than they appear.
- Data Integrity
- Migrations risk corrupting or losing content. Every document, reference, and asset is validated before, during, and after the move.
- Zero Downtime
- Your content operations don't stop for a migration. Careful planning and staged execution keep your team productive throughout.
- Schema Confidence
- Schema changes compound in complexity. A clear migration plan prevents drift, preserves editorial workflows, and avoids breaking your front end.
Services
Three migration practices.
Content Migration
Move content between Sanity projects or from another CMS into Sanity. Document types, references, images, and files — all mapped, transformed, and validated.
- Cross-project data transfer
- CMS-to-Sanity imports
- Asset migration and rewriting
- Reference integrity checks
Schema Migration
Restructure and evolve your Sanity schemas without losing data. Rename fields, reshape documents, split or merge types — with scripts that are repeatable and auditable.
- Field renaming and reshaping
- Document type splitting/merging
- Portable Text transforms
- Repeatable migration scripts
Platform Migration
Moving to Sanity from another CMS, or consolidating multiple Sanity projects. Full-stack migration planning from content modeling through front-end integration.
- Legacy CMS to Sanity
- Multi-project consolidation
- Content model redesign
- Front-end integration support
Process
From discovery to handoff.
- 01
Discovery
We start with a call to understand your current setup, content model, and goals. No commitment — just clarity on what the migration involves.
- 02
Migration Audit
I review your schemas, data, and integration points to produce a detailed migration plan — including scope, risks, and timeline.
- 03
Execution
The migration runs in stages with validation at each step. Scripts are repeatable, so nothing is a one-shot operation.
- 04
Verification & Handoff
Content is verified against the source, your team reviews the results, and I hand off documentation so you own the process going forward.
The work itself
Scripted, repeatable, and auditable.
Every migration runs through versioned scripts — not one-shot operations. Each change is reviewable, re-runnable against staging, and safe to roll back.
import { client } from "./sanity.client";
// Move legacy `authorName` into a structured `author` object
const posts = await client.fetch(
`*[_type == "post" && defined(authorName)]`
);
const tx = client.transaction();
for (const post of posts) {
tx.patch(post._id, (p) =>
p.set({ author: { name: post.authorName } })
.unset(["authorName"])
);
}
await tx.commit({ visibility: "async" });FAQ
Frequently asked questions.
How long does a typical Sanity migration take?
Most content migrations take two to six weeks end-to-end. Simple imports from a single CMS can finish in a week; schema-heavy migrations with custom Portable Text transforms and reference rewriting take longer. The timeline depends on document count, the complexity of your source data, and how much content modeling work needs to happen before any scripts run.
Can you migrate from WordPress, Contentful, or Drupal to Sanity?
Yes. WordPress, Contentful, Drupal, and Strapi are the most common source systems I work with. The general pattern is the same: pull structured data out of the source, design a Sanity schema that fits your editorial workflow (not a 1:1 copy), convert HTML or rich text to Portable Text, and validate the result with GROQ queries before pointing your frontend at the new dataset.
What happens to images and other assets during a migration?
Assets are uploaded into Sanity's asset pipeline first, then a lookup table maps old URLs to new asset IDs. That mapping is used when transforming documents so every image, file, and reference points to the correct asset. The original media URLs stay intact for rollback until the migration is verified.
Will my live site go down during the migration?
No. Migrations run against a separate Sanity dataset (typically named 'migration' or 'staging') so your live content stays untouched. The cutover happens by switching your frontend to the new dataset only after the migration is validated, usually behind a feature flag or preview deploy.
Do you write the migration scripts, or just advise?
Both, depending on the engagement. Most clients want me to write and run the migration scripts end-to-end, then hand over the scripts and documentation so they can re-run them. Some teams have engineering capacity and just need a content model review or code review of their migration approach — that works too.
How do you handle schema changes after launch?
Sanity migrations don't stop at launch. Ongoing schema changes — renaming fields, splitting documents, restructuring references — are handled with the Sanity Migration Toolkit (@sanity/migrate). Migrations get checked into the repo so they're repeatable across dev, staging, and production datasets.
Get in touch
Ready to plan your migration?
Start with a free discovery call to scope your project. No obligation, no sales pitch — just an honest assessment of what it'll take.