An IT manager sizing a new ticketing system reads the feature matrix and the question lands fast: does GLPI's Change module actually handle real change management, or do we end up back in spreadsheets and email threads? The honest answer is "it depends on what you mean by real" — and the dependency is narrower than the vendors selling you ServiceNow would like you to believe.
What follows is what the Change module does out of the box, where it stops being enough, and an adoption order that works even if your team has never filed an RFC before.
What the Change module covers natively
GLPI ships with a dedicated Change object — separate from Incidents, Problems, and Requests — that moves through New, Evaluation, Approval, Testing, Implementation, and Review before closing. Each phase transition is timestamped and attributed to the user who performed it, so the audit trail writes itself rather than being assembled in Teams six months later. Impact, risk, and rollback plans live in structured fields on the form, not as free-text memos buried in a wiki.
The part that makes this meaningfully better than a SharePoint spreadsheet is the native linking. A Change can reference the Incidents that triggered it ("we're upgrading the VPN concentrator because of 47 incidents last month"), the Problem it addresses, and the specific Assets it touches (servers SRV-01 through SRV-08, switch SW-CORE-01). When an incident fires six weeks later, you query "what changed on this asset recently" and get an answer — not a best guess from whoever was on the call. The change calendar makes this even more useful: all scheduled changes on a timeline, collisions visible before either one starts.
Standard, normal, emergency — and why the distinction matters
ITIL names three change classes and GLPI supports all of them as configurable categories:
- Standard changes — pre-approved, low-risk, routine. Monthly Windows patches on non-critical servers, documented service restarts, cert rotations. These skip the approval phase entirely.
- Normal changes — the full lifecycle. A database migration to a new server. These get the CAB, or a single approver if the scale doesn't warrant a committee.
- Emergency changes — one approver instead of a full CAB, implemented immediately, reviewed retrospectively. A critical security patch for an actively exploited vulnerability. For the full emergency workflow — including how to enforce post-implementation review — see our guide to emergency changes and PIR in GLPI.
Most teams we see land a clear majority of their changes in the Standard bucket once they define a few categories — which is the point. The lifecycle exists for the ones that matter, not for every server reboot.
Where stock GLPI approval stops being enough
Single-level approval works. Multi-level approval in a linear chain works. Where native GLPI runs out of room is conditional and parallel approval — the shape most larger organizations eventually need: "if the change affects production and is classified medium-risk, route to the security architect and the database lead in parallel, then to the CAB only if either vetoes." That's not a Change module feature. That's a workflow engine.
We built Cascade for this shape of problem because the alternative — a custom plugin commissioned per client — breaks every GLPI major upgrade and returns as another rebuild every two years. Cascade handles conditional branching, parallel approvers, and task chains, and it's maintained centrally in one codebase across GLPI versions rather than reappearing as a separate rebuild per client.
How to actually adopt it
The gap between "we don't do change management" and "we have a CAB" is where most teams fail — they try to install the CAB first and the team rebels within two months. A working adoption order:
- Require an RFC for anything that touches production. Just the form, with impact and rollback fields filled in. No approval chain yet. The goal is documentation, not control. Three weeks of this and you'll have real data on what kinds of changes you actually make.
- Introduce Standard categories next. Pre-approve the obvious routine stuff — patches, cert rotations, documented restarts. This removes friction before you add any.
- Add single-approver approval for Normal changes. The team lead or service owner. One approver, one field, one email. For a detailed walkthrough of designing these tiers — low, medium, and high-risk — see our approval workflow design guide.
- Add a CAB only if scale demands it. Below roughly 50 changes a month, a formal CAB is often more overhead than value. Above that, you need a coordination body — and that's when Cascade's parallel-approval routing starts earning its keep.
When to pick something else
GLPI's Change module is right for organizations that want structured change management without vendor lock-in and without a ServiceNow licensing bill. It is not the right choice if your compliance framework requires out-of-the-box audited workflows with signed artifacts for SOC 2, HIPAA, or equivalent — that's ServiceNow or BMC territory, and you'll spend more building to those standards in GLPI than you'd save on licensing. For frameworks where GLPI does deliver — ISO 27001 and NIS2 change documentation — see our guide to GLPI change management for audit compliance.
For the rest of mid-size IT — helpdesk plus ops plus a dozen approvers — GLPI covers more ground than most teams realize, and with Cascade on top it handles the approval complexity that otherwise pushes organizations toward a seven-figure replacement.
Change management in GLPI doesn't have to be slow. It has to be deliberate. The difference between "we planned this" and "we'll figure it out" shows up at 2 AM when something breaks.