Change management for support teams

A Friday-evening firmware update went to a fleet of forty laptops to fix a flaky Wi-Fi driver. By Monday the Wi-Fi worked on thirty-seven of them, and three would not start at all: the firmware changed while the drive was still protected, the encryption no longer trusted the boot path, and each machine stopped at a recovery prompt asking for a key nobody had to hand. None of that was bad luck. One paragraph in a change request would have caught it: suspend the encryption first, try it on a few machines, and keep a way back.

This lesson turns that paragraph into a habit. You will sort a change into one of three kinds and say who authorises each, write a change request with the fields that stop surprises, pick a window that respects a published freeze, and close a change only once the user has accepted it and the systems have stayed healthy.

The kind of change decides who authorises it

Not every change needs the same care, so change management sorts each one into a kind first. A standard changestandard change: A pre-authorised, low-risk, repeatable change that follows a template permitted once, so a support team can run it without returning to the change-advisory board each time. is pre-authorised, low-risk and repeatable: it follows a template that has been permitted once, so the desk just runs it. A normal changenormal change: A change new or risky enough to need assessment, so it goes to a change-advisory board that weighs its risk and clears it before a scheduled window. is new or risky enough to need assessment, so it goes to a change-advisory boardchange-advisory board: The group that assesses a normal change, weighs its risk against its benefit, and authorises or declines it before it runs. that weighs the risk and clears it. An emergency changeemergency change: A change that fixes an urgent problem which cannot wait for the normal path, so it gets fast authorisation and its full documentation afterwards rather than before. fixes an urgent problem that cannot wait for that path, so it gets fast authorisation and its full documentation afterwards rather than before.

Getting the kind right decides everything that follows: how fast it can move, who has to agree, and how much evidence you gather up front. This table is the one to keep in your head:

The mistake that causes outages is treating a normal change as if it were standard: skipping the assessment because the work “feels routine”. The opposite mistake wastes a night: forcing an emergency fix through the full board while a floor of users sits offline. The kind is a judgement about risk and urgency, and it is the first thing a change request records.

A change request records the risk and the way back

A change requestchange request: The record that carries a change from idea to close, stating its purpose, scope, risk, test evidence, steps, rollback plan, people, window, authorisations and how success will be verified. is the record that carries a change from idea to close. CompTIA’s A+ V15 objective 4.2 lists the fields it should hold, and they fall into two groups: planning the change, and running then closing it. Walk through them once and the shape sticks.

The first group describes and assesses the change. The purpose says why it is needed. The scope names the users it affects and the affected systems say what it touches, so a reader sees how far it reaches. The risk level, low, medium or high, sets how much care it needs, and the test evidence is proof it worked on a sandbox or a pilot before the real systems. A change with no evidence is a guess.

The second group is about doing it safely. The implementation planimplementation plan: The ordered steps that make a change happen, written so the work can be followed in order and repeated if needed. is the ordered steps to make the change, and the rollback planrollback plan: The recorded way to return a system to its previous working state if a change fails; a change without one should not run. is how to undo it if it fails. A change without a rollback plan should not run, because it leaves you with no way back when something breaks. Then come the responsible people, the scheduled window, the authorisations the change carries, and the verification plan: how you will confirm success afterwards, in something a user can see.

A standard change fills this record once, as a template, and reuses it. A normal change fills it fresh and hands it to the board. Either way, the fields are the same, and the empty ones are exactly where the risk hides.

Three Windows safety measures give every change a way back

On Windows fleets, three safety measures turn a risky change into a reversible one, and the opening disaster skipped the first. Before firmware or driver work on an encrypted machine, suspend the drive encryption so the changed boot path does not lock the user out. The command is Suspend-BitLocker, and its -RebootCount controls how long the pause lasts: Microsoft’s documentation says that if you do not set it, the value is one, so protection resumes after the next restart, while a value of 0 suspends it until you run Resume-BitLocker. For a quick firmware update that reboots once, the default is usually what you want.

