Answer

Yes — moving issues between projects already exists, but only from the issue list (batch operations), not from the issue detail side panel.

How to move today

1. Open the project's Issues list
2. Select one or more issues (or use a query)
3. Open the batch/actions menu
4. Choose Move Selected Issues To... or Move All Queried Issues To...
5. Pick the destination project and confirm by typing yes

This requires issue management permission on the source project. Destination projects must have issue management enabled and be accessible to you.

Comments, discussion history, attachments, links between issues (by internal id), votes, watches, etc. stay on the same issue record — the move updates the issue's project and assigns a new number in the destination project. A project-change activity is recorded on the issue.

Docs also mention this flow in the service desk tutorial (tickets opened in a default project can be moved later).

Detail-page UX you described

There is no "Move issue" control next to the copy-reference button in the side info panel today (EntityReferencePanel only shows the reference + copy icon).

Feasibility of that UX: high / relatively small. Backend support already exists (IssueService.move(...)), and the list UI already uses ProjectSelector + confirm modal. Adding an icon with tooltip "Move issue" beside the copy button that opens the same project selector would mainly be UI wiring on the issue side panel — not a new data model.

Important caveat on references

Your requirement that references from other issues, PRs, and commit messages keep working after the move is not fully met by the current move behavior:

On move, the issue gets a new number in the destination project. External text that still says oldProject#123 or OLDKEY-123 will not resolve to the moved issue.

Clarifying questions

1. Is the existing list-based move enough for your use case, or do you still want the detail-page control?

A. List-based move is enough — no product change needed
B. Still want the side-panel "Move issue" icon + project selector as described
C. Want both documented clearly, and the side-panel control as a convenience

Recommendation: C if this comes up often; otherwise B if you mainly care about the detail-page shortcut.

2. How strict is the "preserve all external references" requirement?

A. Current behavior is acceptable (discussion preserved; old textual refs may break)
B. Must keep old references working via a redirect/stub at the old project+number (and ideally old URL) pointing to the new location
C. Must rewrite references across other issues/PR descriptions/comments (commits still can't be rewritten)
D. Prefer keeping the same number when possible (e.g. if unused in destination) plus redirects for any number change

Recommendation: B (redirect/stub) if reference integrity is "very important" as stated — that is the only approach that can cover commit messages. A if the main pain is misfiled issues with little external linking yet.

3. If we add the side-panel control, who should be allowed to use it?

A. Same as today: users with issue management on the source project
B. Also require issue management (or create-issue) on the destination project
C. Broader: any user who can edit the issue

Recommendation: B for a detail-page control (clear intent + safer), or keep A for parity with the existing list action.

4. After you answer above, what should we do next?

A. Close this question — existing list move is sufficient
B. Open/convert to an Improvement for the side-panel UX only (current move semantics)
C. Open/convert to an Improvement for side-panel UX and stronger reference preservation (per Q2)
D. Something else (please describe)

Please reply with your choices (e.g. 1B, 2B, 3B, 4C). Once you confirm, we can either close this question or escalate for implementation planning.

1. This is not correct. There is an operations menu but there is no batch actions menu. In any case This is counterintuitive to move from the Issues list because when you move from the actual issue itself into the Issues list, you lose the context of exactly which issue you are talking about. This leaves us vulnerable to user errors where they end up moving the wrong issue.
2. B is the minimum requirement. I would you like to ALSO implement option C, which would make this product a world-class product, however I prefer to leave the architectural approval for option C to @robin
3. b
4. D. We are awaiting the decision from Robin. Following the decision, if there are no outstanding unanswered questions, please create a fresh issue with the detailed set of requirements and architectural decisions made, as well as motivations and so on, and then close this issue.

Thanks for the correction — you're right. On the Issues list the move actions live under the Operations menu (Move Selected Issues To... / Move All Queried Issues To...), not a separate "batch actions" menu. Sorry for the inaccurate wording.

Agreed on the UX concern: leaving the issue detail to find and re-select the issue in the list loses context and makes it easy to move the wrong issue. A detail-page "Move issue" control next to the copy-reference icon remains the right product direction.

Recorded choices so far

@robin — please decide on reference preservation architecture:

1. Redirect/stub (required minimum): After move, should old project#number / KEY-number and old issue URLs resolve via a stub/redirect to the new location? Any constraints on stub lifetime, permissions, or whether the old number stays reserved in the source project?
2. Rewrite references (optional / world-class): Should we also rewrite textual references in other issues' and PRs' descriptions/comments (knowing commits remain immutable)? Approve, defer, or reject for a first version?
3. Anything else that should be locked before we open the implementation issue?

No code changes from this question until that decision; we'll open the requirements issue afterward as requested.

My apologies there is a move operation action.

No worries — thanks for confirming. The Operations menu move is the existing path; your earlier points still stand (detail-page control preferred for context/safety, redirect/stub as minimum, rewrite left to @robin, destination rights as discussed). Still awaiting @robin's decision before opening the implementation issue.

@robin my recommendation is as follows:

1. Yes we need a redirect stub. This is absolutely compulsory otherwise things will break.
2. Yes we should rewrite references in order to ensure the integrity of the system

(No response needed from AI User @servicedesk)