# How do you consolidate several CMSs into one Sanity content platform without a big-bang migration?

Reviewed by Martin Dejnicki · facts verified 25 October 2026 · canonical: https://deploi.ca/sanity/use-cases/cms-consolidation

Experience: Reviewed from Sanity's documentation, not production use.

## 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](https://www.sanity.io/pricing); [Sanity Docs, Plans and payments](https://www.sanity.io/docs/platform-management/plans-and-payments), October 2026).

- **Content systems per organization:** 4.95 on average in 2023, up from 3.14. AIIM's research over ten years; organizations running 7 to 10 content systems rose from 3.6% in 2013 to 14% in 2023 ([AIIM, Navigating the Content System Evolution](https://info.aiim.org/aiim-blog/navigating-the-content-system-evolution-how-many-content-systems-do-you-manage))
- **Document quota shared by every source:** 25k across all datasets on Growth. Drafts 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 2026 ([Sanity, Plans that scale with you](https://www.sanity.io/pricing); [Sanity Docs, Plans and payments](https://www.sanity.io/docs/platform-management/plans-and-payments))
- **Unique attributes on Growth:** 10,000 per dataset. Each 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 2026 ([Sanity Docs, Technical limits](https://www.sanity.io/docs/content-lake/technical-limits); [Sanity, Plans that scale with you](https://www.sanity.io/pricing); [Sanity Docs, Attribute limit](https://www.sanity.io/docs/content-lake/attribute-limit))
- **References between sources:** Across datasets on Enterprise, never across projects. Cross-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 referenced ([Sanity Docs, Cross-dataset references](https://www.sanity.io/docs/studio/cross-dataset-references); [Sanity Docs, Platform terminology](https://www.sanity.io/docs/platform-management/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.

**BUILD: Consolidate 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.

**DEPENDS: Federate 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](https://info.aiim.org/aiim-blog/navigating-the-content-system-evolution-how-many-content-systems-do-you-manage), 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](https://deploi.ca/sanity/migration/leaving-a-legacy-cms/cms-end-of-life-calendar) lists those dates.

> **When CMS consolidation isn't worth it**
>
> - The CMSs share almost no content types, so one schema would be a union of unrelated models.
> - No team will own a shared schema and its releases.
> - Only one site is moving: that is [a single CMS migration to Sanity](https://deploi.ca/sanity/migration/cms-to-sanity), not a consolidation.

## 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](https://www.sanity.io/glossary/single-source-of-truth), October 2026) and "federate the volatile data and own the editorial content locally" ([Sanity, content federation](https://www.sanity.io/glossary/content-federation), October 2026).

**Editorial content consolidates, volatile values are referenced, and a separate team may keep its own project**

| 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 |

The "Typical content" column and the "Keep" row are Deploi's judgment. Sources: [Sanity, What is content federation?](https://www.sanity.io/glossary/content-federation); [Sanity Docs, How to implement multi-tenancy with Sanity](https://www.sanity.io/docs/developer-guides/multi-tenancy-implementation); [Sanity Docs, Platform terminology](https://www.sanity.io/docs/platform-management/platform-terminology). As of 24 October 2026.

A separate Sanity project blocks references and duplicates settings ([Sanity Docs, multi-tenancy guide](https://www.sanity.io/docs/developer-guides/multi-tenancy-implementation), October 2026). Content can be referenced across datasets only on Enterprise ([Sanity Docs, Cross-dataset references](https://www.sanity.io/docs/studio/cross-dataset-references), October 2026), and never across projects ([Sanity Docs, Platform terminology](https://www.sanity.io/docs/platform-management/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.

**A phased CMS consolidation on Sanity, from editing to access**

- Editing: Sanity Studio workspaces
- Model: shared base schema types, a site field, references
- Import: Sanity command-line interface (CLI) dataset import, migration scripts, deterministic IDs
- Storage: Content Lake datasets
- Delivery: Graph-Relational Object Queries (GROQ) filtered by site
- Access: built-in roles, custom roles on Enterprise

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](https://www.sanity.io/customers/tata), 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](https://www.sanity.io/customers/tata), October 2026). One Sanity Studio takes an array of workspace configurations, so each site gets its own editing space ([Sanity Docs, Workspaces](https://www.sanity.io/docs/studio/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](https://www.sanity.io/learn/course/refactoring-content/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**

1. **Inventory every CMS.** Count types, documents with drafts, URLs and owners per source (the content audit).
1. **Write the master map.** Give every content element one mastering system and one decision.
1. **Design the base schema.** Model shared types once, then add per-site extensions.
1. **Pick the first source.** Deploi's judgment: the one with a forcing date, or the smallest blast radius.
1. **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](https://www.sanity.io/learn/course/migrating-content-from-webflow-to-sanity/two-pass-import), October 2026).
1. **Cut that site over.** Ship its own redirect map and [cutover and rollback plan](https://deploi.ca/sanity/migration/cms-to-sanity/cutover-and-rollback) while the other CMSs stay live.
1. **Retire the source.** Make the CMS read-only, then switch it off; delete the staged copy.
1. **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](https://www.sanity.io/docs/content-lake/environments), October 2026). Sanity recommends [Content Releases](https://deploi.ca/sanity/features/content-releases) for content changes, but it is an Enterprise add-on ([Sanity pricing](https://www.sanity.io/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](https://www.sanity.io/pricing); [Sanity Docs, Plans and payments](https://www.sanity.io/docs/platform-management/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.

**A consolidation spends three Sanity budgets at once, and the attribute ceiling is the one Growth can't raise**

| 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 |

The "What a merge does" column is Deploi's judgment from the sources above. Sources: [Sanity, Plans that scale with you](https://www.sanity.io/pricing); [Sanity Docs, Plans and payments](https://www.sanity.io/docs/platform-management/plans-and-payments); [Sanity Docs, Technical limits](https://www.sanity.io/docs/content-lake/technical-limits). As of 24 October 2026.

What counts as a Sanity document explains the quota, and [the multi-brand guide](https://deploi.ca/sanity/use-cases/multi-brand-content-hub) 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](https://www.sanity.io/docs/content-lake/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](https://www.sanity.io/docs/content-lake/attribute-limit), October 2026).

> **Sanity's pages disagree on Enterprise's attribute ceiling**
>
> Sanity's pricing page lists unique attributes per dataset as "Custom" on Enterprise ([Sanity pricing](https://www.sanity.io/pricing), October 2026). Its technical limits ([Sanity Docs, Technical limits](https://www.sanity.io/docs/content-lake/technical-limits), October 2026) and attribute limit pages give Enterprise the same 10,000 as Growth, and the attribute limit page says moving to Enterprise doesn't raise it ([Sanity Docs, Attribute limit](https://www.sanity.io/docs/content-lake/attribute-limit), October 2026). Get your contract's number in writing before you plan a merged schema around a higher one.

## 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](https://www.sanity.io/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](https://www.sanity.io/learn/course/refactoring-content/deterministic-and-consistent-ids), October 2026), so two CMSs can both produce `post-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](https://www.sanity.io/docs/content-lake/importing-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](https://deploi.ca/sanity/migration/cms-to-sanity/safe-import) shows.
- **Unvalidated content.** Mutations through the application programming interface (API) or client libraries skip Studio validation rules ([Sanity Docs, Import data](https://www.sanity.io/docs/content-lake/importing-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](https://www.sanity.io/docs/user-guides/roles), October 2026); [the multi-brand setup](https://deploi.ca/sanity/use-cases/multi-brand-content-hub) 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

## Ready to plan your CMS consolidation?

Contact us today to work out your master map, which CMS moves to Sanity first and whether one Sanity project holds them all. [Contact us](https://deploi.ca/contact)

## Sources

1. [Sanity, Plans that scale with you](https://www.sanity.io/pricing), checked 24 October 2026
2. [Sanity Docs, Plans and payments](https://www.sanity.io/docs/platform-management/plans-and-payments), checked 24 October 2026
3. [Sanity Docs, Technical limits](https://www.sanity.io/docs/content-lake/technical-limits), checked 24 October 2026
4. [Sanity, What is content federation?](https://www.sanity.io/glossary/content-federation), checked 24 October 2026
5. [Sanity, What is a single source of truth for content?](https://www.sanity.io/glossary/single-source-of-truth), checked 24 October 2026
6. [Sanity Docs, How to implement multi-tenancy with Sanity](https://www.sanity.io/docs/developer-guides/multi-tenancy-implementation), checked 24 October 2026
7. [Sanity Docs, Platform terminology](https://www.sanity.io/docs/platform-management/platform-terminology), checked 24 October 2026
8. [Sanity, Scaling a multi-brand e-commerce mobile app](https://www.sanity.io/customers/tata), checked 24 October 2026
9. [Sanity Learn, Deterministic and consistent IDs](https://www.sanity.io/learn/course/refactoring-content/deterministic-and-consistent-ids), checked 24 October 2026
10. [Sanity Learn, Import content with the two-pass pattern](https://www.sanity.io/learn/course/migrating-content-from-webflow-to-sanity/two-pass-import), checked 24 October 2026
11. [Sanity Docs, Development, staging, and production environments](https://www.sanity.io/docs/content-lake/environments), checked 24 October 2026
12. [Sanity Docs, Import data](https://www.sanity.io/docs/content-lake/importing-data), checked 24 October 2026
13. [Sanity Docs, Roles](https://www.sanity.io/docs/user-guides/roles), checked 24 October 2026
14. [Sanity Docs, Workspaces](https://www.sanity.io/docs/studio/workspaces), checked 24 October 2026
15. [Sanity Docs, Cross-dataset references](https://www.sanity.io/docs/studio/cross-dataset-references), checked 24 October 2026
16. [Sanity Docs, Attribute limit](https://www.sanity.io/docs/content-lake/attribute-limit), checked 24 October 2026
17. [AIIM, Navigating the Content System Evolution](https://info.aiim.org/aiim-blog/navigating-the-content-system-evolution-how-many-content-systems-do-you-manage), checked 24 October 2026