Risk-free Migrations in Commitspark

Applying Content Model Changes

The Pitfalls of Migrations

How hard can it be to rename a content element or otherwise adjust a content model in a legacy CMS when content already exists? Quite hard, as it turns out: From migration scripts that fail half-way through in production to an unclear recovery path in such situations. There are plenty of pitfalls that can bring down production - just ask your content teams.

Illustration of people discussing content

Iterate Content Models without Risk

Where content teams held their breath when running a migration script in a legacy CMS, Commitspark instead lets them prepare changes to content models and content entries in advance using branches. This exposes any remaining migration issues long before they hit production.

Legacy CMS

  • Migration script failures in production leave content in an undefined state
  • Migration script execution must be manually tracked to prevent duplicate migrations
  • Recovery from migration failures is very hard due to a lack of fine-grained backups
  • Model migrations and corresponding content changes are applied separately to production
  • Migration scripts can work in QA but fail in production due to stale QA content


  • Migration script failures can be caught and fixed already before merging a branch
  • Git prevents changes (i.e. commits) from being applied twice
  • Recovering from unintended content changes is as easy as reverting a commit
  • Model and content changes can be prepared together in a branch and merged into production simultaneously
  • Changes to production content can be "back-merged" into QA at any time to prevent migration failures from the get-go