Re-modelling your existing content

There's a high likelihood that your incumbent, monolithic platform stores content in a way that is tightly coupled to its presentation.

If your authors' day-to-day content operations involve building and editing web pages, this re-platforming is a great opportunity to implement structured content to avoid another costly re-platforming in the near future.

Consider the following web pages: staff profiles, products, and stores. When thinking about this content in a presentational context—like a website—it's tempting to store all of these as "pages" that use a unique template: "a staff profile web page, a product web page," etc.

Avoid trapping content about what something is in content models that describe what it looks like in the front end.

A staff profile should be stored as a "person" document. Product content should be stored in a "product" document. Stores could be stored in a "location" document.

All the data within these document types can still be queried into and displayed on a web page; they just don't need to be stored in—or thought of as—web pages inside your Sanity Studio.

Where possible, move from presentational thinking towards structured content. Use as few "pages" as possible, and where pages are used, leverage references to individual, meaningful content documents.

Depending on the age of your legacy platform, you may also have some similar content models that do not need to be separated. For example, you may have "person" and "staff" records or "office" and "store" records.

Your existing content—including rich text and block content—may be stored as HTML strings or markdown in flat files or an SQL database.

The preferred way of storing rich text and block content in Sanity Studio is Portable Text, an open standard for storing this content in JSON so that it is queryable, filterable, and ... portable.

Authoring Portable Text is made simple by the Sanity Studio's Portable Text Editor. However, migrating existing content into the Portable Text standard takes some finessing. This is covered in more detail in Refactoring content for migration.

Remodeling your content can have a profound SEO impact if it also affects the structure of your website. Consider carefully planning for a backend of structured content that renders a consistent, SEO-friendly front-end.

Your re-platformed front-end should not create a new link structure without appropriate redirects.

At a minimum, you should not only be extracting content from your existing platform but also "crawling" your existing website to record all pages that currently exist and ensure you're recreating those pages or at least redirecting from those that no longer exist to pages that now will.

"There is only one way to eat an elephant: one bite at a time."

You might not need to re-platform your entire application in one move. To reduce the impact of your initial efforts, identify low-risk content and perform an incremental migration. Prove its worth, and then expand the rollout.

Popular content types include legal documents like your terms of service or support pages. These are typically simpler, more static pieces of content that can be easily isolated.

In the next lesson, you'll learn more about how to re-platform without imposing downtime and interruption to your services.