It is Thursday afternoon and the change manager is reviewing a change on a database cluster. The proposed date looks fine. What nobody notices is that an update to the storage underneath the same cluster is scheduled for that very night, that the affected application only has a maintenance window on Sunday mornings, and that month-end closing is running, a period when production should not be touched at all. All of this is written down somewhere. Just not in one place.
Anyone who has run operations knows how this ends: an early phone call, an anxious service owner, and a team explaining why two changes collided instead of doing the work they had planned. This is rarely about carelessness. It is about the rules for touching production not being visible enough to the people who plan changes.
Why spreadsheets and goodwill are not enough
We often see maintenance windows recorded in contracts or service documentation, freezes announced by email, and collisions caught by an experienced colleague who “knows what's going on where”. That works as long as change volume is low and that colleague is not on holiday.
The weak spots are predictable:
- the maintenance window belongs to the service, but the change is planned on a server, so someone has to trace the link by hand,
- a freeze is announced but never enforced,
- two changes on shared infrastructure are found to collide only when someone checks the calendar, if at all,
- large changes across many items are executed in one go, because a gradual rollout is hard to plan.
How to approach it
The core idea is simple: rules should be data, not tribal knowledge. A maintenance window belongs to a service and must be traceable from every item the service depends on. A freeze is a period in which the system will not accept a change date at all. Collisions should be evaluated during planning, not spotted by eye.
It is equally important to admit that not every situation fits strict rules. When a new process is being introduced, or in an organisation that has never defined maintenance windows, a deliberate and traceable exception is better than rules everyone works around.
How Eywo Stratum handles it
In Eywo Stratum, a change is linked to CMDB items and, through the dependency map, to the services that run on them. Before a change is submitted for approval, the system calculates its impact: which services and applications will be down or degraded.
Scheduling rules build on that calculation:
- maintenance windows – a change can only be scheduled within the windows of the affected services,
- change freezes – a change cannot be scheduled during a freeze,
- collisions – the system flags other changes that overlap in time and scope,
- rolling execution – a change can be carried out item by item, so a redundant service does not have to go down as a whole.
Every change appears in the change calendar, where the change manager and service owners can see what is coming and when. The owner of the affected service approves the outage, and depending on the change model, so do the change manager or the CAB. Standard pre-approved changes move quickly; normal and emergency changes have their own steps and lead time.
For the rollout period, Eywo Stratum offers a “change without a maintenance window” model. This lets an organisation start recording and approving changes before every service has a defined window. The exception stays visible and traceable, and once the windows exist, teams switch to the standard models.
Calm instead of improvisation
Maintenance windows and freezes are not bureaucracy. They are agreements between operations and the people who rely on a service. When the system enforces them, the change manager can focus on the substance of a change rather than searching calendars, and engineers start their night shift knowing nobody else is working on the same infrastructure. Everyone gets to go home with a clearer head.
Maintenance windows, freezes, collision checks and the change calendar are included in the Standard edition.
Eywo Stratum Standard
For organisations that want a reliable CMDB and managed ITSM processes.