Migration
What is the CMS migration checklist for a move to Sanity?
Short answer
A CMS (content management system) migration checklist for Sanity gives every item one owner and closes it only with proof: a count, a query result, a file or a crawl report. Imports skip Sanity Studio's validation rules (Sanity Docs, October 2026), so a tick without its proof proves nothing. Four owners sign: project owner, content lead, developer and search lead.
- Validation on import
- None: imports skip schema rulesSchema validation rules only run in Sanity Studio, so sanity documents validate --file checks the import file before it loadsSources: Sanity Docs (Import data, Documents CLI command reference)
- Growth document quota
- 25,000, or 50,000 with the add-onThe Increased quota add-on is $299 a month, as of October 2026, and Growth allows no document overageSources: Sanity (Plans that scale with you); Sanity Docs (Plans and payments)
- Rollback after an import
- By ID: an import never deletesDocuments in the target that aren't in the import file stay, so a rollback needs a pre-import export and the imported ID listSource: Sanity Docs (Development, staging, and production environments)
- Redirects after launch
- Generally at least 1 year, per GoogleGoogle advises redirecting each old URL to its final destination directly and keeping redirects as long as possibleSource: Google Search Central (Site Moves and Migrations)
Deploi’s call
Hold a migration to Sanity to a checklist where each item has one owner and one piece of proof. Launch when every blocking check carries its proof, and run the follow-ups from a dated list after launch instead of holding cutover for them.
MigrateGo live on Sanity when
- Every launch-blocking check has its proof on file, signed by its owner, so any failure traces to one person.
- Counts per type match the export minus the retire list, so nothing went missing silently.
- A pre-import export and the list of imported IDs are on file, because a Sanity import never deletes documents and a rollback removes them by ID.
StayHold the cutover to Sanity and stay on the old CMS (content management system) when
- sanity documents validate still reports errors, because Sanity doesn't check imported content against your validation rules.
- Any crawled URL with traffic or links has no destination or a chained redirect, because Google advises one hop to the final URL.
- No rollback window or old CMS license covers the days after launch, so a failed launch has nowhere to go back to.
What does the project owner decide before anyone writes a migration script to Sanity?
The project owner settles six items before any migration script to Sanity exists, and each closes with a written record, not a meeting. The content management system (CMS) to Sanity migration plan sets the steps; the project owner's list holds the proof behind each one.
| Item | Proof that closes it |
|---|---|
| Content to retire | A retire list signed by the content lead |
| Plan fit | Documents per type after remodeling, staging copy included, against the plan quota |
| Datasets | Which dataset holds staging; Free and Growth include 2 |
| Old CMS contract | Renewal date and notice period, in writing |
| Rollback window | The date the old CMS license runs to, after launch |
| Sign-off owners | One named person for each owner's list |
Plan fit is a hard gate, because Growth allows no document overage, as of October 2026 (Sanity Docs, Plans and payments, October 2026). What counts as a Sanity document settles the count, and the Contentful exit checklist covers that vendor's notice terms.
What does the content lead sign off before content moves to Sanity?
The content lead signs off five items before content moves to Sanity, and editors produce most of the proof. Sanity's planning lesson says training is "absolutely required for content creators" (Sanity Learn, Planning a re-platforming project, October 2026), so the editors' sign-off is a launch item, not a courtesy.
| Item | Proof that closes it |
|---|---|
| Inventory | Counts per content type, with a retire column |
| Content model | Editors' review notes, dated before the first import |
| Roles | Each old role mapped to a Sanity role, gaps listed |
| Training | Each editor has published a test document on staging |
| Preview | Editors approve sample pages of each type in preview |
Role mapping has a fixed ceiling below Enterprise: Growth has five fixed roles, and custom roles are Enterprise, as of October 2026 (Sanity Docs, Roles and permissions, October 2026). A content audit before the move builds the inventory, and what each Sanity role can do has the role matrix.
What does the developer sign off before a Sanity import counts as done?
The developer signs off a Sanity import only when each item has a saved output, because a Sanity import doesn't check content against your schema: validation rules run only in Sanity Studio (Sanity Docs, Import data, October 2026).
| Item | Proof that closes it |
|---|---|
| Schema | A deploy record dated before the first content import |
| Stable IDs | A second run with --replace leaves counts per type unchanged |
| Validation | sanity documents validate --file output with no errors |
| Webhooks and Functions | Webhooks disabled; each Function scoped away or removed |
| Counts | Documents per type equal the export minus the retire list |
| References | A query finds no unresolved placeholder references |
| Array keys | Every array item carries a stable key |
| Assets | No skipped files, or a signed list of the ones skipped |
| Rollback files | A pre-import export and the imported ID list |
A deployed Function has "no on/off switch", unlike a webhook (Sanity Docs, Functions cheat sheet, October 2026). Safe imports into Sanity explains each flag and failure mode.
What does the search lead sign off before cutover to Sanity?
The search lead signs off six search engine optimization (SEO) items before cutover to Sanity, each closed by a crawl report or a Search Console record. Sanity's re-modeling lesson says to crawl "your existing website to record all pages that currently exist" (Sanity Learn, October 2026), so the URL list starts from a crawl, not the export.
| Item | Proof that closes it |
|---|---|
| URL map | Every crawled URL has one destination, or a 404 or 410 |
| Redirects | Each old URL answers with one server-side permanent redirect |
| Canonicals | Each new URL's canonical names itself |
| Sitemaps | New URLs only, with lastmod from real modified dates |
| Indexing blocks | No development noindex or robots.txt block left |
| Search Console | The verification method carried into the new build |
Google lists leftover noindex and robots.txt blocks first among its common site-move mistakes (Google Search Central, Site Moves and Migrations, October 2026), and uses lastmod only when it's "consistently and verifiably" accurate (Google Search Central, Build and Submit a Sitemap, October 2026). Keeping SEO through the move explains each item.
Which migration checks block a launch on Sanity, and which can wait?
A migration check blocks the launch on Sanity when failing it loses content, traffic or the way back; every other check goes on a dated follow-up list with an owner. The sort is Deploi's judgment, built on Sanity's and Google's guidance.
| Check | Blocks launch | Why |
|---|---|---|
| Validation errors | Yes | Broken content goes live |
| Counts per type | Yes | A gap means content went missing silently |
| Export and ID list | Yes | An import never deletes, so rollback needs the IDs |
| URL with traffic or links, unmapped | Yes | Its visitors and links land on a 404 |
| Chained redirect | Yes | Google advises one hop; chains ideally no more than 3 |
| Noindex or robots.txt block | Yes | The new site can't be indexed |
| URL with no traffic or links, unmapped | No | A 404 or 410 is a valid answer |
| External links to old URLs | No | Redirects carry them for at least a year |
Google says to keep redirects "generally at least 1 year" (Google Search Central, October 2026), so link updates can follow launch. Sanity's Webflow course warns that some URL patterns "will surface gaps in your redirect map" (Sanity Learn, October 2026).
In what order do the owners sign off a migration to Sanity?
The owners sign off a migration to Sanity in dependency order, with the project owner first and last, and the record keeps each proof beside its signature. Deploi's own Sanity releases keep the same kind of record: wave 1 of deploi.ca's Shopify data section went in as one package of 406 documents and 159 images, with an import, check queries, an ID list for rollback and a sign-off record, in October 2026.
Signing off a migration to Sanity
- Scope. The project owner signs the retire list, plan fit, datasets, contract dates and rollback window.
- Model. The content lead signs editors' review notes, the role map and the training record.
- Staging import. The developer signs validation output, counts per type, the reference query and the rollback files.
- URL crawl. The search lead signs the crawl of every old URL against staging.
- Go-live. The project owner confirms every blocking check carries its proof and gives each follow-up an owner and a date; cutover and rollback runs the switch.
- Rerun. Any new import run voids the developer and search lead signatures until their checks pass again.
Deploi’s point of view
- Where we disagree
- The standard migration checklist is a task list: export, import, set up redirects, launch. Ticked from memory, it proves only that someone believes the work is done. It also treats every item as equal, so teams either delay launch for fixes that could follow it or launch with an unmapped high-traffic URL. Each item needs the evidence that closes it and a flag for whether it blocks.
- What we’ve seen
- The habit comes from releasing deploi.ca's own Sanity content. Wave 1 of deploi.ca's Shopify data section went in as one package of 406 documents and 159 images in October 2026, with the schema deployed before content, check queries, a list of IDs for rollback and a sign-off record. The September 2026 release that moved 256 live FAQ answers to shorter URLs had a runbook that planned expected counts and 59 integration checks, and its checks record 261 pages compared identical with the new template switched off.
- What this adds
- The root plans a migration to Sanity in eight steps with an owner per step. This page turns those steps into sign-off items, names the proof that closes each one, and sorts the checks into launch-blocking and follow-up with a reason for each.
- What we refuse to promise
- We won't promise that a migration to Sanity loses no traffic. A checklist proves the URLs, redirects and metadata are right; Google decides when the new URLs show, and says a medium-sized site can take a few weeks or more.
When this answer changes
- Sanity adds schema validation or a dry run to sanity datasets import
- Sanity gives deployed Functions an on/off switch
- Sanity changes the Growth document quota, the $299 Increased quota add-on or the datasets Growth includes
- Sanity changes the fixed roles on Free or Growth
- Google revises its site move guidance on redirects, canonicals or common mistakes
Sources
Every source opened and checked on 25 October 2026.
- Sanity Learn, Planning a re-platforming project
- Sanity Docs, Import data
- Sanity Docs, Documents CLI command reference
- Sanity, Plans that scale with you
- Sanity Docs, Plans and payments
- Sanity Docs, Development, staging, and production environments
- Sanity Docs, Roles and permissions
- Sanity Docs, Functions cheat sheet
- Sanity Learn, Import content with the two-pass pattern
- Sanity Learn, Validate your import without a frontend
- Google Search Central, Site Moves and Migrations
- Google Search Central, Build and Submit a Sitemap
- Sanity Learn, Launch checklist and DNS transfer
- Sanity Docs, Important considerations for schema and content migrations
- Sanity Learn, Deterministic and consistent IDs
- Sanity Learn, Re-modelling your existing content