The second measure stages the rollout instead of pushing it everywhere at once. Microsoft’s guidance on deployment plans describes a common shape of three rings: preview for the IT staff, limited for pilot and validation, and broad for everyone else. The limited ring is your pilot ringpilot ring: A small group of machines that receive an update first, so a problem shows on a few recoverable devices before the broad rollout to everyone else.: a few devices chosen to represent the fleet’s hardware and applications, and the broad ring follows only once the pilot has had a long enough spell of stable running. A bad change then surfaces on a handful of recoverable machines rather than across the whole fleet. The updates, patches and drivers lesson goes deeper into staged rollouts and build-number checks.

The third measure is the oldest: before a risky configuration change, take a restore point or a full disk image, so “undo” is a restore rather than a rebuild. These settings, and when to change them, are the subject of the Windows security settings lesson. Together the three give every Windows change a way back, which is the same thing the rollback plan field asks for. Read the table by its last column: each measure is a different way back.

Only an emergency change may run inside a freeze

A change needs a time as well as a plan. A maintenance windowmaintenance window: An agreed period, often an evening or a weekend, when a change may run with the least disruption to users. is an agreed slot, often an evening or a weekend, when a change may run with least disruption. A change freezechange freeze: A published period, such as quarter-end, exams or a big launch, when no non-emergency change may run because the business cannot afford the risk. is the opposite: a published period when no non-emergency change may run, because the business cannot afford the risk. Freezes cluster around quarter-end, exams, festivals and big launches for your organisation, and the rule that makes them work is simple: publish them in advance, and let only an emergency change run inside one.

The linter from a change request can enforce this. This program checks three recorded requests against a published freeze calendar: it looks for the required fields, checks the window sits outside every freeze, and makes sure an emergency carries its after-the-fact note.

# Check a recorded change request the way a change-advisory board would read it:
# are the required fields present, is the scheduled window clear of every published
# freeze, and does an emergency carry its after-the-fact documentation note? The
# requests and the freeze calendar live in the code, so there is no network call and
# the run is the same every time. validate_change does the checking; the rest prints
# a short report for three requests.

# The fields CompTIA's A+ objective 4.2 lists for a change request.
REQUIRED_FIELDS = [
    "purpose",
    "scope",
    "affected_systems",
    "risk_level",
    "test_evidence",
    "implementation_steps",
    "rollback_plan",
    "responsible_people",
    "scheduled_window",
    "authorisations",
    "verification_plan",
]


def _overlaps(window, freeze):
    """True when the scheduled window's date touches a freeze's date range."""
    day = window["start"][:10]
    return freeze["start"] <= day <= freeze["end"]


def validate_change(request, calendar):
    """Return (ok, problems) for one change request against a freeze calendar."""
    problems = []
    for field in REQUIRED_FIELDS:
        if not request.get(field):
            problems.append(f"missing {field}")
    window = request.get("scheduled_window")
    kind = request.get("kind")
    if window:
        inside = [f["name"] for f in calendar if _overlaps(window, f)]
        if inside and kind != "emergency":
            problems.append(f"window falls inside freeze: {inside[0]}")
    if kind == "emergency" and not request.get("post_change_note"):
        problems.append("missing post_change_note")
    return (not problems, problems)


# A published freeze calendar: a week of exams and the quarter-end week.
CALENDAR = [
    {"name": "exam fortnight", "start": "2026-03-16", "end": "2026-03-27"},
    {"name": "quarter-end freeze", "start": "2026-04-01", "end": "2026-04-05"},
]

