Post-acquisition consolidation of issue type and workflow schemes

The union is easy; deletion is the trap. Issue types are global objects - a scheme merely selects them. So confirm first that SUP's Bug and ENG's Bug are the same object and not two near-duplicates created by an admin years ago (names like 'Bug ' or 'Defect'). Duplicates are the only thing here that would force a real migration.

Build one new scheme: Epic, Story, Bug, Task, Sub-task. Then:

1. Adding a type is safe - assign both projects to the new scheme and SUP simply gains Story/Epic.
2. Removing a type is not - Jira refuses to remove an issue type from a scheme while issues of that type exist in a project using the scheme. Because you only add, no migration is needed. Do not try to standardise by deleting.
3. Set the default issue type deliberately - it drives the Create button and API/portal fallbacks. Task is the safest shared default; leaving it as Story would have support agents creating stories.
4. Before assigning, confirm every included type is on each project's create screen and has a workflow in the workflow scheme. Missing either produces 'issue type is not valid' or 'no workflow associated' errors at create time, which read like permissions bugs.
5. Sub-tasks: keep one sub-task type. Multiple sub-task types across projects quietly break boards, filters and hierarchy reports.
6. 'Customer is required on SUP only' survives the consolidation - required-ness is a field-configuration property, and each project keeps its own field configuration scheme.

The goal is comparable reporting, not identical workflows.

• Option A - one shared workflow with the union of statuses. Cheapest to maintain, but it creates illegal paths: an ENG story can be moved to 'Waiting for Customer', and every ENG board must map a status its team never uses. Every future change requires cross-team coordination.
• Option B - one workflow scheme, two workflows, mapped by issue type. Workflow schemes map issue type → workflow, so a single scheme can hold SUP's workflow for Task/Sub-task and ENG's for Story/Epic, still satisfying 'one workflow scheme'. Caveat: Bug can map to only one workflow per scheme - pick which project's process governs bugs.

Recommendation: B, plus standardise status categories rather than status names. Report with statusCategory = Done and statusCategory = In Progress and both teams' data aggregates regardless of whether they call the terminal state Resolved, Closed or Done.

Execution: use the workflow scheme switch/migration, mapping every old status to a target status and choosing to save a backup. Statuses with no mapping lose their status (history survives in the changelog, the current status does not). Map the done-category statuses to done-category targets so boards keep counting them as complete. Do it in a change window: the switch triggers re-indexing and can briefly hide issues from boards and filters.

• Ownership. A filter is owned by a person; if the support manager leaves the site, both boards and the weekly report break. Move ownership to a shared service account and share the filter with a group or project role, not with the owner alone.
• Scope. Rewrite project = SUP deliberately - extend to both projects only if the report is meant to be cross-project. Do not accidentally let the ENG Scrum board pick up SUP issues.
• Status-name JQL. Any clause naming Resolved, Closed or Waiting for Customer silently changes meaning after the switch. Replace with statusCategory/resolution-based clauses.
• Gadget permissions. Filters and dashboards have independent sharing. A gadget renders blank or errors for viewers who can see the dashboard but not the filter, so share filters to the same audience as the dashboard.
• Subscriptions if the weekly report is emailed - recreate them after changing ownership.