Contents
Database change management is the practice of putting rules around everything that happens to a database, from the moment a change is requested to the moment it is executed and recorded. The definition sounds simple, the practice rarely is. In most organizations this is not a system but a bundle of habits: the script arrives by email, the approval stays in a thread, execution depends on one person's night shift and the record lives only in memory.
Definition: The Common Misunderstanding
The most common misunderstanding is treating database change management as schema delivery. Schema delivery moves tables and procedures consistently between environments. Change management answers a different set of questions: who asked for this change, why was it needed, who reviewed and approved it, what was the risk, was it tested, was there a rollback plan, who executed it, what was the result and who can prove all of this today.
An organization can solve schema delivery perfectly and still answer none of those questions. The two complement each other, but one does not replace the other.
What is in scope?
All three statement families are in scope. DDL changes structure (tables, indexes, procedures). DML changes data (insert, update, delete). DCL changes privileges (grant, revoke, users). Most organizations govern only DDL, yet auditors ask most often about DML and DCL records.
The Eight Steps of the Process
1. Request
A change begins as a record: who is asking, for which system, with which business justification and on which environment. The only goal of this step is to turn a conversation into a record. A change without a request number effectively never happened six months later.
2. Automatic validation
The script is parsed as it is saved and evaluated against the organization's standards. Typical findings include UPDATE or DELETE without a WHERE clause, use of TRUNCATE, touching critical tables, naming convention violations and irreversible structural changes. The important property of this step is that it runs before human review. The machine should look first so people are not spent on what a rule can catch.
3. Risk classification
Not every change carries the same risk. Adding an index and running a bulk update on a production table should not follow the same path. Risk classification decides the depth of approval. The critical point is that classification must follow the worst case: the highest tier triggered decides, and minor warnings must never offset a critical finding.
4. Approval
Approval steps should follow risk. A low risk change may need a single approval while a change touching a critical table may require database and security approval together. Who approved and when must be recorded, and whether the requester can approve their own request must be an explicit rule.
5. Trial on a validation environment
Discovering on production that a script actually runs is an expensive way to learn. A run and roll back approach tries the script on a real environment and undoes its effect. This step is especially valuable for long running updates, where unexpected locking shows up in advance.
6. Rollback plan
A change without a rollback plan is an accepted risk. The plan can be a restore from backup, but a restore takes hours rather than minutes. A rollback script containing the counter operations is usually the only realistic option, and it should be produced together with the change and stay part of the request.
7. Execution
Execution should run from the approved record. There must be no difference between the text that was approved and the text that ran; this is the point that breaks most often in an audit. If a maintenance window is needed, execution should be scheduled so that waking up at night stops being a requirement.
8. Record and evidence
The last step is the most neglected. The result, affected objects, duration, any error message and the executor must be recorded. If the record can be altered afterwards its evidentiary value drops, which is why integrity protection is expected in serious organizations.
Roles and Responsibilities
| Role | Responsibility | Typical failure |
|---|---|---|
| Developer | Writes the script, explains the reason and the impact | Assuming it is fine because it ran locally |
| Database manager | Technical review, performance impact, execution | Taking on everything and becoming the bottleneck |
| Approving manager | Accepts the business justification and the risk | Approving without reading the content |
| Security and compliance | Reviews personal data and privilege changes | Joining the process too late |
Four Maturity Levels
Read the four levels below to find where your organization sits today. Most organizations believe they are at level two while they are at level one.
- Level 1: Verbal. The script arrives by chat, approval is given verbally and there is no record. The answer to "who did this" depends on memory.
- Level 2: Correspondence. Requests live in email or a ticket system, but the script text and the approval sit in different places. Gathering evidence means searching archives.
- Level 3: Central record. Request, script, approval and result live in the same record, but controls still rely on human attention and rule violations are not caught automatically.
- Level 4: Policy driven. Rules are defined in the system, violations are caught automatically, approval depth follows risk, rollback is generated and evidence is produced at the moment of the action.
Five Common Mistakes
1. Building the process only for DDL. Auditors ask most about DML and privilege changes. When data fix scripts are excluded, the riskiest operations stay unrecorded.
2. Tying approval to one person. When that person goes on leave the process stalls and the team invents informal paths. Define backup approvers.
3. Never defining an emergency path. Urgent intervention will be needed sooner or later. Without a defined exception the team bypasses the process entirely. The right approach is not to forbid the exception but to record it.
4. Leaving test environments out of scope. Real customer data on a test environment is common. An environment left out of scope becomes the weakest link for personal data.
5. Trying to gather evidence during audit season. Evidence cannot be assembled afterwards, it has to be produced at the time of the action. Collecting screenshots during an audit is both expensive and weak as evidence.
Implementation Checklist
Tick the items below for your own organization. If you can tick fewer than six, your governance gap will find you before the auditor does.
- Every change has a request number
- The script text matches the approved record and cannot be changed afterwards
- Rule violations are caught automatically before human review
- Approval depth varies with risk
- The requester cannot approve their own request
- Every change has its rollback plan in the record
- DML and privilege changes are also in scope
- The emergency path is defined and recorded when used
- The integrity of the audit record can be verified
- All evidence for a request can be exported in one action
Frequently Asked Questions
Are database change management and a schema migration tool the same thing?
They are not. A migration tool carries the change to the target and keeps versions consistent; it solves the technical delivery problem. Change management deals with the decision itself: why the change is needed, what its risk is, who approves it, whether a rollback plan exists and whether the decision can be proven. The two layers do not replace each other, they sit on top of each other.
Does a small team need all eight steps?
All the steps are needed, but each step does not need a separate person. In a small team one person can carry several roles; what matters is not being both the requester and the approver on the same item. Instead of cutting the number of steps, it is healthier to let low risk work pass some steps automatically.
How do we measure our maturity level?
The most practical measure is this: when two different people assess the same change, do they reach the same conclusion? If they do, the process has become independent of individuals. The second measure is evidence: for any change from last month, can you answer who requested it, who approved it and what actually ran, within minutes?
Apply the checklist in your own environment
SQL Change Guard runs these eight steps in one model across SQL Server, PostgreSQL and Oracle. See it in a 30 minute demo.
Book a Demo →