REQUESTS = [
    {
        "id": "CHG-201 (standard)",
        "kind": "standard",
        "purpose": "Install the permitted finance app update",
        "scope": "Finance team laptops",
        "affected_systems": "12 managed laptops",
        "risk_level": "low",
        "test_evidence": "Passed on the pilot laptop",
        "implementation_steps": "Push via the management tool, verify version",
        "rollback_plan": "Remove the update and reinstall the previous version",
        "responsible_people": "Asha (desk), Ravi (apps)",
        "scheduled_window": {"start": "2026-04-09T19:00", "end": "2026-04-09T20:00"},
        "authorisations": "Pre-authorised standard change",
        "verification_plan": "Confirm the version and that the app opens",
    },
    {
        "id": "CHG-202 (emergency)",
        "kind": "emergency",
        "purpose": "Replace a failed switch to restore the second floor",
        "scope": "Second-floor network",
        "affected_systems": "One access switch, 40 users",
        "risk_level": "high",
        "test_evidence": "Spare switch tested on the bench",
        "implementation_steps": "Swap the switch, copy the saved config",
        "rollback_plan": "",
        "responsible_people": "Ravi (network on call)",
        "scheduled_window": {"start": "2026-04-02T02:30", "end": "2026-04-02T03:30"},
        "authorisations": "Fast authorisation by the on-call lead",
        "verification_plan": "Ping every port and confirm users are back",
        "post_change_note": "Write up the fix and raise a problem record",
    },
    {
        "id": "CHG-203 (normal)",
        "kind": "normal",
        "purpose": "Change the database schema for a new feature",
        "scope": "Shared application database",
        "affected_systems": "App server and database",
        "risk_level": "medium",
        "test_evidence": "Migration run on the staging copy",
        "implementation_steps": "Run the migration, then redeploy the app",
        "rollback_plan": "Restore the pre-change snapshot",
        "responsible_people": "Ravi (apps), Meera (database)",
        "scheduled_window": {"start": "2026-04-03T22:00", "end": "2026-04-03T23:30"},
        "authorisations": "Cleared by the change-advisory board",
        "verification_plan": "Smoke-test the feature and watch error rates",
    },
]

print("Published freeze calendar:")
for freeze in CALENDAR:
    print(f"  {freeze['name']}: {freeze['start']} to {freeze['end']}")
print()

for request in REQUESTS:
    ok, problems = validate_change(request, CALENDAR)
    verdict = "PASS" if ok else "FAIL"
    window = request["scheduled_window"]["start"].replace("T", " ")
    print(f"{request['id']}: {verdict}  (window {window})")
    for problem in problems:
        print(f"    - {problem}")

Published freeze calendar:
  exam fortnight: 2026-03-16 to 2026-03-27
  quarter-end freeze: 2026-04-01 to 2026-04-05

CHG-201 (standard): PASS  (window 2026-04-09 19:00)
CHG-202 (emergency): FAIL  (window 2026-04-02 02:30)
    - missing rollback_plan
CHG-203 (normal): FAIL  (window 2026-04-03 22:00)
    - window falls inside freeze: quarter-end freeze

The standard request CHG-201 passes: every field is filled and its window, 2026-04-09, is clear of both freezes. The emergency CHG-202 fails for one reason, missing rollback_plan, even though it runs at 02:30 inside the quarter-end week, because an emergency is allowed to run during a freeze. The normal request CHG-203 is rejected with window falls inside freeze: quarter-end freeze, because it is scheduled for 2026-04-03, inside the published 2026-04-01 to 2026-04-05 freeze. The fix is not to force it through but to move it.

So the next question is when the window can move to. A second program reads the same calendar and, for each proposed window, finds the first open day after it:

# Read a published change-freeze calendar and test three proposed change windows
# against it: does each fall inside a freeze, and if so, when is the next open day?
# Everything is in the code, with fixed India Standard Time offsets, so there is no
# network call and the run is the same every time.

from datetime import date, datetime, timedelta, timezone

IST = timezone(timedelta(hours=5, minutes=30))

# A published freeze calendar: a pre-exam window and the quarter-end week.
FREEZES = [
    {"name": "pre-exam window", "start": date(2026, 3, 16), "end": date(2026, 3, 27)},
    {"name": "quarter-end freeze", "start": date(2026, 4, 1), "end": date(2026, 4, 5)},
]

# Three proposed change windows, each a start time in IST.
WINDOWS = [
    datetime(2026, 3, 20, 21, 0, tzinfo=IST),
    datetime(2026, 4, 3, 22, 0, tzinfo=IST),
    datetime(2026, 4, 9, 19, 0, tzinfo=IST),
]


