Use cases
How do you consolidate several CMSs into one Sanity content platform without a big-bang migration?
Short answer
A phased CMS (content management system) consolidation into Sanity moves one source at a time on a shared base schema with source-prefixed IDs, so each site cuts over on its own while other CMSs keep running. Every source draws on one project quota: Growth's 25k documents count across datasets, drafts included (Sanity pricing; Sanity Docs, Plans and payments, October 2026).
- Content systems per organization
- 4.95 on average in 2023, up from 3.14AIIM's research over ten years; organizations running 7 to 10 content systems rose from 3.6% in 2013 to 14% in 2023Source: AIIM (Navigating the Content System Evolution)
- Document quota shared by every source
- 25k across all datasets on GrowthDrafts count, image and file assets don't. Growth has no document overage: the $299 a month Increased quota add-on lifts it to 50k, and past that the path is Enterprise, as of October 2026Sources: Sanity (Plans that scale with you); Sanity Docs (Plans and payments)
- Unique attributes on Growth
- 10,000 per datasetEach attribute and datatype combination counts once, so a schema that unions every source's fields spends it fast. Free allows 2,000; no add-on raises it, as of October 2026Sources: Sanity Docs (Technical limits, Attribute limit); Sanity (Plans that scale with you)
- References between sources
- Across datasets on Enterprise, never across projectsCross-dataset references need the same project, an Enterprise plan and the feature enabled, as of October 2026; content in separate projects can be copied by script but not referencedSources: Sanity Docs (Cross-dataset references, Platform terminology)
Deploi’s call
Don't consolidate in one cutover. Write the master map first, build one base schema, then move one CMS at a time, starting with the source that has a forcing date, and count each source done only when it is switched off. Federate prices, stock and entitlements instead of copying them into Sanity.
BuildConsolidate your content management systems (CMSs) onto one Sanity project when
- Most sources share their content types, so one base schema with per-site extensions covers them.
- One team owns that shared schema and its releases, because every source's editors work against it.
- The combined document count, drafts included, fits Growth's 25k or 50k with the $299 a month Increased quota add-on as of October 2026, or you will budget Enterprise.
- Each site can cut over on its own, with its own redirect map, while the other CMSs keep running.
DependsFederate into Sanity or keep a separate system when
- Another system masters fast-changing values such as price, stock or entitlements, so Sanity should hold a reference, not a copy.
- A site's team, front end and release cycle must stay fully separate, so a separate Sanity project fits, at the cost of references and duplicated settings.
- A merged schema would push one dataset toward the 10,000 unique-attribute ceiling on Growth as of October 2026.
- A CMS has no forcing date and shares little content with the others, so moving it adds cost without removing duplication.
Who needs to consolidate several CMSs, and when is it worth it?
Consolidating content management systems (CMSs) is worth it for a central digital or platform team that runs several sites, brands or regions on different CMSs and maintains the same content, integrations and skills once per system. The estate keeps growing: AIIM (the Association for Intelligent Information Management) found the average number of content systems in an organization rose from 3.14 to 4.95 over ten years, and the share running 7 to 10 systems rose from 3.6% in 2013 to 14% in 2023 (AIIM, October 2026).
A forcing date makes the case: when one source CMS reaches end of life or end of support, the team has to move it anyway, and consolidation turns that forced move into the first step of a program. The CMS end-of-life calendar lists those dates.
Should each CMS's content move into Sanity, be federated, or stay where it is?
Editorial content should move into Sanity, fast-changing values should be federated, and a content management system (CMS) with little shared content can stay, because each content element needs one system that masters it. Sanity's glossary advises "Decide which system masters which element" (Sanity, single source of truth, October 2026) and "federate the volatile data and own the editorial content locally" (Sanity, content federation, October 2026).
| Decision | Typical content | What Sanity holds | Trade-off |
|---|---|---|---|
| Consolidate | Articles, landing pages, legal copy, navigation | The documents | One shared quota and schema |
| Federate | Price, stock, entitlements | An identifier resolved at render time | Each request depends on the owning system |
| Separate project | A site with its own team, front end and releases | Its own documents | No references across projects |
| Keep | A CMS with no forcing date and little shared content | Nothing | The duplication stays |
A separate Sanity project blocks references and duplicates settings (Sanity Docs, multi-tenancy guide, October 2026). Content can be referenced across datasets only on Enterprise (Sanity Docs, Cross-dataset references, October 2026), and never across projects (Sanity Docs, Platform terminology, October 2026).
Which Sanity capabilities make a phased CMS consolidation work?
Six layers of Sanity carry a phased content management system (CMS) consolidation, and the import layer is where it differs most from a single-site migration, because every source lands in the same Content Lake.
The combination works for three reasons. Schemas are code, so one base schema serves every source with per-site layers: Sanity says Tata Digital used schemas in code to "create a base schema, and layer on product-level requirements" (Sanity, Tata Digital, October 2026). That was one source CMS: Sanity says Tata migrated 20,000 documents from Adobe Experience Manager (AEM) "with a single script in under 17 hours", and its 20-plus other tech stacks were connected by application programming interface (API), not migrated (Sanity, Tata Digital, October 2026). One Sanity Studio takes an array of workspace configurations, so each site gets its own editing space (Sanity Docs, Workspaces, October 2026). And Sanity Learn recommends reusing a unique source value as the document ID, which helps keep each migration script idempotent (Sanity Learn, Deterministic and consistent IDs, October 2026).
How do you consolidate one CMS at a time?
Consolidate one content management system (CMS) at a time in eight steps: map and model once, then import, cut over and retire each source in turn while the other CMSs keep running.
Consolidating several CMSs into Sanity, one source at a time
- Inventory every CMS. Count types, documents with drafts, URLs and owners per source (the content audit).
- Write the master map. Give every content element one mastering system and one decision.
- Design the base schema. Model shared types once, then add per-site extensions.
- Pick the first source. Deploi's judgment: the one with a forcing date, or the smallest blast radius.
- Import into a staging dataset. Use source-prefixed deterministic IDs, and a two-pass import when a script writes references (Sanity Learn, two-pass import, October 2026).
- Cut that site over. Ship its own redirect map and cutover and rollback plan while the other CMSs stay live.
- Retire the source. Make the CMS read-only, then switch it off; delete the staged copy.
- Repeat. Re-check document and attribute budgets first.
Stage in a separate dataset because Sanity says to run content migrations against a non-production dataset first (Sanity Docs, Environments, October 2026). Sanity recommends Content Releases for content changes, but it is an Enterprise add-on (Sanity pricing, October 2026), so on Growth use a separate dataset or Scheduled drafts.
Will the content of several CMSs fit in one Sanity project, and on which plan?
Several content management systems (CMSs) fit one Sanity project on Growth only if their combined documents, drafts included, stay under 25k, or 50k with the $299 a month Increased quota add-on, as of October 2026. The quota counts every dataset in the project, drafts count separately, and image and file assets don't count (Sanity pricing; Sanity Docs, Plans and payments, October 2026). Growth has no document overage, so past 50k the path is Enterprise, and a staged copy of a source spends documents twice until you delete it.
| Budget | Counted per | Growth, October 2026 | What a merge does |
|---|---|---|---|
| Documents | Project, all datasets | 25k, or 50k with the $299 a month add-on | Adds every source's documents and drafts |
| Datasets | Project | 2, plus up to 2 at $999 a month each | A dataset per source runs out at four |
| Unique attributes | Dataset | 10,000 | Unions every source's fields |
What counts as a Sanity document explains the quota, and the multi-brand guide answers how many datasets to use.
Why does a merged schema hit Sanity's attribute limit?
A merged schema hits Sanity's attribute limit because the limit is 10,000 unique attributes per dataset on Growth, and each source brings its own field names and types. Sanity counts an attribute as "any unique attribute/datatype combination" (Sanity Docs, Technical limits, October 2026), so a title that is a string in one source and an array in another counts at least twice. Free allows 2,000.
The fix is to normalize every source to the base schema before import, so the headlines of three content management systems (CMSs) land in one title field. Sanity's attribute limit guide says it offers no pay-as-you-go option for extra attributes, and asks teams that expect to pass 10,000 to contact Sanity before they get there (Sanity Docs, Attribute limit, October 2026).
What does consolidating CMSs onto Sanity replace, and what drives the cost?
Consolidating content management systems (CMSs) onto Sanity replaces three things for each retired CMS: its hosting and any license fee; its integrations with search, commerce or analytics; and the shared content it duplicates, such as legal copy and navigation. Consolidation doesn't replace the systems that master volatile values; those stay and get referenced.
The cost of a consolidation is driven by:
- Source count and distance. How many CMSs, and how far each one's content types sit from the base schema.
- Volume. Documents and drafts per source, which also decides whether Growth's quota holds.
- Rich text. Each source's markup needs its own path to Portable Text.
- URLs. Each site needs its own redirect map; redirects at scale covers the mechanics.
- Plan. Custom roles, cross-dataset references and more than 4 datasets (Deploi arithmetic from Sanity pricing: 2 included plus up to 2 extra) are Enterprise as of October 2026 (Sanity pricing, October 2026), which moves the Sanity bill to a custom quote.
Deploi quotes this work by scope, after the inventory, because none of these drivers is known until each CMS is counted.
What goes wrong when several CMSs merge into one Sanity project?
Several content management systems (CMSs) merging into one Sanity project go wrong in six known ways, and each has a fix:
- ID collisions. Sanity Learn's example ID is
post-234, type plus record ID (Sanity Learn, Deterministic and consistent IDs, October 2026), so two CMSs can both producepost-234. Fix: prefix by source as well as type (Deploi's judgment). - Webhooks firing on import. Sanity warns that an import can trigger webhooks and functions (Sanity Docs, Import data, October 2026). After the first cutover, a live site is listening. Fix: disable webhooks before each import and keep functions from running on imported documents, as the safe import guide shows.
- Unvalidated content. Mutations through the application programming interface (API) or client libraries skip Studio validation rules (Sanity Docs, Import data, October 2026). Fix: validate in the script.
- One redirect map for all sources. Fix: one map per source, shipped with its cutover.
- Editors crossing sites. Growth's Editor role reads and writes all datasets (Sanity Docs, Roles, October 2026); the multi-brand setup covers the fences.
- A source never retired. Deploi merged two of its own Sanity projects in September 2026, and the old project still held 12 FAQ articles, 3 of them drafts, on 24 October 2026. Fix: a consolidation ends when the source is retired, not when the import lands.
Deploi’s point of view
- Where we disagree
- The common ID advice for a migration, content type plus the source's record ID, is safe for one source and collides when two CMSs both have a post 234; with several sources the source belongs in the ID. The second wrong claim is that a big customer story proves a multi-CMS consolidation: Sanity's Tata Digital story says Tata migrated 20,000 documents from one CMS and connected its 20-plus other stacks by API, not migrated. And consolidation isn't all or nothing: a site with its own team and release cycle can keep its own Sanity project, or its own CMS, without failing the program.
- What we’ve seen
- deploi.ca is a multi-CMS site itself: its main pages run on other CMSs, and only its Shopify sections run on Sanity. On the Sanity side, Deploi merged two of its own Sanity projects into one. Per its runbook and README, the Shopify FAQ hub moved from a standalone project into the shared project on 26 September 2026, through a single-transaction cutover script that runs dry unless told to apply, deletes only allow-listed documents, checks referential integrity before deleting, and imports without --replace so editors' versions are never overwritten. The old project still holds 12 FAQ articles, 3 of them drafts, counted 24 October 2026. The shared project runs one Sanity Studio with three workspaces over two datasets, and the content wave packages Deploi ships to its Shopify sections carry a list of their document IDs, used to verify counts after import and to roll back.
- What we'd tell you to do first
- Write the master map before any schema: every content element, the one system that masters it, and whether Sanity will own it, reference it or leave it alone. That map decides the base schema, the order of sources and whether one Sanity project is enough.
- What we refuse to promise
- We don't promise a consolidation date or a cost before the inventory. Documents with drafts, attributes per dataset and each source's redirect map set the size of the job, and none of them is known until each CMS is counted.
When this answer changes
- Sanity changes Growth's 25k document quota, the $299 a month Increased quota add-on or its 50k ceiling
- Sanity changes the 10,000 unique-attribute limit, or its pages agree on Enterprise's attribute ceiling
- Sanity changes Growth's 2 included datasets or the $999 extra-dataset price
- Content Releases or cross-dataset references become available on Growth
- Sanity publishes a customer story of several CMSs consolidated in sequence
- Sanity Learn retires or rewrites its deterministic IDs or two-pass import lessons
Sources
Every source opened and checked on 25 October 2026.
- Sanity, Plans that scale with you
- Sanity Docs, Plans and payments
- Sanity Docs, Technical limits
- Sanity, What is content federation?
- Sanity, What is a single source of truth for content?
- Sanity Docs, How to implement multi-tenancy with Sanity
- Sanity Docs, Platform terminology
- Sanity, Scaling a multi-brand e-commerce mobile app
- Sanity Learn, Deterministic and consistent IDs
- Sanity Learn, Import content with the two-pass pattern
- Sanity Docs, Development, staging, and production environments
- Sanity Docs, Import data
- Sanity Docs, Roles
- Sanity Docs, Workspaces
- Sanity Docs, Cross-dataset references
- Sanity Docs, Attribute limit
- AIIM, Navigating the Content System Evolution