Promote a Jira Cloud workflow scheme sandbox → production

01 — Scheme vs workflow

Why “I imported the workflow” is not enough

Company-managed projects do not bind to a lone workflow. They bind to a workflow scheme: which issue type uses which workflow (Story → software flow, Bug → bug flow, Epic → epic flow, and so on). Promoting only one workflow definition leaves production with the old scheme map — so issue types still hit the wrong path. This guide is the scheme job. For a single definition, use the sandbox → prod workflow move.

02 — When you need scheme promote

Sandbox scheme is tuned; production still has the old map

• New issue-type wiring — sandbox maps Bug and Task to different workflows; production still shares one.
• Scheme rename / replace — you built a cleaner scheme in sandbox and want that map on prod without hand-editing every association.
• Pilot then roll out — promote the scheme, attach it to one pilot project, then widen — same habit as workflow-only moves.

Native Cloud still has no clean “export this scheme file → import on the other site” path. Full project / product copy is heavier than a scheme-only change, and on Standard you often lack Premium sandbox deploy.

03 — Safe sequence

Export scheme → compare → validate → snapshot → import

1. Export the scheme from sandbox as portable JSON (workflows in the scheme plus the issue-type map) — not a screenshot of Associations.
2. Compare staging vs production for the workflows that scheme will write — side by side, not by memory (compare guide).
3. Validate on production in read-only mode — Ready vs blocking (statuses, fields, third-party rules) before any write (validate guide).
4. Snapshot production first so a bad promote is a one-click restore (backup / restore).
5. Import when Ready — then attach or confirm the scheme on a pilot project before every project.
6. Verify — open one issue per mapped type; spot-check critical transitions; keep screens, fields, and automation on a separate checklist.

04 — Scope (honesty)

Company-managed schemes · Forge · not full CM

This path is for company-managed Jira Cloud workflow schemes (and the workflows they reference). It is not team-managed, not Data Center XML, not issue/project copy, and not a full Configuration Manager for screens, fields, permission schemes, or every scheme type. Easy Workflows runs on Atlassian Forge: definitions, snapshots, and history stay in your site. Free for teams ≤10; 30-day trial; then about USD 2/user/mo via Atlassian. We do not claim to undercut Workflow Wizard at larger seat counts — pick the tool that matches the job. For Premium sandbox configuration deploy or full-site CM, use Atlassian / CMJ / Revyz when that is the real need.

05 — Which guide to open next

Scheme promote vs move vs Standard vs C2C

• This guide — promote a company-managed workflow scheme sandbox → production.
• Move a workflow — single definition sandbox → prod.
• Compare — side-by-side before you promote.
• Validate — Ready / blocking before any write.
• Standard plan — promote without Premium sandbox deploy.
• Copy between sites — workflow-only clone site-to-site.
• Transition properties after C2C — product copy dropped properties; compare → validate → re-import.
• Restore — pick snapshot → one-click restore → verify.

06 — Tooling

Easy Workflows for Jira

Easy Workflows for Jira is a Forge app for that scheme/workflow promote path: export portable JSON (workflow or scheme), side-by-side compare, read-only validate with Ready / blocking verdict, import when you confirm, plus in-site snapshots and one-click restore.

Marketplace: Easy Workflows for Jira. Support: info@berkly.nl.

Try free on Marketplace