def freeze_for(day, freezes):
    """Return the freeze that covers this day, or None when the day is open."""
    for freeze in freezes:
        if freeze["start"] <= day <= freeze["end"]:
            return freeze
    return None


def next_open_day(day, freezes):
    """Walk forward from this day to the first day no freeze covers."""
    while freeze_for(day, freezes) is not None:
        day = day + timedelta(days=1)
    return day


print("Published freezes:")
for freeze in FREEZES:
    print(f"  {freeze['name']}: {freeze['start']} to {freeze['end']}")
print()

for window in WINDOWS:
    day = window.date()
    stamp = window.strftime("%Y-%m-%d %H:%M %z")
    freeze = freeze_for(day, FREEZES)
    if freeze is None:
        print(f"{stamp}: open, the window may run")
    else:
        opens = next_open_day(day, FREEZES)
        print(f"{stamp}: inside {freeze['name']}; next open day is {opens}")

Published freezes:
  pre-exam window: 2026-03-16 to 2026-03-27
  quarter-end freeze: 2026-04-01 to 2026-04-05

2026-03-20 21:00 +0530: inside pre-exam window; next open day is 2026-03-28
2026-04-03 22:00 +0530: inside quarter-end freeze; next open day is 2026-04-06
2026-04-09 19:00 +0530: open, the window may run

A window on 2026-03-20 falls inside the pre-exam freeze, so the earliest open day is 2026-03-28; a window on 2026-04-03 falls inside the quarter-end freeze, so it moves to 2026-04-06; and a window on 2026-04-09 is already open, so it may run. Converting a window’s time across the zones a fleet sits in is exactly what the timestamp converter tool is for.

Close a change only after the user accepts it

A change is not done when the work finishes; it is done when it is confirmed and recorded. Close a change only after user acceptanceuser acceptance: Confirmation from the person affected that a change works as intended, part of what must happen before a change is closed., where the person who feels the change agrees it works, and after a spell of monitoring to be sure nothing broke quietly. The verification plan you wrote earlier is what you check against: the feature opens, the numbers look right, the error rate stays flat.

When verification fails, the change has caused a fault, so you roll back using the plan you prepared, and the failure becomes an incident. That incident feeds problem management, which looks for the root causeroot cause: The condition that makes a fault happen. Fixing it stops the fault from coming back, while fixing only a symptom, or working around it, leaves the cause in place. More in “A troubleshooting method that holds under pressure” before anyone tries the change again; an emergency fix often arrives through an escalationescalation: Moving a ticket to people with more skill or access (functional escalation) or with more authority (hierarchical escalation), together with the evidence of what has been tried so far. More in “IT support roles, tiers and channels” path for just this reason. A change that fails and is quietly left in place is how a one-off problem becomes a recurring one, which the incidents, problems and major incidents lesson treats in full.

Only after acceptance and quiet monitoring do you close the change, and you record what was done, how it was verified and who accepted it. That record is what makes the next similar change faster and safer, and it is why a closed change is worth more than a finished one.

Practise: find the first slot a change may use

The two programs above say whether a window is allowed and on which day a freeze ends. The exercise takes the next step: from a change’s kind, the earliest moment it could start, how long it runs, the desk’s weekly maintenance windows and the freeze calendar, return the first moment it may start. Its sample tests cover a change that waits for the next window, one that starts inside an open window, one too long for what is left of a window, one that ends exactly at a close, a freeze in the way, and an emergency, which starts at once. Then check yourself on the whole lesson.

"""Starter for first_slot: the first moment a change may start (see the task)."""

from datetime import datetime, time, timedelta

DAYS_AHEAD = 28


def in_freeze(day, freezes):
    """True when a freeze covers this date: the freeze test of the lesson's freeze-calendar program."""
    text = day.isoformat()
    return any(f["start"] <= text <= f["end"] for f in freezes)


