Standard : Database changes are versioned, tested, and deployed safely alongside application code
Purpose and Strategic Importance
Database schema changes are among the highest-risk operations in any software delivery pipeline. When migrations are managed informally — applied manually, stored outside version control, or executed independently of application deployments — the risk of data corruption, schema drift, and production incidents increases dramatically. This standard establishes that all schema changes must be tracked in version control, validated in lower environments, and applied automatically as a coordinated part of the deployment pipeline, ensuring the database and application code always evolve together.
Beyond risk reduction, treating database changes as first-class delivery artefacts enables teams to move faster with greater confidence. Automated migration execution eliminates the coordination overhead of manual DBA handoffs, rollback strategies become deliberate and tested rather than improvised under pressure, and zero-downtime techniques such as expand-contract patterns allow continuous deployment even for complex schema changes. Teams that adopt this standard experience fewer production incidents related to database changes and recover significantly faster when issues do occur.
Strategic Impact
- Eliminates schema drift and the class of production incidents caused by mismatched database and application versions
- Enables continuous delivery by making database changes a safe, automated step in every deployment pipeline
- Reduces dependency on manual DBA intervention, freeing specialist capacity for higher-value work
- Provides a full auditable history of schema evolution, supporting compliance, forensic investigation, and onboarding
Risks of Not Having This Standard
- Production data loss or corruption caused by untested or mis-sequenced schema migrations applied under pressure
- Schema drift between environments leading to bugs that only surface in production, after customer impact
- Inability to roll back a failed deployment because the database change cannot be cleanly reversed
- Prolonged outages during deployments that require manual coordination between application and database releases
- Loss of audit trail for regulatory or forensic purposes when schema changes are applied out-of-band
CMMI Maturity Model
Level 1 – Initial
| Category |
Description |
| People & Culture |
Database changes are applied manually by individuals with no shared process or documentation. |
| Process & Governance |
No standard approach exists; migrations are ad hoc and undocumented across teams. |
| Technology & Tools |
Schema changes are executed directly against environments using scripts stored locally. |
| Measurement & Metrics |
There is no tracking of migration history, failures, or time spent on database changes. |
Level 2 – Managed
| Category |
Description |
| People & Culture |
Some teams store migration scripts in version control but practices are inconsistent organisation-wide. |
| Process & Governance |
A basic process exists for applying migrations but it relies on manual steps and individual discipline. |
| Technology & Tools |
A migration tool such as Flyway or Liquibase is used by some teams in some environments. |
| Measurement & Metrics |
Migration scripts are tracked in source control, providing a partial history of schema changes. |
Level 3 – Defined
| Category |
Description |
| People & Culture |
Teams treat database migrations as part of the codebase, reviewed and approved alongside application changes. |
| Process & Governance |
Migrations are mandatory for all schema changes, validated in CI, and applied automatically on deployment. |
| Technology & Tools |
A standard migration framework is adopted across all services with consistent naming and sequencing conventions. |
| Measurement & Metrics |
Migration success and failure rates are tracked per environment, with failures triggering automated alerts. |
Level 4 – Quantitatively Managed
| Category |
Description |
| People & Culture |
Teams proactively design migrations using expand-contract patterns to achieve zero-downtime deployments. |
| Process & Governance |
Rollback scripts are mandatory for all migrations and are validated in lower environments before production. |
| Technology & Tools |
Schema drift detection runs continuously, alerting teams when environments diverge from the expected state. |
| Measurement & Metrics |
Migration execution time, rollback rate, and schema drift incidents are measured and reviewed at team level. |
Level 5 – Optimising
| Category |
Description |
| People & Culture |
Engineering teams share and refine migration patterns organisation-wide, elevating the collective capability. |
| Process & Governance |
Post-incident reviews of migration failures feed directly into improved tooling, patterns, and guardrails. |
| Technology & Tools |
Migration tooling is integrated with feature flags and deployment orchestration to enable safe, staged rollouts. |
| Measurement & Metrics |
Aggregated migration data informs architectural decisions, database platform choices, and CoE guidance. |
Key Measures
- Percentage of schema changes applied via automated migration tooling rather than manual intervention
- Percentage of migrations with a tested and validated rollback script present in version control
- Number of production incidents attributed to database migration failures or schema drift per quarter
- Mean time to detect and remediate schema drift between non-production and production environments
- Percentage of deployments achieving zero downtime despite including schema changes
- Lead time from migration script creation to successful application in production as part of a pipeline