Transfer GitHub Issues Between Repositories
Transfer the existing issue when another repository should own it, then inspect metadata and access after the move. This preserves a better history than copying the description into an unrelated new record.
Step-by-step guide
Check access and scope
You need write access in both repositories. Transfers require the same owning user or organization; private issues cannot transfer into public repositories.
Agree receiving ownership
Agree on the destination with the receiving maintainer.
Capture existing metadata
Record the issue URL, labels, milestone and linked context.
- Worked example: A bug filed against documentation may belong in the service repository after investigation. Preserve the original report and reproduction details while letting the receiving team choose its own labels and milestone.
Transfer the issue
Use the issue transfer action and choose the eligible repository. Use Transfer issue in the issue sidebar and select an eligible destination; the original URL redirects after transfer.
Inspect the destination
Inspect fields, subscriptions and resource access after transfer.
Notify affected owners
Notify affected owners and update textual references where useful.
Verify the result
The original reference leads to the transferred work and the receiving maintainer can locate its evidence.
Common mistakes
Check the handoff edge case
Labels and milestones depend on matching destination metadata. Inspect the moved issue instead of assuming every classification survives.
Sources and verification
Based on product documentation checked on 2026-10-24. This is a documentation-based guide, not a hands-on benchmark. Features and availability can change.