Migrating without downtime

Beyond the technical tasks of re-platforming, pausing content operations while switching to the new platform frustrates authors and developers. Your migration strategy should account for reducing the time and pressure for all parties on the day you switch.

To avoid or minimise a "content freeze", your migration script should be able to run against the most up-to-date version of your current platform's content.

Ideally, your migration script should be "idempotent". That is, you can run the script many times, and it will produce the same result. Your import script should create the same documents with each run.

This is made possible with Sanity because document IDs can be predetermined, so you can reuse IDs from your existing data source, and each invocation of your migration script will update the same document, not create a new one.

These strategies are covered in more detail in Refactoring content for migration.

Defend your new front-end from errors in advance by validating every document as it is migrated. Runtime validation tooling like Zod can ensure the content you're uploading matches the shape your Sanity Studio schema types are expecting.

Once your content is in Sanity Studio, you can validate all documents in the dataset against the rules set in your schema types from the command line:

npx sanity@latest documents validate

For front-ends with a huge content volume, manually checking every page is problem-free may not be scalable. Adding automated testing to your front-end should catch any post-migration errors before your users do.

Using a tool that can scan your front-end for errors, downtime, and broken links will likely catch any on-page problems in advance. This is also critical for maintaining a good SEO standing after re-platforming.

If you are re-purposing an existing front-end but with a new data source, you may want to integrate a visual regression tool to compare before and after states of every page.