Safe content migrations in production

Example content migration scenario

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.

1. Create a non-production environment

Create a clone of your production environment so that you have a place for testing. Your own development sandbox.

2. Create migration scripts

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.

3. Run the migration scripts

Run the migration scripts to update and migrate your content model and data.

4. Validate the migration scripts

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.

5. Mark the staging environment as production

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.

6. Clean-up