製品間の移行について

Enterprise Importer を使うと、 Enterprise Server から Enterprise Cloud にデータを移行することも、.com から Enterprise Cloud 上の別のアカウントにデータを移行することもできます。

たとえば、 Enterprise Importer は、お客様の会社で次を行うのに役立ちます。

• エンタープライズを GHE.com に移行することで、データ所在地付き Enterprise Cloud を採用する
• .com のエンタープライズ間で移行することにより、Enterprise Managed Users や新しい課金モデルなど、.com の特定の機能を導入する
• Enterprise Server から Enterprise Cloud に移行することで、簡素化された管理と新機能の恩恵を受ける

移行元が .com のアカウントである場合は、組織間で個々のリポジトリを移行したり、エンタープライズ間で組織全体を移行したりできます。 移行元が Enterprise Server の場合は、個々のリポジトリを移行できます。

Enterprise Importer が移行するデータは、移行元と、リポジトリまたは組織のどちらを移行しているかによって異なります。

への移行に関する考慮事項

Enterprise Importer を使う前に、以下の考慮事項を確認しておいてください。

• Enterprise Cloud を既に使用している場合: Enterprise プランでは、 Enterprise Cloud のデプロイを 1 つ利用できます。

  たとえば、既に .com を使用していて、 Enterprise Server から GHE.com への移行も行いたい場合は、1 つのプランで両方の使用に対応することはできません。

• Enterprise Managed Users に移行する場合: ID プロバイダーと統合してユーザー アカウントを管理する必要があります。 開始する前に、ID プロバイダーのサポート レベルを確認してください。 「Enterprise Managed Users について」を参照してください。

• Enterprise Server から移行する場合: では特定のアクションにレート制限が適用されることに注意してください。これは、 Enterprise Server では既定で無効になっています。 「REST API のレート制限」を参照してください。

• データ所在地付き Enterprise Cloud に移行する場合: 特定の機能は使用できず、一部の機能には異なる構成または追加の構成が必要になることに注意してください。 「データ所在地付き Enterprise Cloud の機能の概要」を参照してください。

Enterprise Server (GHES) から移行するには、GHES バージョン 3.4.1 以降が必要です。 移行されるデータは、使用しているバージョンによって異なります。

GHES のバージョンに応じて、リポジトリあたりの異なるサイズ制限が適用されます。

現時点では、次のデータは移行されません。

• 監査ログ
• Code scanning の結果
• コミット状態チェック
• Dependabot のアラート
• Dependabot のシークレット
• リポジトリ レベルでのディスカッション
• issue のコメントと pull request のコメントの履歴を編集する
• リポジトリ間のフォーク関係 (「フォークについて」を参照してください)
• Actions シークレット、変数、環境、セルフホステッド ランナー、より大きなランナー、またはワークフロー実行履歴
• Apps と App のインストール
• Git LFS オブジェクトと大きなバイナリ (Git LFS を使うリポジトリは引き続きサポートされます。「 Enterprise Importerの制限事項」を参照してください)
• リベース マージされたコミットから pull request へのリンク
• Packages
• Projects (新しいプロジェクト エクスペリエンス)
• 異なるリポジトリ内の pull request と issue 間の参照 (「自動リンクされた参照と URL」を参照してください)
• secret scanning の結果の修復状態
• ユーザー アカウントが所有するリポジトリ
• リポジトリのアクティビティ フィード
• リポジトリのプロパティ
• リポジトリの星
• リポジトリ ウォッチャー
• ルールセット
• タグ保護ルール
• ユーザーのプロファイル、SSH キー、署名キー、または personal access tokens
• Webhook のシークレット
• Teams
• リポジトリへのユーザーまたはチームのアクセス
• pull request のリポジトリ設定

ブランチ保護により、特定のブランチ名またはブランチ名パターンに、指定した一連の規則が適用されます。 詳しくは、「保護されたブランチについて」をご覧ください。

ブランチ保護は常に移行されますが、特定の規則は移行されません。 次のブランチ保護規則は移行されません。

• 特定のアクターが必須の pull request をバイパスできるようにする
• 最新のプッシュの承認を要求する
• Require deployments to succeed before merging
• ブランチをロックする
• 一致するブランチを作成するプッシュを制限する
• フォースプッシュを許可

また、次の制限事項が適用されます。

