もしこの投稿が不適切な場所でしたら申し訳ありませんが、GitHub Issue → Discourse 移行ツールのような機能の再実装を検討されているご予定はありますか？私たちは kubernetes プロジェクトや、私が知るいくつかの他の OSS プロジェクトでこれを利用したいと考えています。
私たちは GitHub に投稿されたサポート関連の issue をクローズし、ユーザーに Discourse フォーラム へ再投稿するよう案内しています。もし移行機能が付属していれば、フラグが付けられた際に自動で移動させるボットコマンドを追加し、ユーザーにリンクを提供することも可能になるでしょう。
ああ、より永続的な解決策をお探しのようですね。問題リストを定期的にスキャンして、内容をコピーし、クローズするといった対応はいかがでしょうか。
ワークフローの観点から言えば、良い解決策としては、kind/supportタグで関連事項をタグ付けし、新しいサポートに関する問題が発生した場合は GitHub でクローズし、Discourse で新規作成し、Discourse へのリンクを含む投稿を追加するという流れが考えられます。
このような機能を実現するには多くの作業が必要です。現在、当社の Discourse と GitHub を連携させるプラグイン（https://github.com/discourse/discourse-github）ではリンクバックのみを行っていますが、これを拡張する必要があります。しかし、技術的には十分に実現可能です。
ただし、これはコードレビュープラグインには適合しないため、タグ付けの再検討は必要かもしれません。
これは、あなたがスポンサーシップを検討しているタイプの作業でしょうか？もしそうであれば、これを当チームの受信トレいに移動させます。
返信が遅くなり申し訳ありません。
注意点ですが、discourse-github プラグインの仕組みにはあまり詳しくありません。しかし、プロジェクト側が該当するイシュー番号を含む呼び出し（ウェブフック）をトリガーできる場合、そのイシューを取得し、トピックとして投稿し、その後イシュー側にそのトピックへのリンクを返すというアプローチが考えられるかもしれません。
このようにすれば、イシューとコメントの取得をトリガーする動作の責任はリポジトリのメンテナーに委ねられます。GitHub Actions や probot プラグインなどを用いて実装可能です。また、イシューを自動的にクローズするか、そのまま開いたままにするかも彼らが判断できます。
最後の部分について補足しますと、現時点ではまだ該当しませんが、将来的には可能性はあります。