Change Request

Create structured change requests with impact analysis, risk assessment, implementation plan, rollback procedures, and CAB preparation.

Workflow

Step 1: Classify

• Standard: Pre-approved, low-risk, repeatable. No CAB required.
• Normal: Requires impact analysis and CAB approval.
• Emergency: Active incident or critical vulnerability. Expedited approval, retrospective CAB.

Step 2: Define Scope and Impact

Document: what is changing and why, systems affected (primary and dependent), users affected, service impact (downtime/degradation), data impact (schema changes, migrations), and rollback complexity (simple/moderate/complex).

Step 3: Assess Risk

Evaluate likelihood of failure, impact of failure, and overall risk (LOW/MEDIUM/HIGH/CRITICAL). Document mitigations: testing coverage, canary deploys, feature flags, monitoring.

Step 4: Implementation Plan

• Pre-change: Backups, notifications, pre-checks.
• Steps: Ordered actions with estimated duration and owner.
• Validation: Smoke tests, monitoring checks after each step.
• Window: Date, time, duration, go/no-go deadline.

Step 5: Rollback Plan

• Trigger: Specific conditions (error rate >X%, latency >Y ms).
• Steps: Ordered reversal actions with duration estimates.
• Data: Whether rollback affects data created during the window.
• Owner: Who has authority to initiate rollback.

Output Format

## Change Request
**CR ID**: CR-[YYYY]-[NNNN] | **Type**: [Standard / Normal / Emergency]
**Title**: [Brief title] | **Risk**: [LOW / MEDIUM / HIGH / CRITICAL]

### Change Description
**What**: [Change] | **Why**: [Justification] | **Systems**: [Affected]

### Impact Analysis
| Dimension | Assessment |
|-----------|-----------|
| Users affected | [Who/how many] |
| Service impact | [Downtime/degradation] |
| Dependent systems | [Upstream/downstream] |

### Implementation Plan
**Window**: [Date, Time-Time] | **Duration**: [Est.]
| Step | Action | Duration | Owner | Validation |
|------|--------|----------|-------|------------|
| 1 | [Backup] | 15 min | [Name] | Confirmed |
| 2 | [Deploy] | 30 min | [Name] | Tests pass |

### Rollback Plan
**Trigger**: [Conditions] | **Duration**: [Est.] | **Owner**: [Name]
| Step | Action | Duration |
|------|--------|----------|
| 1 | [Revert] | 10 min |

### Approvals
- [ ] Technical review -- [ ] CAB approval -- [ ] Business sign-off

Examples

User: "Create a change request for the database migration to PostgreSQL 16" Action: Document scope, identify all connected applications, assess risk (medium), build migration plan with maintenance window, define rollback to snapshot restore.

User: "Emergency change -- patch the authentication service now" Action: Create emergency CR with expedited approval, document the vulnerability, define hotfix deployment and rollback, note retrospective CAB requirement.

Best Practices

• Every change must have a rollback plan. Documenting it forces you to verify rollback is possible.
• Specify rollback triggers in measurable terms, not subjective judgment.
• Schedule during low-traffic windows. Check for conflicting changes in the same window.
• Include validation steps after each implementation step, not just at the end.
• Communicate proactively: before, during, and after the change window.
• Link the CR to the incident, problem, or project that triggered it.