def first_slot(kind, earliest, minutes, windows, freezes):
    """Return the first allowed start as "YYYY-MM-DDTHH:MM", or None."""
    # TODO: an emergency starts at earliest.
    # TODO: walk the DAYS_AHEAD days that start on earliest's date and skip a frozen day. Try that day's windows in
    #       order of their start: a change starts at the later of the window's open and earliest, and it fits when
    #       its start plus minutes is no later than the window's close.
    return None

"""Sample tests for first_slot(kind, earliest, minutes, windows, freezes)."""

from change_slot import first_slot

# Tuesday and Thursday evenings, and a Saturday morning.
WINDOWS = [
    {"weekday": 1, "start": "19:00", "end": "22:00"},
    {"weekday": 3, "start": "19:00", "end": "22:00"},
    {"weekday": 5, "start": "07:00", "end": "11:00"},
]
FREEZES = [{"name": "quarter-end freeze", "start": "2026-04-01", "end": "2026-04-05"}]


def test_a_change_waits_for_the_next_window():
    # Monday 6 April at 10:00: the next window is on Tuesday evening.
    assert first_slot("normal", "2026-04-06T10:00", 60, WINDOWS, FREEZES) == "2026-04-07T19:00"


def test_a_change_may_start_inside_an_open_window():
    assert first_slot("standard", "2026-04-07T20:15", 60, WINDOWS, FREEZES) == "2026-04-07T20:15"


def test_a_change_that_no_longer_fits_moves_on():
    # At 21:30, 30 minutes of the Tuesday window are left and the change needs 45.
    assert first_slot("standard", "2026-04-07T21:30", 45, WINDOWS, FREEZES) == "2026-04-09T19:00"


def test_a_change_may_end_exactly_at_the_close():
    assert first_slot("normal", "2026-04-07T21:00", 60, WINDOWS, FREEZES) == "2026-04-07T21:00"


def test_no_change_starts_inside_a_freeze():
    # 22:30 on Tuesday 31 March is after that window closes; Thursday 2 and Saturday 4 April are frozen.
    assert first_slot("normal", "2026-03-31T22:30", 30, WINDOWS, FREEZES) == "2026-04-07T19:00"


def test_an_emergency_starts_at_once_even_in_a_freeze():
    assert first_slot("emergency", "2026-04-02T02:30", 90, WINDOWS, FREEZES) == "2026-04-02T02:30"

Interview questions

Warm-up (fresher): Three changes land on your desk at 09:00: a pre-authorised monthly software update to the finance app; an emergency switch replacement to restore a floor; and a one-off database schema change for a new feature. Which is standard, which is emergency, which is normal, and what authorisation does each need?

The monthly finance-app update is a standard change: it is pre-authorised by its template, so the desk runs it in a maintenance window without going to the board. The switch replacement is an emergency change: a floor is offline, so it takes fast authorisation from the on-call lead now and its full documentation, including a problem record, straight afterwards. The database schema change is a normal change: it is new and risky, so it carries test evidence from a staging copy and a rollback plan to the change-advisory board, which weighs the risk and clears it for a window outside any freeze.

Two harder questions start where this lesson stops: one about putting a night-time emergency fix on record the next morning, and one about a security fix that arrives in the middle of a freeze. Decide your own first move for each, then compare it with how the model answer begins:

Key takeaways

• Sort every change into standard (pre-authorised and repeatable), normal (assessed and cleared by the board) or emergency (fast authorisation now, full documentation after), because the kind decides how it may move.
• A change request carries its purpose, scope, affected systems, risk, test evidence, implementation steps, rollback plan, responsible people, scheduled window, authorisations and verification plan; the empty fields are where the risk hides.
• On Windows, suspend BitLocker before firmware work (-RebootCount 1 resumes after the next restart), roll out in a pilot ring then a broad ring, and take a restore point or image before a risky configuration change.
• Publish maintenance windows and change freezes, and let only an emergency change run inside a freeze; move every other change to the next open window.
• Close a change only after the user accepts it and monitoring stays clean, record the result, and turn a failed change into an incident that feeds problem management.