Two teams schedule maintenance for the same server on the same weekend. A network change breaks an application that nobody flagged as dependent. A patch rollout overlaps with a scheduled database migration. These collisions happen because changes are planned in isolation — each team sees their own change but not everyone else’s.
GLPI’s change management module addresses this with two features: the change calendar and impact tracking through linked assets.
The change calendar
Every change in GLPI has a planned start date and end date. The change calendar displays all scheduled changes on a timeline view, making overlaps immediately visible. If two changes target the same maintenance window, you see it before either one starts.
The calendar is filterable by:
- Entity — see changes for one division or all divisions
- Status — approved changes only, or include pending approvals
- Category — infrastructure changes, application changes, network changes
- Priority — separate view for high-risk changes vs. routine ones
For organizations with a regular Change Advisory Board meeting, the calendar filtered to "pending approval" is the CAB agenda — no separate document needed.
Impact analysis through linked assets
GLPI lets you link assets to a change record. A server migration change should list every server, switch, and application instance affected. When you do this consistently, two things become possible:
Collision detection
If Change A affects Server SRV-05 and Change B also affects SRV-05, and both are scheduled for the same week — that’s a collision. You can find it by checking which assets appear in multiple active changes. GLPI doesn’t automate this warning (yet), but a simple database query or report surfaces it. Defining clear risk-based approval tiers helps here too — most collisions happen with routine work that could have been pre-approved as standard changes.
Incident correlation
When an incident occurs and the user reports "the application is down," the first question is: "Did anything change?" If all changes have linked assets, you can search for recent changes that touched the affected server or application. Instead of asking around ("Did anyone change anything?"), you check the change log.
Maintenance windows
Many organizations define recurring maintenance windows — Saturday 02:00-06:00 for infrastructure, Wednesday 22:00-01:00 for application deployments. GLPI doesn’t have a built-in maintenance window concept, but you can achieve it with:
- Change templates — pre-filled change forms with the standard window dates, risk assessment, and communication plan
- Calendar filtering — check whether your planned change falls within an approved window
- SLA calendar exclusions — configure the SLA clock to pause during planned maintenance so controlled downtime doesn’t count as a breach
For organizations that need conditional approval routing tied to maintenance windows — approve automatically if within the standard window, escalate to CAB otherwise — Cascade handles that branching logic.
Freezes and blackout periods
Release freezes — periods where no changes are allowed (typically around holidays, quarter-end, or major events) — are managed by process, not by GLPI configuration. But you can support them by:
- Setting a business rule that blocks change approval during freeze dates
- Adding a freeze notice to the change form template
- Filtering the calendar to show any changes scheduled during the blackout and flagging them for rescheduling
Emergency changes during freeze periods are a special case — they bypass the blackout by definition but need enhanced documentation and mandatory post-implementation review. See our guide to emergency changes and PIR in GLPI.
The change calendar is most valuable in organizations where multiple teams share infrastructure. The more teams submit changes independently, the more important it is that everyone sees the same timeline.