Overview

Safe content migrations in production

Jan Cerman, David Klement

3 minutes

Environments

0% complete

Performing content migrations directly in production can be risky. To mitigate that risk, we recommend you clone your production environment, make your changes in the clone, validate and test, and swap the two environments. This approach works well for both small and complex changes.

Let’s say you have a project with blog articles. Each article has an author typed manually as “Jane Doe” into a text element. At some point, you decide you want to include additional information about the authors, such as their bio and profile image. Because adding these details to each article would take a long time, you create a new content type called Author. And then you link the Author content items to the articles. As this is a content model change, you want to first test everything in a separate environment before committing it to production. The following steps outline how to do it. Create a clone of your production environment so that you have a place for testing. Your own development sandbox. Write migration scripts. You’ll use these scripts to change the content model and migrate your content from the old model to the new one. Run the migration scripts to update and migrate your content model and data.

When your migration scripts are doing what you want under the non-production environment, it’s time for a double-check. Create a new staging environment by cloning the production environment again. Then run your migration scripts against the new staging environment.

Although this step isn’t critical, it helps ensure that all ends well. The production environment has probably changed while you were writing the migration scripts, so it’s a good practice to check if they work with the latest production content.

If your migration scripts do what you want in the staging environment, you can mark the staging environment as production.

Remember to rename the two environments after you mark the staging environment as production.

You’re done with the migration, and your production content model is updated. The content freeze is over. Your content creators can make changes again.All that’s left to do is clean up. Delete the staging and development environments because they’re not needed anymore. The next time you need to perform a content migration, you’ll create new ones.

Kontent.ai Learn

Example content migration scenario

1. Create a non-production environment

2. Create migration scripts

3. Run the migration scripts

4. Validate the migration scripts

5. Mark the staging environment as production

6. Clean-up

Example content migration scenario

1. Create a non-production environment

2. Create migration scripts

3. Run the migration scripts

4. Validate the migration scripts

5. Mark the staging environment as production

6. Clean-up

Cheat sheets
Documentation
API reference
Product updates
Sign in

Try Kontent.ai
Plan
Set up
Model
Develop
Create

Sign in with your Kontent.ai credentials or sign up for free to unlock the full lesson, track your progress, and access exclusive expert insights and tips!

Web
Privacy policy
Cookies policy
Consent settings
Security
GDPR

Safe content migrations in production | Kontent.ai Learn

Safety first!Make sure to run the migration scripts against a testing non-production environment first. Each environment has its own set of API keys.

Time for a content freezeAt this point, we recommend you stop making any content changes in your production environment. That means coordinating with your content creators so that they avoid making changes during the migration.