A Simple Upgrade — Or Is It?
On a Monday morning, Sarah from Shipping & Receiving sent Marcus an email: "The label software is out of date. Vendor says the new version has better address validation. Can you update it today?"
Marcus had been IT manager at RetailMax for three years. He'd seen what happened when someone installed "a simple update" without going through process. One time, a patch had silently changed a database connection string and knocked out the accounting system for six hours during quarter-end close. The CFO had not forgotten.
"I need to open a change request," Marcus replied. "It won't take long — but we have to do this right."
Sarah groaned. "But it's just a label printer upgrade."
"That's what they all say," Marcus typed back.
Filling Out the Form
Marcus opened the change management portal and began filling out the Change Control Request form. The form required him to document:
- Purpose: Upgrade ShipLabel Pro from v3.1 to v4.2 for improved address validation and vendor support
- Scope: 14 workstations in the Shipping & Receiving department plus 2 print servers
- Scheduled date/time: Saturday, 2:00 AM – 5:00 AM
- Affected systems: ShipLabel Pro, Print Server 1 and 2, and the shipping database integration layer
- Risk assessment: Medium — upgrade is straightforward but the DB integration layer has dependencies
The form also required him to identify the owner and the stakeholders. This is where things got interesting.
Who Owns This? Who Is Affected?
"The owner," Marcus explained to his junior analyst Dana, "is the department that needs the change. Sarah's team owns this change request. They manage the process and they'll be the ones testing it at the end. I'm just the technician who actually does the install."
"Got it — ownership doesn't mean doing the work."
"Exactly. Now, stakeholders — who else is impacted?" Marcus pulled up the system diagram. "Shipping obviously. But who uses the shipping data?"
They traced the dependencies:
- Accounting — pulls daily shipping reports from the label software database
- Logistics — uses delivery timeframes from shipment records
- Customer Service — uses tracking data that originates from label printing
- CEO dashboard — pulls revenue recognition data that depends on confirmed shipments
"A label printer upgrade," Dana said slowly, "touches the CEO dashboard."
"Now you understand why we have a process."
What Could Go Wrong?
For the impact analysis, Marcus rated the change Medium risk and documented the specific risks:
- The upgrade might not work — v4.2 could have installation issues on the older workstations
- The DB integration layer might break — the new version uses a different API format
- If print servers go down during peak hours, order fulfillment stops
- Data corruption was possible if the database schema changed between versions
But then Marcus added the most important section: risks of NOT making the change.
- The vendor would stop supporting v3.1 in 90 days
- A known address validation bug in v3.1 was causing roughly 2% of labels to have incorrect postal codes
- Continuing to run unsupported software would create a security vulnerability
"The risk of doing nothing is also a risk," Marcus reminded Dana. "Change management isn't about avoiding all change. It's about making change safely."
Test Before You Touch Production
Marcus set up a sandbox environment: a VM cloned from the production shipping workstation, connected to a copy of the shipping database. Completely isolated — no connection to real production systems. A technological safe space.
He installed ShipLabel Pro v4.2 in the sandbox. It installed cleanly. He tested address validation. He ran a batch of 200 test labels. He tested the DB integration API. Then he confirmed the backout plan worked — could he uninstall v4.2 and restore v3.1? Yes, with the backup in place.
"One thing the sandbox can't fully replicate," he noted in his documentation, "is 14 workstations all printing simultaneously during peak hours. Some edge cases will only appear in production."
Plan for Failure
Marcus wrote the backout plan carefully. If anything went wrong during the maintenance window:
- Stop all ShipLabel Pro services
- Restore the v3.1 installer from the backup share
- Restore the DB integration configuration from the pre-change snapshot
- Restore the full database backup (taken 30 minutes before the upgrade begins)
- Verify label printing with a test batch of 10 labels
- Notify stakeholders that change was rolled back
"Always have backups," he said to Dana. "Always have good backups. And always test your backout plan in the sandbox before you need it in production."
The Change Control Board
The Change Control Board reviewed Marcus's request on Wednesday. They had one question: "Why Saturday at 2 AM? We have weekend warehouse operations until midnight."
Marcus had already considered this. "The main label printing rush ends at 10 PM. I'm scheduling 2 AM to give a buffer. Three-hour window — should be done by 5 AM before the Sunday morning shift."
The CCB approved. Sarah, as the owner, signed off. The stakeholders — accounting, logistics, customer service — were notified via the standard change calendar.
Marcus noted that during the holiday season — Thanksgiving through New Year — RetailMax had a complete change freeze. Nothing could be modified. He was glad this came in October.
Saturday Night, 2:00 AM
The upgrade went smoothly for the first 12 workstations. Then workstation 13 threw an error — the old DB integration DLL was locked by a background process that hadn't stopped cleanly. Marcus followed the documented procedure for that scenario (it was in the backout plan as a contingency), stopped the process manually, and continued. By 4:15 AM, all 14 workstations and both print servers were running v4.2.
At 4:30 AM, Sarah printed 50 test labels. All correct. At 4:45 AM, Marcus updated the documentation — new version numbers, new API configuration, updated system diagram. He sent the post-change notification to all stakeholders.
At 5:00 AM, he locked the change request as complete.