If you have ever gotten an email saying systems will be unavailable Tuesday from nine to eleven at night, you have seen a change window. Most owners read that, think “fine, whatever,” and move on. Which is the right response. But it is worth knowing what happens behind that email, because the difference between a company that handles maintenance well and one that does not shows up in how many surprise Monday mornings you get.
The short version: changing a working system carries risk, and change management exists to shrink that risk and contain it when something goes sideways. None of it is complicated. Predictable things at predictable times, telling people in advance, and a plan to undo what you just did. Small businesses skip these steps constantly, because it feels like overhead until the one time it is not.
What a Change Window Actually Is
A change window is an agreed block of time when technical work is allowed and a brief disruption is acceptable. That is the whole concept. A scheduled appointment for risk.
Why evenings and midweek? If something breaks, you want the fewest people affected and the most hours to fix it before anyone needs the system. Tuesday and Wednesday nights are the sweet spot: far enough from the weekend that everyone is available, far enough from Monday that you are not fighting the week’s opening rush.
Tuesday has an industry reason too. Microsoft’s documentation on the Windows update release cycle states that the monthly security update release is published on the second Tuesday of each month, typically at 10:00 AM Pacific Time. That is the release most of the industry calls Patch Tuesday, and once a large share of business software takes its cue from that date, everyone’s maintenance rhythm follows.
Telling people in advance is part of the window, not a courtesy. Keep the notice short.
- When, in plain time. Tuesday, nine to eleven at night. Not “during the standard maintenance window.”
- What will be unavailable. Email, the file server, the phone system. Name what people use, not the product name on the invoice.
- What to do if you are working late. Save your work and sign out before nine. That sentence prevents most of the damage.
- Who to call if something is wrong the next morning. A name and a number. People will not report a problem if they do not know where to report it.
- Nothing else. No version numbers, no vendor names. Nobody reads past the second line.
Routine Patching Versus a Real Change
These get lumped together and should not be. Routine patching is the monthly security update rolling out to workstations. Boring, high volume, low individual risk. A real change is structural: moving a server, replacing a firewall, upgrading a line of business application, altering how people sign in. Different risk, different ceremony.
NIST’s guide to enterprise patch management, published in 2022, names the tension honestly: “Deploying patches more quickly reduces the window of opportunity for attackers but increases the risk of operational disruption because of the lack of testing.” No setting eliminates that tradeoff. You decide where you sit on it deliberately instead of by accident.
The same NIST guidance recommends phased deployment, where a small subset of assets gets a patch first. That is the most useful idea here for a small business. Pick a handful of machines, including one belonging to someone who will actually tell you if something is off. Wait a few days. Then everyone else. Microsoft supports this pattern directly, describing optional nonsecurity preview releases, typically issued on the fourth Tuesday of the month, as a chance for administrators to validate content ahead of the following month’s security update.
Have the Undo Ready Before You Start
The rule we hold ourselves to: do not begin a change until you can describe out loud how you would reverse it. Not “we could probably restore from backup.” Specifically how, and roughly how long.
- Write down the current state first. Settings, versions, configurations. If you cannot describe where you started, you cannot return there.
- Take a verified snapshot immediately before. Not last night’s. Right before, and confirm it completed rather than assuming.
- Decide in advance what “this failed” looks like. Agree on the symptom that triggers a rollback before you are tired and invested.
- Set a hard stop. If the window ends at eleven, the decision to roll back happens at ten, not at midnight. Fatigue makes bad calls.
- Change one meaningful thing at a time. Three changes in one night means you will not know which caused the problem.
Which brings us to the Friday afternoon change, the most reliable self inflicted wound in this business. It is tempting because the office is emptying out, so disruption seems cheap. But if the problem takes a few hours to surface, you find out Saturday, from a customer, with a skeleton crew and vendors closed until Monday. Do not let anyone talk you into a quick one at four on a Friday.
Emergency Changes Are a Different Animal
Sometimes waiting for Tuesday is the wrong answer. A vulnerability under active exploitation, failing hardware, an outage in progress. The NIST patch management guidance covers this, describing emergencies as running on a highly accelerated schedule while still recommending a brief test on a small set of assets first, sometimes only minutes ahead of the wider rollout.
The useful principle: an emergency compresses the timeline, it does not delete the steps. You still know what you are changing, you still have a way back, you still tell people. You do it in twenty minutes instead of a week.
Define ahead of time what qualifies and who can declare one. If everything is an emergency, you have no change process, only improvisation. The honest test is whether the risk of waiting exceeds the risk of rushing. That is a real question with a real answer, and it is usually no.
Keep a Log So Later Is Not Archaeology
The least glamorous item, and the one that pays off most. Every change gets a line in a shared document: the date, what changed, who did it, and whether anything unexpected happened. Four fields, in a spreadsheet.
The reason is simple. Six weeks from now, printing will break for one department, and the only question that matters will be “what changed?” Without a log, answering that means interviewing people about their memories of a Tuesday night. That is archaeology. With a log it takes ninety seconds. The gap between a fifteen minute fix and a two day investigation is the same argument we make about why saving time beats saving money: the cheap thing to skip is rarely the cheap thing overall.
One more benefit. A thorough log makes it obvious when a vendor changed something you did not know about.
The Bottom Line
Maintenance happens Tuesday night because that is when a mistake costs the least, and because much of the industry’s update calendar keys off the second Tuesday of the month. Everything else is discipline: separate routine patching from real changes, roll out to a few machines first, tell people in plain language beforehand, know your rollback before you start, never go on a Friday afternoon, and write down what you did. As the NIST guidance puts it, problems are inevitable, so be prepared for them.
None of that requires a big IT department. It requires deciding once and then being boring about it. If your updates happen whenever somebody gets around to them, or you have no record of what changed and when, that is fixable and cheap. It pairs with knowing what happens when a service you depend on goes down, since planned and unplanned downtime need the same preparation. We handle maintenance scheduling for small and mid-sized businesses across Denton County and would be glad to talk through a sane rhythm for yours. Contact us today
Sources:
Comments are closed