By Brian Fitzgerald
Every autumn, Charlie Brown takes a running start at the football. Every autumn, Lucy pulls it away at the last second, and he lands flat on his back.
Year-end database changes can feel the same way. We prepare a change, line up the window, and take our run at it. Then, at the last minute, the change is postponed. A question nobody answered, a concern nobody addressed, or a feeling that now is not the right time is enough to stop it. Once a change slips into November, the holidays and the freezes often carry it into next year.
This year, let’s keep our footing. The idea is simple: prepare your changes carefully, answer the concerns before anyone raises them, and finish them by the end of October.
Why October
October is unique. It is the last month when a postponed change can still be recovered. If a change scheduled in early October slips a week or two, it still happens this year. If a change slips out of October, it usually does not. November and December bring year-end processing, change freezes, and vacations, and the people you would call for help may not be at their desks.
That makes October a sweet spot with a sharp edge. Early in the month, a postponement costs a couple of weeks. Late in the month, a postponement costs the year.
So plan for two dates: a primary date in early October and an alternate date later in the month. Get both approved at the same time. Then a postponement simply moves the change to a date everyone has already agreed to, instead of starting the approval process over.
Prepare diligently
A well-prepared change is a quiet change. In an earlier post on change control, I listed what a production change needs. It is worth revisiting each autumn:
- Written implementation steps.
- Written validation steps.
- Written backout steps.
- Proof that those steps were tested beforehand.
- A risk analysis.
- Written approval.
Each set of steps should name who will do the work, exactly what they will do, and when.
Preparation takes time, and that is the point. Testing in a non-production environment shows you the surprises while they are still cheap. A written backout plan lets you step back with confidence instead of improvising. A clear risk analysis helps your approver make a real decision, because an approver is someone who can also say no.
None of this needs to be heavy. It needs to be done, and done before the window opens.
Head off the cancellation
Preparing the technical work is only half the job. The other half is making sure the change is not cancelled at the last minute.
Most cancellations are not hostile. They come from people who are responsible for the system and need to feel confident before they say yes. When that confidence is missing on the day of the change, postponing feels like the safe choice. Our job is to supply that confidence early.
The questions are predictable. Have your answers written down before anyone asks:
| The question | Be ready with |
|---|---|
| Has this been tested? | Test results from a non-production environment, with dates. |
| What if it goes wrong? | Tested backout steps and how long backout takes. |
| How will we know it worked? | Validation steps and who confirms success. |
| What is the risk? | A short risk analysis: what could fail, how likely, how bad, and how you reduce it. |
| Who else is affected? | The applications and teams that depend on the system, and confirmation that they know. |
| Why now? Can it wait? | What waiting costs: freeze periods, support dates, and work that slips into next year. |
| Who will be there? | Named people for implementation, validation, and backout, and who is reachable. |
| Is this the right window? | The window checked against the business calendar and other scheduled changes. |
| Is it approved? | Written approval from someone who could also have said no. |
A few habits help these answers land:
- Share the plan early. Send it to stakeholders weeks ahead and invite questions. A question asked in early October is a gift; the same question asked an hour before the window is a cancellation.
- Walk through it together. A short review meeting surfaces concerns while there is still time to address them.
- Agree on go/no-go criteria in advance. If everyone knows what must be true to proceed, the decision on the day is a checklist, not a debate.
- Keep the answers in the change record. When a new person joins the conversation late, the answers are already there.
- Have the alternate date approved. If the first date slips, the change moves to a date already agreed on, still in October.
Finish by October
Working backward from the end of October helps. Look at the changes you still hope to make this year, and ask which ones can be prepared, tested, approved, and completed in the next few weeks.
Those are your changes for this year. Schedule them for early October, with an approved alternate date later in the month, while calendars are still open and colleagues are still available to review your plans.
The rest can wait for January. That is not a failure. A change that is moved to a calmer season, with good preparation behind it, is a sound decision. A change that is rushed into a crowded December is the football Lucy is holding.
A calmer year-end
Charlie Brown keeps running at that football because he is an optimist, and optimism is a fine quality in a DBA. Let’s pair it with a little planning.
Write the steps. Test them. Plan the backout. Answer the questions before they are asked. Get the approval. Then finish the work while October is still here. When the holidays arrive, you can enjoy them, knowing your systems are steady and your changes are behind you.