Unclear change impact puts cloud services at risk
A software company with 3,100 employees runs more than 250 cloud services, and around 230 changes a day cause outages.
- Technology
- IT-Service-Management
Key metric
Unplanned service outages after changes
4022/month
Unplanned service outages after changes per month
At a glance
Starting point
A software company with 3,100 employees runs more than 250 cloud services across several platforms. Around 230 changes are logged in the ITSM system every working day, ranging from small configuration tweaks to larger platform updates. About 40 percent of these changes affect central platform components used by several product teams. Documentation of the dependencies is scattered across the CMDB, wikis and architecture diagrams. Service owners and platform teams spend several hours a day identifying the services affected by planned changes and estimating the risks.
- 250+
- Cloud services
- 230/day
- Changes in ITSM
The challenge
The change processes are formally established, but assessing the impact in practice remains tedious. For each of the roughly 230 daily changes, platform teams and service owners have to check which services, pipelines and integrations are affected. Dependencies are often only partly maintained in the CMDB, and further clues sit in tickets, runbooks or architecture diagrams. As a result, risks are underestimated, the wrong maintenance windows are chosen or affected teams are informed too late. Unplanned service interruptions and rollbacks after changes cost time, cause night shifts and undermine trust in the change process.
Typical symptoms in the company
Why this remained unsolved
The problem had been known for a long time but was accepted as an unavoidable complexity of cloud operations. A complete and always up-to-date CMDB seemed unrealistic, and manual impact analyses were considered necessary effort. Classic automation failed because dependencies are described in free-text tickets, wikis and diagrams. A dedicated CMDB modernization project was postponed for lack of resources. So the effort in the change advisory boards stayed high, while unplanned service interruptions were accepted as an operational risk.
Our solution
An agentic workflow now supports the impact analysis of changes across several systems. For every new or modified change record, the workflow automatically gathers context from ITSM tickets, the CMDB, monitoring, wikis and architecture diagrams. Generative AI analyzes this information, identifies affected services, typical failure patterns and relevant runbooks, and produces a structured impact report. The report is attached to the change in the ITSM system, flags critical services, suggests communication paths and points to known risks. Before the CAB, platform teams and service owners get a consistent basis for decisions and can plan maintenance windows, tests and escalation paths in a targeted way.
Where generative AI comes in
Generative AI reads change descriptions, historical tickets, runbooks and architecture texts, summarizes dependencies in clear impact reports and suggests affected services and communication paths. It combines unstructured text, different writing styles and partly outdated documentation, and flags uncertainties transparently.
- Automated gathering of context from the ITSM system, CMDB, monitoring, wikis and architecture diagrams for every new or modified change
- Generative analysis of the change description, history and dependencies to identify affected services, pipelines and integrations, with an impact report
- Integration of the impact report into the ITSM system, highlighting critical services, suggesting communication and linking relevant runbooks
- Feedback loop for platform teams and service owners to review suggestions and gradually improve the quality of the impact analyses
How the impact workflow runs
Gather context
When a change is created or modified, the workflow automatically gathers context from ITSM, the CMDB, monitoring, wikis and architecture diagrams.
Analyze impact
Generative AI analyzes descriptions, history and dependencies, identifies affected services and known risks, and structures the results.
Deliver the report
The impact report is stored on the ITSM change, flags critical services, links runbooks and suggests communication paths.
Collect feedback
Platform teams and service owners review the report, add notes and mark corrections that feed into future analyses.
Evaluate metrics
Regular evaluations of rollbacks, outages and processing times show how the workflow affects the change process.
Measured: after six months in production
Period: after six months in production.
| Metric | Value | Basis |
|---|---|---|
| Unplanned service outages after changesKey metric | Down by around 45 percent | System measurementmeasured |
| Time spent on impact analysis per change | Reduced from 25 to 12 minutes | Time tracking before/afterestimated |
| Corrections needed in impact reportsQuality measure | Around 20 percent of reports need corrections | Samplemeasured |
Cost-effectiveness
The solution depends heavily on the quality of the existing documentation. In areas with outdated CMDB entries or missing runbooks, impact analyses remain uncertain and still require manual review by experienced platform teams.
Integration and operations
Transferability
The agentic workflow for change impact analysis can be transferred to other environments where many changes come with scattered dependencies. Wherever changes are documented in a ticketing system, dependencies are described in free-text or semi-structured sources and several teams are affected, generative AI can prepare impact reports. Clear governance matters: which changes are analyzed automatically, and how feedback flows into improving the suggestions.
A similar case in your organization? Let’s talk.
Briefly describe your process. We’ll get back to you with an initial assessment of whether the pattern can be transferred, and what it realistically takes.