• ブランチ保護規則で、規則の適用対象外とするユーザー、チーム、またはアプリを必要に応じて指定できる場合 ("pull request レビューを無視できるユーザーを制限する" など)、例外は移行されません。
• "強制プッシュを許可する" 規則が "強制プッシュできるユーザーを指定する" モードで有効になっている場合、規則は移行されません。

移行元が .com のアカウントである場合は、組織間で個々のリポジトリを移行したり、エンタープライズ間で組織全体を移行したりできます。

Organization を移行すると、移行先の Enterprise アカウント内に新しい Organization が作成されます。 その後、次のデータが新しい Organization に移行されます。

• Teams
• リポジトリ
• リポジトリへのチーム アクセス
• メンバー特権
• Organization レベルの Webhook (移行後に再度有効にする必要があります。「Webhook の有効化」を参照してください)
• Organization 内に作成された新しいリポジトリの既定のブランチ名

すべてのリポジトリは、可視性を非公開として移行されます。 リポジトリの可視性を公開または内部に設定する場合は、移行後に UI または API を使用して行うことができます。

チーム メンバーシップは移行されません。 移行後、移行されたチームにメンバーを追加する必要があります。 詳しくは、「 製品間の移行に関する概要」をご覧ください。

リポジトリを直接、または Organization 移行の一部として移行すると、次のデータのみが移行されます。

• Git ソース (コミット履歴を含む)
• Pull Request
• issue
• マイルストーン
• Wiki (添付ファイルを除く)
• Actionsのワークフロー
• コミットのコメント
• アクティブな Webhook (移行後に再度有効にする必要があります。「Webhook の有効化」を参照してください)
• リポジトリトピック
• リポジトリ設定
  • ブランチ保護 (詳細については、「ブランチ保護」を参照してください)
  • Pages の設定
  • 自動リンク参照
  • pull request の設定
    • head ブランチを自動的に削除する
    • 自動マージを許可する
    • マージ コミットを許可する (コミット メッセージの設定が既定のメッセージにリセットされる)
    • スカッシュ マージを許可する (コミット メッセージの設定が既定のメッセージにリセットされる)
    • リベース マージを許可する
• リリース (リポジトリあたり最大 10 GB)
• 上記のデータのユーザー履歴
• 添付ファイル (「ファイルのアタッチ」を参照してください)

現時点では、次のデータは移行されません。

• Codespaces のシークレットの * 監査ログ
• Code scanning の結果
• コミット状態チェック
• Dependabot のアラート
• Dependabot のシークレット
• リポジトリ レベルでのディスカッション
• issue のコメントと pull request のコメントの履歴を編集する
• リポジトリ間のフォーク関係 (「フォークについて」を参照してください)
• Actions シークレット、変数、環境、セルフホステッド ランナー、より大きなランナー、またはワークフロー実行履歴
• Apps と App のインストール
• Git LFS オブジェクトと大きなバイナリ (Git LFS を使うリポジトリは引き続きサポートされます。「 Enterprise Importerの制限事項」を参照してください)
• リベース マージされたコミットから pull request へのリンク
• Packages
• Projects (新しいプロジェクト エクスペリエンス)
• 異なるリポジトリ内の pull request と issue 間の参照 (「自動リンクされた参照と URL」を参照してください)
• secret scanning の結果の修復状態
• ユーザー アカウントが所有するリポジトリ
• リポジトリのアクティビティ フィード
• リポジトリのプロパティ
• リポジトリの星
• リポジトリ ウォッチャー
• ルールセット
• タグ保護ルール
• ユーザーのプロファイル、SSH キー、署名キー、または personal access tokens
• Webhook のシークレット
• リポジトリへのユーザー アクセス

リポジトリを直接移行する場合、チームと、リポジトリへのチーム アクセスは移行されません。

ブランチ保護により、特定のブランチ名またはブランチ名パターンに、指定した一連の規則が適用されます。 詳しくは、「保護されたブランチについて」をご覧ください。

ブランチ保護は常に移行されますが、特定の規則は移行されません。 次のブランチ保護規則は移行されません。

• 特定のアクターが必須の pull request をバイパスできるようにする
• 最新のプッシュの承認を要求する
• Require deployments to succeed before merging
• ブランチをロックする
• 一致するブランチを作成するプッシュを制限する
• フォースプッシュを許可

