Do you want to migrate content within ButterCMS?
Migrating Content Schema Within Butter
Using multiple environments is a development best practice for creating new content experiences. Working in a non-production environment helps separate experimental changes so you can safely work without accidentally impacting your production application.
ButterCMS Migrations make migrating configuration data across your environments dead simple. Simply create a Migration from a test environment that specifies what you want to migrate and to which environment.
For example, let's say we are working on creating a new FAQ section for our site, so we've developed a
FAQ Page Type in our
Dev environment. Now we are ready to move it to our
Staging environment, simply create a Migration:
Migrating Content Within Butter
With a few clicks, you can migrate a Page Type and its associated pages or a collection and all of its items, making it easy to stage new content experiences and instantly launch them into your production environment when ready.
You can also view a log of all the migrations that took place in each environment so you can keep track of everything:
Note: Our migrations feature does not support incremental updates, yet.
Configuration versus content
A quick note on migrating configuration data versus content across ButterCMS environments. Configuration data (Page Types and Collections) in Butter is akin to a schema for a database. They are distinct from the content (data in a database). We recommend using ButterCMS environments for Migrating schema only. For example, testing out launching a new PageType or Collection or making changes to an existing one. Since this impacts the structure of the JSON from our API, you will want to test this in coordination with code changes in your application to display this new content. You can do this safely via ButterCMS environments and migrate across environments using our schema Migration feature.
How to handle References
ButterCMS has a powerful feature called References which allows you to create relationships between your content types. In database terminology, this is like a foreign key from one table to another. Here's how to handle this when migrating:
- PageTypeA has Reference to PageTypeB
- Migrate PageTypeB first
- Then migrate PageTypeA