Discussion on organizing schemas and splitting schemas with the same name in Sanity

Hello, i am very new to Sanity and try to organise/structure my schemas nicely. I already did some work and now i am realising that my structure wasn’t that good. My structure is the following:
I have the problem that i have some sections that have the same name because they are used in different documents. Nevertheless, these elements are different. So i tried to change the structure like following:

Obviously it is not possible to have schema with the same name. But now my Question. How can I change my schema name without losing all the content in the Studio. If I change the schema name I lose all my content. Perhaps there is a way to transfer the contents? I hope someone can help me. Thank you in advance.

If you have a lot of documents and data in your dataset — This guide for exporting data may be the reference you need. The idea is that you export your data, go through the json data file, and update your document headers or IDs with your new desired types. There are a variety of third party tools to make this easier than it sounds.

BUT… from your change I wonder if there is a way to do this with creative schema updates.
You could add a new field or related document to your hero schema. Continue to use ONE hero schema for your different sections. Then add that field (or a variety of desired fields) to your single hero schema.

Then when you query your data, include a statement like

Now this is either one extra query statement on your front end or an extra line in your existing query. And you don’t have to do the entire export import thing - along with having a single source of truth for all of your hero sections

Thanks a lot for the answer. I really want to split the two hero schemas. So i will try to do the migration.

Thanks a lot for the answer. I really wont to split the two hero schemas. So i will try to do the migration.

Hey , , unfortunately I haven’t gotten around to making the change on my end yet. But I have already tried the migration and it worked well.Unfortunately, I am still not satisfied with the structure. I now have the structure as shown above. So in my sections two folders with two different brands of the customer. These each have different hero schemas. Named with abcHero and xyzHero. However, I find this solution unattractive and was hoping to find another.
I still want to separate the two hero’s from each other. Is there any way to manage two schemas with the same “name” attributes? Maybe via two separate schema.js files or something?
Couldn’t find any solution.

For some further discussions on your content structure, you might enjoy the conversations in content-modeling and content-strategy.
For your desires to duplicate schema files, you’re going to come up against some fundamental javascript and coding things in general. Even if you completely duplicate your studio, while you’re in the same dataset - a

hero

document type is going to be the same regardless. If you want to juggle both clients in a single dataset, I think this would be extremely doable.
Maybe most of all, a little
head tilt on the concepts of schemas vs documents might be in order. Your schemas define what appears in your documents. Your documents are where the data is. So, if you make a “hero type” schema, you can make 100 “hero type” documents. If you want to add different fields to different hero types, you’ll need to create a new type or hide/show the fields depending on selections made in the document. Which of those hero or footer docs is referenced into each customer site would depend on your query that you build in your frontend vs the data in your document.
so, if you’re building multiple sites from a single dataset, I would suggest adding a “client” selection to your hero schema and then alter your query in each site to return the specific document for each section you want to display. You could even add a fn to insert a constants value into your query from another file and copy paste all of your sites, just needing to fill in the constants values to change the query sources relative to the client selection I noted.