Everything the transition needs, in one place
Four modules that hand evidence to each other: assess, gate, transition, then prove it survived early life.
Readiness templates & weighted scoring
Define once, reuse everywhere. Admins build templates of criteria grouped into categories; transition managers score against them.
- Categories and criteria — group by Support Model, Knowledge, Monitoring, Security, Training, or whatever your organisation gates on.
- Weights of 1–10 per criterion, so a runbook can matter more than a nice-to-have.
- A 0/25/50/75/100 "met" scale — partial credit where it is genuinely partial, not a binary tick.
- Evidence links and notes on every line, so the score points at the proof.
- Mandatory flags for criteria that must not be waved through.
- Immutable versioning — editing a template creates a new version, and assessments already in flight keep the version they started with.
- Configurable RAG thresholds, set globally or overridden per project.
What this video shows
- Every service in transition, at a glance
- Open one to see the assessment behind its score
- Weighted scoring, rolled up by category
- Score a criterion and the total moves with it
- Support Readiness clears red; the total follows
- Record the go/no-go decision against that score
- The score is snapshotted with it — this cannot be undone
- Gate history is immutable: appended, never edited
Go / No-Go gates with a real audit trail
The decision that matters most is the one most often lost. Gates capture it properly.
- Three outcomes — Go, Conditional Go, No-Go. Conditional Go carries its conditions as a list.
- Who and when — the decider's Atlassian identity and a timestamp, taken from the session, never from the form.
- The score at the moment of sign-off is snapshotted into the decision, so later re-scoring cannot rewrite history.
- Immutable by design — there is no update or delete path for a gate decision anywhere in the app.
- Optional traceability comment posted to the linked JSM request, so the decision is visible from the ticket.
- Full gate history per service, newest first.
Transition plans that stay honest
Phases, tasks, owners, dates — and rollups the app recomputes itself, so the status on the portfolio is never a stale manual entry.
Owners and dates
Assign any Jira user through a picker that returns account ID and display name only. Due dates drive the overdue count.
Linked Jira issues
Attach an existing issue to a task and see its live status badge, read with your own permissions.
Server-side rollups
Percent complete, overdue and blocked counts, and a plan health of On Track / At Risk / Late derived against the target go-live date.
My tasks
One toggle lists everything assigned to you across every service in the project, due-date sorted with overdue highlighted.
Safe concurrent editing
Task edits use compare-and-set. If someone else saved first you are told to refresh, rather than silently overwriting them.
Quick add
A one-line add row on every phase, so building out a plan does not mean a modal per task.
Early-life support, with evidence
The warranty period is where transitions actually succeed or fail. STR makes it a tracked process with data behind the exit decision.
- A defined period with a live countdown, opened after the gate decision.
- A reminder on the linked issue — the service owner is @-mentioned 14 days before the period ends, and again if it ends without sign-off, once per period. Jira's own notifications deliver it; nothing leaves your site.
- Exit criteria with met-by and met-at captured server-side — the client cannot assert who ticked what.
- Your own incident JQL per service, validated live against Jira before you save it.
- Daily trend snapshots of created, resolved, open and P1 counts, kept by a scheduled job and backfillable on demand.
- Audited extensions — moving the end date requires a reason and appends to an extension log.
- Blocked sign-off until mandatory criteria are met; an override is allowed but records the reason and exactly which criteria were bypassed.
- Handover to BAU stamps the signer, the timestamp and the go-live date, and moves the service to Live.
Portfolio & export
A site-wide view for the people who chair the review, and a CSV for the pack that goes with it.
What this video shows
- Every service in transition, across every project
- Sort by readiness to surface what is furthest behind
- Filter to the services scoring red
- Or to one project
- Export the whole portfolio as CSV
Summary tiles
In transition, awaiting gate, in ELS, overdue tasks, average readiness.
Filter & sort
By project, status, gate decision and RAG band; sort by score or go-live date.
CSV export
Generated server-side from the filtered view, escaped against spreadsheet formula injection.
Project mini-portfolio
The project page lands on the same view, scoped to that project's services.
Publishing to Jira
Optionally, the app writes a status summary for each service onto the Jira issue it is linked to — so "which services go live this fortnight without a Go?" is a JQL query in Jira's own search, filters and dashboards, with no STR page open.
What this video shows
- Readiness templates are versioned
- Editing one creates a new version
- RAG thresholds, ELS length, default plan phases
- Publishing status to Jira is off by default
- The warning comes before the switch, not after it
- Saving publishes the services you already have
- It reports what it could not publish, too
- These names now work in Jira’s own search
Off until an administrator turns it on
The setting is site-wide: switched on, it publishes for every service in every project that is linked to an issue. The admin page says so above the switch, not after it. Saving publishes the services you already have, and says how many it could not — a service with no linked issue has nowhere to publish to.
Status only
A closed set of status words, dates, counts and the time the service's record last changed — no names, no account identifiers and no free text. It is stored by Jira, inside your own site, and anyone who can read the issue can read it, as can other apps installed on your site.
Searchable with JQL
strStatus, strGate, strReadiness, strPlanHealth, strOverdueTasks, strTargetGoLive and strEls work anywhere JQL does. For example, strGate != "go" AND strTargetGoLive <= 14d finds the services going live within a fortnight that have not passed their gate. A search only ever returns issues the person running it can already see.
Removable
Turning it off removes what the app wrote, when the daily reconciliation next runs; the Remove published data button does it straight away. Turn it off before uninstalling: once the app is gone it cannot remove anything. See the Privacy Policy.
Four places it shows up in Jira
No separate tool, no separate login, no separate permissions model.
| Surface | Who uses it | What it shows |
|---|---|---|
| Issue panel On the linked JSM request | Anyone on the request | Readiness score, category RAG chips, the latest gate decision, and a link through to the Service Transition & Readiness. |
| Project page "Service Transition & Readiness" | Transition & delivery managers | The project's services, then per-service Readiness, Plan and ELS tabs. |
| Global page "Service Transition & Readiness" | Service delivery managers, CAB | Every service in transition across the site, filterable and exportable. |
| Admin page | Jira administrators | Readiness templates, RAG thresholds, default ELS length, default plan phases, and the Publishing to Jira setting. |
The issue panel is a native Jira UI Kit surface, so it renders in Jira's own components and adopts your site's theme automatically.
Stop guessing whether a service is ready
Bring readiness scoring, gate sign-off and early-life support into the tool your teams already run transitions in.
Pricing and trial details are on the Atlassian Marketplace listing.