on April 12, 2016
I learned to do Change Management from some really smart people. When I first became a DBA, I worked at a small software company where changes were released with increasing frequency over the years. Our team was really great at planning and deploying changes, because we constantly worked at improving.
Good Change Management makes your team smarter. When you change things a lot, things are going to break sometimes. If you’ve done a good change request, you’ll know exactly what to do when something breaks: either you’ll roll the change back, or have a Plan B to execute on. Good change requests also mean that business owners understand the risks of the changes and have approved them, and that teammates have reviewed them: good changes aren’t done in isolation.
Change Management isn’t just for IT. If you’re a developer who deploys changes to production, you need this as well.
Here’s a sample basic change request template. If you don’t have Change Management yet, start here.
Change Request Template for SQL Servers
Change Description
- What is the change?
- What’s the benefit of the change?
Change Planning: Who and When?
- Change Planned Date and Time:
- Who will roll out the change:
- Is this a recurring change, or a one time change?
Change Risk Assessment
- What SQL Servers and databases are impacted?
- Which applications use these databases?
- Describe estimated downtime required by the change and applications impacted:
- What is the worst thing that could happen if the change fails midway, or doesn’t have the intended result?
Change Execution and Rollback
- Steps to do the change:
- Change verification:
- Steps to roll back the change if needed:
Change PreRequisites - Submit the change only if the following are complete (or note why they can’t be done)
- Change deployment tested in pre-production with stated steps
- Change rollback tested in pre-production with stated steps
Change Reviewer Signoff
- Reviewed by:
- Review date:
Change Approver Signoff
- Approved by:
- Approval date:
Change Request Q&A
Doesn’t filling out that information take a long time? Only when it’s worth it. Outlining a complex change takes time, but you need to do that for a complex change – don’t wing it in production. If assessing the risk of a change is time consuming, that means you have a huge problem and need to document dependencies in your environment.
Why do I need a change reviewer AND a change approver? The change reviewer is typically a peer. They are looking at your plan and trying to help you think if you’ve missed anything technically, or perhaps they know of an easier way to do it. The change approver should be a management or stakeholder in the business who is primarily assessing the risk of the change and the impact of any downtime.
What if I’m the only SQL Server DBA or Developer? Who reviews my change then? The same person who would have to take care of the SQL Server if you had an emergency or won the lottery. If there is no such person, you need to identify one, for the sake of your employer.
What if we wouldn’t roll the change back? In that case, explain why you wouldn’t roll back, and what your Plan B is if something goes wrong. If there is no Plan B, change approvers need to be aware of that.
What if I’m the only person who wants to do Change Management? Just start doing it for your changes. Nobody ever got fired for asking for change approval. Usually they get rewarded if they do change management consistently – others will see the value.