How do you cut over from the old CMS to Sanity with a parallel run and a rollback plan?

Should you cut over to Sanity in one switch or run both CMSs in parallel?

Site size decides how you cut over to Sanity: move a small or medium site in one switch, and a large site one section at a time while the old content management system (CMS) serves the rest. Google's site move guidance splits the same way (Google Search Central, Site Moves and Migrations, October 2026):

• Small or medium site. Google recommends moving all URLs at once, because that "helps our algorithms detect the site move and update our index faster".
• Large site. Google lets you move one section at a time, which "can make it easier to monitor, detect, and fix problems faster".

Sanity's re-platforming course backs the section route for a first move: "identify low-risk content and perform an incremental migration" (Sanity Learn, remodeling lesson, October 2026). A parallel run means two systems to keep current, so in Deploi's judgment it earns its cost only when the site is large or its sections run on different templates. Whether to start at all belongs to planning a CMS migration to Sanity; cutover planning starts once that call is made.

How do the old CMS and Sanity serve one site during a parallel run?

During a parallel run, one front end owns the domain: it serves migrated sections from Sanity and passes every other path through to the old content management system (CMS). Next.js does this with fallback rewrites, which proxy to an existing website "after checking all Next.js routes", so you don't change the rewrite rules as more pages move. A dynamic route, including a getStaticPaths page with fallback set to true or "blocking", takes priority over a fallback rewrite, so it shadows matching old CMS paths (Next.js Docs, rewrites, October 2026). The domain switches once, to the new front end; each later section switches when its routes ship, with no DNS (Domain Name System) change. How Sanity and Next.js work together covers that front end.

Two rules keep a parallel run clean (Deploi's judgment):

• One owner per URL. Each path is served by Sanity or by the old CMS, never both, so editors know where every page lives.
• Freeze per section. Editors stop editing a section on the old CMS when its final import runs, not the whole site.

Deploi has used a related pattern inside one front end, not between two CMSs: in September 2026 deploi.ca's FAQ moved to a new page template behind a launch switch environment variable, and with the switch off 261 pages compared identical. Safe release scripts shows that mechanism.

How do you keep the content freeze short at cutover?

Keep the content freeze to the final export and import: editors keep publishing on the old content management system (CMS) until that last export, and a rerunnable script carries their latest work across. Sanity's course says the script "should be able to run against the most up-to-date version of your current platform's content", and predetermined document IDs make each run update the same documents instead of creating new ones (Sanity Learn, Migrating without downtime, October 2026).

Three cutover checks keep the final run short and complete (Deploi's judgment):

• Time a full rehearsal. Run the complete export and import once into a staging dataset and time it, so the freeze is planned around one measured run, not a guess.
• Delete what the source dropped. "Import never deletes documents" (Sanity Docs, Environments, October 2026), so list the IDs that left the old CMS since the last run and delete them in Sanity.
• Keep migrated documents hands-off. Sanity warns that editors may be editing while a migration runs (Sanity Docs, Important considerations, October 2026), and a rerun with --replace overwrites what they changed in Sanity Studio.

Safe imports into Sanity covers which import mode the final run needs and why.

What happens on cutover day, in order?

Cutover day from an old content management system (CMS) to Sanity runs in a fixed order: freeze, export, import, check, switch. Lower your DNS (Domain Name System) time to live (TTL) beforehand: Google suggests "a few hours" set "at least a week in advance" (Google Search Central, October 2026); Sanity's Webflow course says 300 seconds at least 24 hours before (Sanity Learn, October 2026). A week ahead meets both. A section-by-section run repeats steps 1 to 6 per section and switches routes, not DNS.

What can you roll back after a cutover to Sanity, and what can't you?

Rollback after a cutover to Sanity works in layers, and only switching traffic back to the old content management system (CMS) undoes the whole cutover, because the other layers restore documents, not the live site. Managed backups and dataset aliases need Enterprise, as of October 2026 (Sanity pricing; Sanity Docs, Backups, October 2026).

Deploi's wave 1 package for its Shopify data section, 406 documents and 159 images in October 2026, shipped with an ID list. Safe imports into Sanity covers the mechanics; backups and restore covers Enterprise.

When can you switch off the old CMS after moving to Sanity?

Switch off the old content management system (CMS) only after the rollback window closes and every old URL checks out against its redirect. Google's hosting guide says to shut old infrastructure down "when you're confident that all users, including Googlebot, are receiving content correctly from the new infrastructure" (Google Search Central, Changing your hosting, October 2026).

• Redirects outlive the old CMS. Google says to keep redirects "generally at least 1 year" (Google Search Central, Site Moves and Migrations, October 2026). In a Sanity stack redirects run in the front end or at the host (Deploi's reading of Sanity's redirects guide), so the old CMS can go first; keeping search rankings through a move to Sanity owns the redirect plan.
• Keep a reference copy. Sanity's Webflow course keeps the old staging URL "bookmarked and accessible" for visual checks after launch (Sanity Learn, October 2026).
• Time the license. End the old contract at a renewal date after the rollback window; the Contentful exit checklist works through one vendor's terms.