Migration Splitting

Cased automatically identifies database migration changes in pull requests and enables team members to manage these changes effectively through Slack notifications and interactive actions.

​

Overview

When a pull request contains database migration changes, the system:

1. Automatically detects the migration files
2. Sends a Slack notification to relevant team members
3. Provides options to manage these changes directly through Slack

​

How It Works

​

Migration Detection

Cased smartly identifies database related changes in a pull request. This process is framework agnostic and can detect both data model changes as well as framework generated changes. Once migrations are found, Cased will send a notification in slack:

Alternatively, in case you want to split at later times or the slack message could not be found anymore, you can always go to your branch page to split the changes. You can navigate to your main deploy view and click the branch or directly go to
https://app.cased.com/projects/<your project name>/branches/<your branch name>

​

Split Changes

Splitting database migrations into separate PRs allows teams to deploy schema changes independently of application code, reducing deployment risks and making rollbacks simpler if issues arise. To split these changes, simply click on the button Split Changes in the slack notification message, and Cased will automatically open new PR containing migrations alone.

Optionally, users can click Split and Remove button to remove migrations from original pull request to ensure complete separation.

​

Framework Support

The detection system supports all major database migration frameworks and custom solutions out of the box:

​

ORM Migrations

• Ruby on Rails Migrations
• Python Alembic
• TypeORM
• Prisma
• Django Migrations
• Entity Framework
• Flyway
• Sequelize
• Knex.js

​

Raw SQL

• Raw SQL files
• SQL Scripts
• Database-specific formats (*.pgsql, *.mysql)
• Stored procedures

​

Custom Migrations

• Custom migration formats
• Framework-specific patterns
• Company-specific standards
• Legacy migration systems
• In-house solutions

​

Best Practices

1. Review Before Splitting: Always review the detected migrations before splitting them into a separate PR
2. Communication: Use the Slack thread to discuss migration changes with team members
3. Documentation: Include relevant documentation when splitting migrations into a separate PR
4. Testing: Ensure both PRs (original and split) have appropriate test coverage