また、次の制限事項が適用されます。

• ブランチ保護規則で、規則の適用対象外とするユーザー、チーム、またはアプリを必要に応じて指定できる場合 ("pull request レビューを無視できるユーザーを制限する" など)、例外は移行されません。
• "強制プッシュを許可する" 規則が "強制プッシュできるユーザーを指定する" モードで有効になっている場合、規則は移行されません。

Enterprise Importer で何を移行できるかについては、制限があります。 の制限に起因するものもあれば、 Enterprise Importer 自体の制限事項であるものもあります。

の制限事項

• 1 つの Git コミットに対する 2 GB のサイズ制限: Git リポジトリ内の 1 つのコミットが 2 GB を超えることはできません。 いずれかのコミットが 2 GB を超える場合は、そのコミットを、それぞれが 2 GB 以下の小さなコミットに分割する必要があります。
• Git 参照の 255 バイトの制限: "ref" と呼ばれる 1 つの Git 参照には、255 バイトを超える名前を付けることはできません。 通常、これは、参照の長さは 255 文字を超えることはできませんが、絵文字などの ASCII 以外の文字は複数バイトを消費する可能性があることを意味します。 いずれかの Git 参照が大きすぎる場合は、明確なエラー メッセージが返されます。
• 100 MB のファイル サイズ制限: 移行が完了した後、Git リポジトリ内に 100 MB を超えるファイルは存在できません。 リポジトリの移行中は、この制限が 400 MB に増やされます。 大きなファイルを格納するためには、Git LFS を使用することを検討してください。 詳しくは、「大きなファイルを管理する」をご覧ください。

• Git リポジトリの 40 GB のサイズ制限 (パブリック プレビュー): この制限はソース コードにのみ適用されます。 リポジトリ アーカイブが制限を超えているかどうかをチェックするには、git-sizer ツールを使用して出力の合計 BLOB サイズを確認します。 git-sizer ツールは、大きなファイル、BLOB サイズ、コミット サイズ、移行に影響する恐れがあるツリー数に関連する潜在的な問題を特定することにも役立ちます。
• メタデータの 40 GB の制限 (パブリック プレビュー):: 40 GB を超えるメタデータを含むポジトリは、Importer で移行できません。 メタデータには、issue、pull request、リリース、添付ファイルが含まれます。 ほとんどの場合、大きなメタデータの原因は、リリースにアタッチされたバイナリ資産です。 migrate-repo コマンドの --skip-releases フラグを使用して移行からリリースを除外し、移行後にリリースを手動で移動できます。
• 400 MB file size limit: When migrating a repository with Enterprise Importer, no single file in your Git repository can be larger than 400 MB. Consider using Git LFS for storing large files. For more information, see 大きなファイルを管理する.
• Git LFS objects not migrated: The Importer can migrate repositories that use Git LFS, but the LFS objects themselves will not be migrated. They can be pushed to your migration destination as a follow-up task after the migration is complete. For more information, see リポジトリを複製する.
• Follow-up tasks required: When migrating between products, certain settings are not migrated and must be reconfigured in the new repository. For a list of follow-up tasks you'll need to complete after each migration, see 製品間の移行に関する概要.
• Delayed code search functionality: Re-indexing the search index can take a few hours after a repository is migrated, and code searches may return unexpected results until re-indexing is complete.
• Rulesets configured for your organization can cause migrations to fail: For example, if you configured a rule that requires email addresses for commit authors to end with @monalisa.cat, and the repository you're migrating contains commits that don't comply with this rule, your migration will fail. For more information about rulesets, see ルールセットについて.
• Mannequin content might not be searchable: Mannequins are placeholder users to which imported content (such as issues, pull requests, comments, etc.) is associated. When you search for content associated with a mannequin, such as assigned issues, the issues may not be found. Once a mannequin is reclaimed, the content should be found via the new owner. For more information, see Enterprise Importer のマネキンの回収.

製品間で移行する前に、移行の実行方法を計画する必要があります。 データを移行する前に、移行を実行する名前未登録ユーザーを選択する必要があります。　 移行元と移行先の両方に必要なアクセス権をそのユーザーに付与する必要があります。　 また、最初に試用版の移行を実行することをお勧めします。

最初から最後までの移行プロセスの概要については、「 製品間の移行に関する概要」を参照してください。