Enterprise Change Management for Technology

Enterprise change management exists because a single misconfigured firewall rule can take down an entire organization. The challenge is protecting production stability without creating a bureaucracy that takes two weeks to approve a one-line config change. Modern change management automates what can be automated and reserves human review for genuinely risky changes.

---

Change Classification

Type	Risk	Approval	Example
Standard	Low, pre-approved	Automated	Deploy tested code via CI/CD
Normal	Medium, needs review	Team lead or change board	Database schema change
Emergency	High, during incident	Post-implementation review	Hotfix during outage
Major	High, broad impact	Change Advisory Board (CAB)	Infrastructure migration

---

Risk Assessment

change_risk_matrix:
  factors:
    blast_radius:
      low: "Single service, < 100 users affected"
      medium: "Multiple services, < 1000 users"
      high: "Platform-wide, all users"
    
    reversibility:
      low: "Not reversible (data migration)"
      medium: "Reversible with effort (schema change)"  
      high: "Easily reversible (feature flag, rollback)"
    
    testing:
      low: "No automated tests"
      medium: "Unit + integration tests"
      high: "Full CI/CD with E2E + staging validation"
    
    change_frequency:
      low: "First time this type of change"
      medium: "Done before with issues"
      high: "Routine, well-documented standard change"
  
  scoring:
    low_risk: "Auto-approve, deploy via CI/CD"
    medium_risk: "Peer review, deploy during business hours"
    high_risk: "CAB review, maintenance window, rollback plan"

---

Progressive Rollout

1% → 5% → 25% → 50% → 100%

Each stage:
├── Deploy to percentage of users/instances
├── Monitor metrics for 10 minutes
├── Compare error rate to baseline
├── If metrics healthy → proceed to next stage
└── If metrics degraded → auto-rollback to previous version

---

Anti-Patterns

Anti-Pattern	Problem	Fix
CAB for every change	Weeks of delay, developers circumvent process	Classify changes, auto-approve standard changes
No testing = manual review	Human review can’t catch bugs at scale	Invest in automated testing, reduce manual gates
Change freezes (months long)	Backlog of changes deployed all at once = high risk	Continuous delivery with smaller, safer changes
No rollback plan	Change fails, can’t undo	Every change must have documented rollback
Friday deploys (no YOLO)	No support staff if things break	Deploy early in the week, never before holidays

---

Checklist

• Changes classified by risk level (standard, normal, emergency, major)
• Standard changes auto-approved via CI/CD
• Risk assessment for all non-standard changes
• Rollback plan documented for every change
• Maintenance windows for high-risk changes
• Progressive rollout for production deployments
• Post-implementation review for emergency changes
• Change metrics: frequency, lead time, failure rate

---

:::note[Source] This guide is derived from operational intelligence at Garnet Grid Consulting. For change management consulting, visit garnetgrid.com. :::