Runbook generator
On migration day it is not the data volume that decides, but the actions no one remembers. The runbook generator turns them into a concrete working template — from the same data as the assessment and the quote.
- A ready runbook from the real inventory
- Remaining-work list in nine categories
- Visible gaps instead of guessed numbers
- Read-only, no write access
- Evaluated against the Data Center original
- No interference with live operations
- Results documented transparently
The runbook generator reads eight endpoints read-only, classifies the state and renders a ready runbook for migration day — not an estimate, but the working template that is worked through step by step.
The real value is in the remaining-work list: everything that can be migrated neither natively nor with tools is set out in nine categories — from custom Groovy through scripted fields to non-native service-management fields. Where the data gives no reliable value, a visible placeholder stands instead of a guessed number. A runbook that is honestly incomplete is worth more on migration day than one that looks complete.
What a standard migration leaves open
After a standard migration
- Actions reconstructed from memory
- Unclear what stays manual
- Guessed numbers that pass as fact
- Runbook contradicts assessment and quote
With this tool Runbook generator
- A concrete working template, step by step
- Remaining-work list in nine categories
- Visible placeholders where values are missing
- Everything from one data source
How your runbook is built
Read-only, from the real inventory.
-
1
Read out
Eight endpoints are captured read-only.
Verified: No intervention in operations.
-
2
Classify
The state is classified: what runs natively, what works tool-assisted and what stays manual.
Verified: Remaining work sorted into nine categories.
-
3
Set out the remaining work
The manual rework is set out as its own runbook page, with visible placeholders where values are missing.
Verified: No guessed numbers.
-
4
Render the runbook
From the classified state the finished step-by-step guide for migration day is rendered.
Verified: Workable step by step.
What it does
A ready runbook
From eight endpoints captured read-only a concrete step-by-step guide for migration day is rendered.
Remaining-work list in nine categories
Everything that can be migrated neither natively nor with tools is classified: Groovy in conditions, validators and post functions, ScriptRunner logic, app-specific actions, scripted fields, behaviours, standalone scripts, app-managed fields and non-native service-management fields.
Visible gaps
Where the data gives no reliable value, a visible placeholder stands — not a guessed number that no one later recognises as a guess.
One data source for everything
The runbook is built from the same raw data as the assessment and the quote. That is why it fits the rest and does not contradict it.
Read-only
The generator captures read-only and changes nothing. It creates a working template, not an intervention in your systems.
Honest, not looking complete
A runbook that shows its gaps is worth more on the day than one that looks complete and is not.
Common questions before migrating
What is the runbook built from?
From eight endpoints of your instance captured read-only — the same raw data the assessment and the quote are built from. That is why the documents fit together.
What is the remaining-work list?
A list of what can be migrated neither natively nor with tools, classified into nine categories — from custom Groovy to non-native service-management fields.
Why visible placeholders instead of numbers?
Because a guessed number is no longer recognised as a guess later. A visible placeholder makes the gap honestly visible — on migration day that is worth more.
Does the generator change anything?
No. It works read-only and creates a working template. Writing happens only on migration day through the actual tools.
Safe and transparent
Reading separated from writing
Reads come from a read-only data layer; writes go through a single controlled channel. Read access never burdens your Cloud.
Evaluated read-only
Everything is evaluated read-only; nothing is written back into your systems. Operations and cloud budget stay untouched.
Repeatable without risk
Every step can be run again without doing harm. An interruption is no problem, and a second run creates no duplicates.
One isolated stack per customer
All tools run on the Jira Migration Manager platform, fully separated per engagement. No mixing of data.
All results are documented transparently and can be checked against the Data Center original. Nothing is silently changed or left out.
Runs on the Jira Migration Manager
This tool does not stand alone. It runs on the platform that unites every tool: a read-only read layer pulls Data Center and Cloud into a versioned snapshot, and every change goes through a single, controlled write gateway.
More on the Jira Migration ManagerMore tools
Migration platform
Jira Migration Manager
The platform that brings every migration tool under one roof and makes a Jira DC-to-Cloud migration safe and repeatable: separate read and write paths, rate-limited into the Cloud, credentials encrypted, one isolated stack per customer.
- Read-only read layer and rate-limited write channel kept strictly separate
- All tools on one shared data base, chainable into pipelines
- Token-secured perimeter, encrypted keystore, one stack per customer
Assets Migration
Asset Relink
Migrates Insight/Assets to the Cloud in full: fields and contexts, AQL filters, screens and the object values on every issue. Exactly where standard tools lose the links.
- Create fields, contexts and screens in the Cloud
- Translate AQL filters from Data Center to Cloud
- Relink object values on every issue
Managed Migration
Jira Migration Helper
JCMA migrates the bulk of your data but leaves configuration broken or unmigrated. Jira Migration Helper closes these gaps module by module and, with Managed Migration, runs the right fixes for each finished project automatically — every one dry-run by default and verified against the live Cloud API.
- Repair filters, dashboards, fields, roles and permissions that JCMA leaves open
- Managed Migration: automatically run the right fixes per project as it finishes
- Web UI or CLI, every module dry-run by default and secured by the idempotent write gateway
A fit for your migration?
Describe your case in a few lines — I'll tell you honestly whether and how this tool helps.
Book a callAtlassian ends support for Data Center on 28 March 2029. If you are moving a large, deeply connected environment, plan early rather than late.