Does anyone else have fragmentation of data models in the same organization?

Contentful is great and offers a lot of flexibility. What I am observing is teams take it in different directions and build different custom models.

For example, one team has SEO metadata within a referenced content type, some other teams have these all built into the page template content type. There are different levels of cross references.

Has anyone experience this and can share their experience and the process on consolidating back into a standardized model?

Hello Kent,
You point out a very typical problem. Inevitably teams will make different decisions (sometimes short term, without coordinating with other teams), which can result in content models that are not reusable and don’t scale well. For example, two teams can create content types that are doing almost the same thing, but with a few minor differences.
We solve this problem by using Contentful Management API and and the Migration API. For example, with code, you can convert existing entries from one type to another and retire the duplicate types.

Thanks for the recommendation.

Can you go into more details on how to migrate off of short term models? It’s all possible through Content Management API for sure but there are coupling with other systems or the frontend application to the existing structure as well. How do you mitigate that?

One common approach with data model refactoring is obviously:

  1. create a union of the old and new model --> the current frontend will continue to run the old in production
  2. move the frontend app over to the new model
  3. with frontend decoupled from the old; remove old model and irrelevant data in Contentful

But this creates a management problem to the content editors as temporarily they will need to enter in multiple places…

Thoughts? more elegant ways?


Yes you describe the 3 steps, just as we experienced them (i guess we’re talking about the “expand migrations” and “contract migrations”). The temporary phase is a bit awkward, but it depends on the specifics.
If the content model change is relatively simple, but the amount of entries affected is high, you can script the transition from the old model to the new, making the temporary situation shorter. For example having a script that copies values from the old field to the new field in all locales is only a few lines of code in Content Management API, but is a real pain to do manually. It also saves your editors from having to deal with a refactoring that they may not really care much about.