The change that breaks something is rarely the big migration. It is the quick firewall rule on a Tuesday afternoon, the switch reboot that took a phone system with it, the update applied because it was there. Nobody planned it, nobody announced it, and the client found out from their staff.
Change management does not need a committee. It needs a short record before the change, a window the client already agreed to, and a message before and after. This post covers the process that small and mid-size environments will actually follow.
Classify changes so most of them are easy
Three classes cover nearly everything. Standard changes are routine, low-risk and pre-approved: adding a user, a printer, a mailbox rule, a patch inside the agreed ring policy. They need a ticket but no approval. Normal changes affect a shared system or carry real risk: firewall rules, server configuration, DNS, anything that needs a reboot in business hours. They need a short change record and an approval. Emergency changes fix an active outage; they happen first and get documented immediately after.
The classification is what keeps the process light. If every user add needs sign-off, technicians route around the process. If firewall changes need nothing, the process is not protecting anything.
- Standard: pre-approved, ticket only, listed by name so nobody has to guess
- Normal: change record, approval from the client's named approver, scheduled in a window
- Emergency: act, then record within the day, and review at the next weekly sync
- Keep the standard list current; promote a change to standard once it has gone well several times
The change record: five questions
A change record is not a form with thirty fields. It answers five questions: what is changing, why, what could go wrong and how you will undo it, when it will happen and how long it takes, and how you will know it worked. If a technician cannot answer the rollback question, the change is not ready.
Write the record in the ticket so it lives with the history. Link the runbook if there is one. For anything touching a server, the rollback answer is usually a snapshot or a backup checkpoint taken just before; name it in the record so the person doing the rollback at midnight can find it.
- What: the specific systems and the exact change
- Why: the ticket, the risk, or the project that requires it
- Risk and rollback: what breaks if it goes wrong and the step-by-step undo
- When: the window, the expected duration, and the point of no return
- Verification: the test that proves success, run by a real user where possible
Checkpoint-VM -Name 'APP01' -SnapshotName "pre-change-$(Get-Date -Format yyyyMMdd-HHmm)"Maintenance windows the client agreed to before you needed them
Negotiate the windows once, at onboarding or the quarterly review, and write them into the agreement. A weekly workstation window for reboots, a monthly server window for patching, and a rule for how much notice a one-off window needs. When the windows exist in advance, scheduling a change is a matter of picking the next one, not asking permission each time.
Learn the client's calendar. Payroll day, month-end close, the trade show, the week the auditors are in. A window that falls on month-end is a window the client will veto, and rightly. Keep a list of blackout dates per client and check it before scheduling anything.
- Weekly workstation window for reboots, outside active hours
- Monthly server window with a stated start, duration and reboot order
- Notice period for one-off windows, and who on the client side can approve a shorter one
- Blackout dates: month-end, payroll, events, audits
- Emergency exception: what you will do without a window and how you will tell them
Communication before, during and after
Clients accept downtime they were told about and resent downtime they discovered. Send a short notice before every normal change: what, when, expected impact, who to contact. Send it to the person who agreed the window and to whoever will hear from staff, usually the office manager. For anything visible to all users, a one-line banner or email to everyone is worth the effort.
After the change, close the loop: it is done, it worked, here is what to expect, or it was rolled back and here is the next step. Keep the after message honest. A rolled-back change reported plainly builds more trust than a silent retry next week.
- Before: notice to the approver and the office contact with what, when, impact and contact
- During: a status update if the window runs long or the impact is bigger than expected
- After: confirmation of success or rollback, sent the same day
- Weekly: a summary of changes made and scheduled, in the sync or by email
- Quarterly: review the windows and blackout dates and adjust
Frequently asked questions
Who approves normal changes on the client side?
One named person with a named backup, agreed at onboarding. Usually the owner, the office manager, or the internal IT contact. Approval by email or in the ticket is enough; the point is that someone at the client knew.
What if the client never responds to change requests?
Agree a rule that silence after a set number of business days on a normal change means approval, and write it into the agreement. Emergency changes never wait on approval.
How do we handle a change that has to happen in business hours?
Say so in the notice, explain why it cannot wait for a window, state the expected impact and duration, and get the approver's explicit yes. Then do it at the least busy time you can find and tell staff when it is over.
Takeaway
Classify changes so the routine ones are easy, answer five questions before every normal change, agree the windows and blackout dates in advance, and send a note before and after. The process fits on one page, and the client stops hearing about changes from their staff.