iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
If your content model describes what things are (a product, an author, a step in a guide) rather than how one design displays them (a blue callout, a floated image, a two-column block), a redesign mostly changes the front end and leaves the content usable. If the model is built around the current layout, every redesign turns into a content rewrite. In Sanity, the schema also does not migrate existing documents on its own, so the change to the model and the change to the stored content have to be planned as two separate pieces of work.
This article covers the modeling choices that make content easier to reuse across redesigns, the difference between a page builder and front-end composition, and the migration steps Sanity documents for changing a schema that already has content in it. The guidance comes from Sanity’s official documentation. It does not report measured redesign times or costs, and it does not attribute outcomes to specific client projects.
Model what the content means, not how the current design shows it
Sanity’s guide How to use structured content for page building recommends modeling for meaning rather than presentation. Its reasoning is that presentation contexts have different constraints, and design-specific concerns such as colors and floats add complexity for both the implementation and the editors who use it. The guide frames a redesign as one of two situations: applying clean content to a new channel or design, or untangling content from presentation details that only made sense for the previous design. The second situation is the expensive one, and it is almost always caused by the first modeling decision.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
The same guide puts the goal in one sentence, attributed to its contributors Knut Melvær (Head of Developer Community and Education), Simeon Griggs (Principal Educator), and Irina Blumenfeld (Solution Architect): “The goal of structured content is to make sure that your content stays resilient, adaptable, and easy to integrate wherever you need it.”
#1 Best Overall
In practice, the difference looks like this:
| Presentation-coupled field | Meaning-based field | Why the second survives a redesign |
|---|---|---|
| heroBackgroundColor | featuredImage or no field at all | A new brand palette does not change what the hero is about; the color belongs in the front-end theme. |
| floatLeftImage (boolean) | image with an optional caption and alt text | Whether an image sits left, right, or full-width is a layout decision made by each template. |
| sidebarBlock | relatedArticles, or a reference to a shared component | The sidebar may disappear in the next design, but the related-content relationship still means something. |
| blueCalloutType | warning, tip, or note | The editorial purpose stays the same when the callout is restyled or moved. |
The rule of thumb is to ask what a field means to an editor writing the content. If the answer depends on the current look, the field is probably tied to the design and should be modeled again.
Why structured content in Sanity holds up across channels
Sanity describes its Content Lake in its documentation on storing and querying structured content. Content is stored as JSON documents that can be queried, referenced, and delivered to different channels. Because documents can reference each other, a single piece of content can be linked into several places rather than copied into each one.
Sanity calls this connected content: the same content chunk can be reused and repurposed in different contexts. For a redesign, the practical benefit is that the concepts (articles, authors, product specifications, FAQs) persist as documents, while the code that renders them changes. A new website, a mobile app, or an email template can query the same documents and apply its own presentation.
This only works if the documents themselves are meaningful. Reuse across channels fails when a document carries a layout instruction that one channel cannot honor.
Page builders and front-end composition are different trade-offs
Editors often ask for a page builder: a set of content modules they can arrange on a page. Sanity’s guide says modules can give editors control over page composition while keeping the implementation compatible with component-based front-end frameworks and design systems. It also cautions that a page builder may not be needed, because front-end rules can combine content from different sources. The decision should start with the editorial task and the content relationships, not with an attempt to reproduce every screen layout in the schema.
| Question | Page-builder model | Front-end composition |
|---|---|---|
| Who decides page structure? | Editors, by arranging modules in Studio | Developers, through rules that assemble content from several documents |
| Semantic durability | Depends on whether module types describe meaning or a specific layout | Depends on whether document types describe meaning; layout lives in the front end |
| Reuse across channels | Modules may need a rendering path for every channel that uses them | Documents are queried directly by each channel |
| Redesign impact | Module definitions and stored page data may both need changes | Mainly front-end code, plus any schema changes to documents |
| Best fit | Marketing teams that need frequent, flexible page layouts | Products where page structure is stable and content relationships are complex |
Neither option is automatically correct. A team that picks a page builder should still define its modules by meaning, for example a “call to action” with a label and a target, not by a layout such as “three-column promo”.
Rank #3
A schema change does not migrate your content
Sanity schemas are JavaScript or TypeScript definitions. They control the structure of content and the editing experience in Sanity Studio. The Content Lake is schemaless: it does not enforce the Studio schema for API writes, and a schema edit does not reshape or remove existing documents. Sanity’s documentation on introduction to schemas describes the schema’s role in the editing experience.
This flexibility makes gradual change possible, because old and new document shapes can coexist. It also means nothing is migrated automatically. Your team decides which documents to migrate, how to validate them, and which shapes your application code must still support during the transition.
Treat this as the central fact of any redesign project. The schema work is quick. Deciding what happens to the millions of existing documents, or even to the few hundred on a small site, is where the effort goes.
Migration workflow for a schema that already has content
Sanity’s guide to important considerations for schema and content migrations and its guide to migrating your schema and content describe the following sequence. Follow it in order, because each step checks the one before it.
- Back up the dataset. Export or back up the data before any change. Sanity recommends a backup before applying a migration, and the dry-run step does not replace it.
- Copy the data to a staging dataset. Run the rest of the process against the copy so that production is not the first place a mistake appears.
- Change the schema and validate existing documents. Check documents against the changed schema to find those that no longer conform. The CLI supports schema validation and document validation for this step.
- Write the migration as code. Sanity’s migrations are code-defined scripts. They transform documents through mutations and patches, so each change is explicit and repeatable.
- Review the dry run. The migration command runs in dry-run mode unless you explicitly tell it to apply changes. The dry-run output lists the proposed patches and the document IDs they affect. Check a sample of documents by hand, not just the counts.
- Apply the migration to staging. Confirm that the migrated documents match what the new front end expects.
- Update queries and downstream code. Change every query, template, and integration that reads the affected fields. Where a rollout cannot be instant, write code that supports both the old and new shapes until the migration is finished.
- Repeat the process against production. Only after the staging run has been reviewed and the dependent applications have passed testing, apply the approved migration to production.
The defensive code in step 7 is often the part teams skip, and it is the part that keeps a live site working during the transition. Sanity’s documentation presents this as a route to staged change, not as a guarantee that migrations are risk-free.
Recommended Free Tools
Check changes in context before they go live
Migrated content can pass validation and still render badly. Sanity’s guide on presenting and previewing content describes high-fidelity previews that let editors, reviewers, and stakeholders see in-flight changes in the real experience before publishing. The Presentation Tool documentation describes contextual visual work inside Studio.
Best Value
- Used Book in Good Condition
Use preview to check how migrated or newly modeled content appears in the new design. Preview does not validate the schema or prove that a migration is correct. Those checks belong to the validation and dry-run steps above.
What the evidence does and does not establish
The principles here are documented recommendations from Sanity. They are not measured outcomes. Sanity’s official guidance does not publish a statistic on redesign time, redesign cost, or project performance, and this article does not supply one. It also does not identify particular client projects whose results can be attributed to these choices. If a team reports a specific saving, it should be measured against its own baseline, because the effect depends on how much presentation logic was embedded in the content before the redesign started.
Quick Recap
Checklist before you redesign a Sanity site
- Each field describes a meaning an editor would recognize, not a color, float, column, or position.
- Shared content is modeled as documents and referenced, so one change reaches every place it appears.
- The page-composition choice (page builder or front-end rules) was made from the editorial task, not from the old layout.
- Every affected document type has a validation check against the changed schema.
- A backup exists and a staging dataset is populated before any migration is written.
- The dry-run output has been reviewed, including a manual check of sample documents.
- Queries and templates that read changed fields are updated, and any transitional code is scheduled for removal.
- Previews of migrated pages have been checked against the new design before publication.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Free tools Windows power users keep installed
One-click scans. No signup required.
