IT Operations
AI Change & Update Management
Firmware, OS and configuration changes planned, approved and applied with a snapshot first.
Available now · Human approval · Complete audit trail
The operational problem
An available update is not yet a safe change
Firmware, operating-system and configuration changes interact across management controllers, hosts, networks, storage and workloads. Installing the newest version without ordering dependencies can create an outage that the update itself never predicted.
The service starts with inventory and evidence. It turns versions and vendor guidance into a staged plan with risk classes, approval points, rollback prerequisites and an explicit verification step after every change.
Change control
What a safe change plan has to contain
Installed state
Current versions, relevant configuration and the time and source of each reading.
Dependencies
The order in which management, firmware, operating systems and dependent services can safely move.
Risk class
Read-only, mutating and destructive steps are separated so the right approval rule applies.
Rollback point
Snapshot, backup or documented reversal is attached to the step before execution is considered.
Verification
A successful command is not enough; service state and agreed health checks must pass afterwards.
Method
How inventory becomes an approved change plan
- Read the current inventoryThe assessment collects installed versions and configuration through read-only operations.
- Resolve dependenciesComponents are grouped into change waves in the order required by the environment and vendor guidance.
- Classify every operationEach step receives a risk class, expected impact, approval rule and maintenance-window requirement.
- Attach rollback and verificationThe plan names the recovery point and the checks that prove the service returned healthy.
- Approve before executionThe exact change plan is reviewed; destructive operations require two approvers.
Example output
One change record, with rollback visible
Illustrative change-plan record — no customer infrastructure data
- Scope
- 5 servers, 12 components
- Order
- Management controller, BIOS, NIC
- Window
- Sat 02:00, 4 h
- Rollback
- Snapshot per host
- Second approver
- Required
Operational judgement
The rules behind a controlled change
Inventory before recommendation
A vendor advisory is relevant only after the affected version and dependency are confirmed.
Rollback must be usable
A snapshot or backup counts only when its scope, timing and restore path match the planned change.
Approve the plan, not a summary
Reviewers see the ordered operations, target, window, rollback and checks they are authorising.
Verify the service outcome
Completion means the agreed health checks passed, not merely that an installer returned success.
Fixed start
What the one-week inventory and plan delivers
- Version inventoryA source-backed view of the selected systems and components included in the assessment.
- Ordered change wavesUpdates grouped by dependency, risk and a realistic maintenance sequence.
- Approval and rollback matrixThe required approver, recovery point and stop condition for each class of change.
- Verification checklistNamed checks that decide whether each change passed, failed or must be rolled back.
- No unapproved executionThe fixed start produces the inventory and plan. Applying it is separately scheduled and approved.
Fit
When this service is—and is not—the right starting point
A good fit
- Versions and configuration are spread across several infrastructure layers.
- Updates are postponed because dependencies and rollback responsibilities are unclear.
- Your team wants an auditable plan before a maintenance window is approved.
Not the right fit
- The request is to apply changes immediately without inventory or a rollback point.
- Nobody owns the maintenance window or can approve service impact.
- The target systems provide neither supported read access nor reliable version evidence.
Where the human approves
Two approvers for destructive changes. The AI works through a fixed list of allowed operations; every approval and result is logged.
Change-management questions
Questions an infrastructure owner should ask
Does the one-week start include applying updates?
No. It produces the inventory and controlled change plan. Execution requires a separately approved window, exact operations and rollback readiness.
Why are changes grouped into waves?
Infrastructure components depend on one another. Waves make the order, blast radius and verification point explicit before the next group is touched.
What requires two approvers?
Operations classified as destructive require a second approver. The classification and named approvers are part of the plan.
Is a snapshot always enough for rollback?
No. The recovery method must match the component and failure mode. The plan states what can be restored, how and within which operating window.
How is a change marked successful?
The installation result and the agreed post-change health checks must both pass. Otherwise the plan stops or follows its rollback path.
Experience behind the service
Built from infrastructure change work
The method is based on TechOne operational work across firmware, operating systems, configuration, virtualization and dependent infrastructure. Customer names, hostnames, locations and vendor-specific management details remain private.
Technical stewardship: David Máj, Founder & Technology Consultant. Last reviewed 24 September 2026.