Guide for identifying new change models (the manual way) - existing clients

[JuliaAllenSN]

Hey team, 

The most common question I get from legacy users is 'how do I know what new models I can create'. So, I wanted to share a general guide to give everyone a baseline to start from. 

Don't forget to sign up and join us at the clinics. Later in July we will be actually setting up models and flow with policies.  => Sign up for the clinic here

Change Models Framework: How to Identify & Build

Change Models are a modern way to automate change intake and governance. Use this framework to identify and build the right models for your organization. This approach enables standardization, reduces approval cycles, and increases automation based on change type and risk profile.

Discovery Phase: Identify Model Candidates

Answer these questions to determine which change types warrant their own model:

1. Frequency: Does this change type occur ≥ 20 times per year?
2. Consistency: Do 80%+ of these changes follow a similar approval/execution pattern?
3. Risk: Do changes in this category have a consistent risk profile (e.g., all low-risk)?
4. Stakeholders: Are the same approvers/teams involved for every change in this type?
5. Automation Potential: Can tasks, notifications, or field population be automated?

If you answer yes to ≥ 3 questions, this is a candidate for a dedicated Change Model.

Six Industry-Standard Change Models

These represent the most common change types. Adapt them to your specific needs:

Standard Infrastructure Change

Server patching, OS updates, firmware upgrades on pre-approved schedules, hardware replacements.

Risk: Low

Approvals: Auto-approve

CAB: No

Volume: 50–100/month

Application & Software Release

Software releases, version updates, configuration changes to production applications.

Risk: Medium

Approvals: App Owner + Tech Lead

CAB: For critical services

Volume: 20–40/month

Database Production Change

Schema changes, index optimization, data migrations, configuration tuning.

Risk: High

Approvals: DBA + Owner

CAB: Always

Volume: 5–15/month

Network & Security Change

Firewall rules, network config, VPN updates, security policies, access controls.

Risk: High

Approvals: Network + Security Owner

CAB: Always

Volume: 10–20/month

Access Management Change

Permission grants/revokes, group membership, role assignments for non-admin users.

Risk: Low

Approvals: Manager approval

CAB: No

Volume: 100+/month

Emergency/Hotfix Change

Critical production incidents requiring immediate change. Post-incident review mandatory.

Risk: High (mitigated by PIR)

Approvals: Incident Lead

CAB: Post-implementation review

Volume: 5–10/month

Building a Change Model: 5 Steps

Step 1: Define Model Metadata

• Model name
• Description & use cases
• Applies to (CIs, services, teams)
• Risk level (Low/Medium/High)

Step 2: Define Required Fields (Model-Driven)

• Affected Service
• Change Type
• Implementation Plan (template-driven)
• Backout Plan (mandatory for medium/high risk)
• Testing Plan
• Impact Description
• Implementation Window

Step 3: Define Approval Path

• Low-risk: Auto-approve (no CAB needed)
• Medium-risk: Manager + Tech Lead approval
• High-risk: CAB review mandatory
• Define SLAs for each step

Step 4: Define Automation & Tasks

• Auto-create tasks for Deployment, Validation, Backout, PIR
• Auto-notify stakeholders
• Auto-populate fields from CMDB
• Auto-suggest implementation window

Step 5: Pilot & Refine

• Select 10–15 historical changes
• Re-create using the new model
• Gather feedback from users
• Adjust field visibility & approval flow
• Go live with full migration

Pro tip: Build models 1–3 first (2–4 weeks). Then launch models 4–6 (weeks 5–8). Don't aim for perfect—iterate based on real user feedback. Your first version is rarely your final version.