Jira change management template

A Jira change management template is a reusable structure for handling a change from request to review, capturing the change summary, its type, the risk and impact, the implementation and rollback plans, the approval, and the post-implementation review. It maps the ITIL-style stages (request, assess, approve, implement, review) onto a Jira issue and its sub-tasks, so every change follows the same controlled path. To use it, build the change structure once, save it as a template, and launch the whole tree in a click with the details prompted as variables. Copy the fields below by hand, or import them in seconds.

What a change management template captures

A change that skips a step is how outages happen: a deploy with no rollback plan, a change nobody approved, an impact nobody assessed. A change management template removes that risk by making the controlled path the default. Every change carries the same fields, in the same order, so assessment and approval are built in rather than remembered.

Field	What it is for
Change summary	What is changing and why, in one line
Change type	Standard, normal, or emergency, which sets how much process applies
Risk and impact	What could go wrong, who and what is affected, the blast radius
Affected systems	The services, environments and teams in scope
Implementation plan	The ordered steps to make the change
Rollback plan	How to reverse it if the change fails
Approver / CAB	Who signs off, and the change advisory board where one is required
Schedule	The planned window, and any freeze periods to respect
Post-implementation review	What happened, whether it succeeded, and lessons for next time

The two fields teams most often omit are the rollback plan and the post-implementation review, and they are exactly the two a template guarantees. That is the point: the structure carries the discipline so the person raising the change does not have to.

Change as a hierarchy

The strongest way to run a change in Jira is as a parent change issue with a sub-task for each stage, because a change is a process, not a single ticket. The parent holds the summary, type and schedule; the sub-tasks carry assessment, approval, implementation and review, each with its own owner and status. You can see at a glance which stage a change is in and who is holding it up.

Parent: Change <<summary>> (type: normal)
  - Sub-task: Assess risk and impact
  - Sub-task: Document implementation plan
  - Sub-task: Document rollback plan
  - Sub-task: Obtain CAB / approver sign-off
  - Sub-task: Implement in the scheduled window
  - Sub-task: Verify and monitor
  - Sub-task: Post-implementation review

This hierarchy is what a template does best: the parent and all its sub-tasks are saved together and recreated as one tree on launch, with the links intact, so approval is a real tracked step rather than a checkbox someone ticks from memory. Variables fill in the change summary, the affected systems and the scheduled window at launch, and a value entered once flows to every sub-task that needs it.

A filled example: a normal change

Parent: Change CHG-031: Upgrade the payments service to v3 (type: normal)
  Risk and impact: Medium. Affects checkout for all web users during the window.
  Affected systems: payments-api, checkout-web, staging + production
  Schedule: Sun 02:00-04:00 UTC; respects the end-of-month freeze
  - Assess risk and impact (owner: platform lead)
  - Document implementation plan (owner: payments team)
  - Document rollback plan: redeploy v2 image, restore config (owner: payments team)
  - Obtain CAB sign-off (owner: change manager)
  - Implement in the window (owner: on-call)
  - Verify and monitor for 2h (owner: on-call)
  - Post-implementation review (owner: change manager)

Standard, normal, and emergency changes

Not every change needs the full path, and the template adapts by type. A standard change is low-risk and pre-approved, so it can skip the CAB step and run on a lighter sub-task set. A normal change is the default: full assessment, approval and review, as above. An emergency change is raised in response to an incident and is approved fast, often after the fact, with the review step made mandatory so the shortcut is documented. Keeping one template per type, or one template with the type as a variable, means the right level of process is applied without anyone deciding it on the spot.

For changes that come out of an incident, link the change to the originating incident report so the trail from incident to fix to change is intact. Standard IT changes that arrive as requests pair with the IT support template. For the broader practice around assessing, scheduling and reviewing changes, see our guide to change management best practices.

Make it repeatable

With Process Templates for Jira, you save the whole change tree once and launch it per change, with the type, affected systems and window prompted as variables. Jira Automation can raise a standard change on a schedule, and the parent-child links and approval sub-task come back every time, so the controlled path is never skipped under pressure. Data is hosted in the EU (Frankfurt) under GDPR, which matters when change records are part of your compliance evidence. It is free for up to 10 users, needs no admin rights, and requires no scripting. The how-to guide covers the setup.

How to create a reusable Jira change management template

1. Install Process Templates for Jira from the Atlassian Marketplace. It is free for up to 10 users and needs no admin rights.
2. Build the change as a parent issue with sub-tasks for each stage from assessment to review, then save it as a template from the issue menu. See creating issue templates for the walkthrough.
3. Turn the parts that change into variables like the change type, affected systems and scheduled window, using template variables, so the person raising the change fills only the blanks.
4. Launch the whole change tree from the template with creating issues from templates, so the parent, its sub-tasks and the approval step come back as one linked tree. Keep the corrective work linked back to the change, and let automation raise standard changes on a schedule.

Frequently asked questions

How do I manage change requests in Jira? Model each change as a parent issue with sub-tasks for assessment, approval, implementation and review, and save that structure as a reusable template so every change follows the same path. Variables capture the summary, affected systems and schedule at launch, and the approval step stays a tracked sub-task rather than an informal sign-off.

What is the difference between a standard, normal, and emergency change? A standard change is low-risk and pre-approved, so it skips the change advisory board. A normal change goes through full assessment, approval and review. An emergency change is raised in response to an incident and approved quickly, with a mandatory review afterwards to document the shortcut. A template per type keeps the right level of process applied.

How do I handle change approvals in Jira? Make approval an explicit sub-task with its own owner and status, so a change cannot move to implementation until the approval sub-task is done. Templating the change tree means the approval step is always present, and you can route it to the change advisory board where one is required.

Related templates

Pair the change management template with the rest of your service workflow: the incident report template for the outages that trigger emergency changes, and the IT support request template for the standard changes that arrive as requests. Or browse the full template library for matching formats across software, ITSM and support work.