Professional Services EM スコーピング - マイグレーション

セールス向け情報 - SaaS へのマイグレーションのポジショニング

• GitLab セルフマネージドから SaaS へのマイグレーション

マイグレーションスコーピングの詳細

このページでは、GitLab、Bitbucket Server、または GitHub（Enterprise または .com）から、宛先 GitLab インスタンス（セルフマネージドまたは SaaS）へのマイグレーションのスコーピングについて説明します。これらのマイグレーションでは、通常、自動化ツールである Congregate を使用します。他の SCM システムからのマイグレーションや、GitLab 以外の CI/CD マイグレーションは、このマイグレーションツールの対象外であり、別途スコーピングする必要があります。

services calculator を使用して、SA、CSM/CSM がスコーピング Issue を作成し、エンゲージメントマネージャーと協力して顧客向けのサービス見積りを反復・改善できます。この Issue では、SCM マイグレーションスコーピング質問に追加コンテキストを含めており、以下でプレビューできます。

注意:

1. ソースコード管理（SCM）マイグレーションには、シークレットの仲介は含まれません。
2. SCM マイグレーションには、CI/CD 機能を GitLab CI を使用するように移行することは含まれません。

GitLab セルフマネージドから GitLab.com へのマイグレーションに関する注意事項

• SaaS へのマイグレーションが最良の推奨事項とならない特定のケースがあります。SaaS が最良のソリューションかどうかを顧客と判断する際の検討事項は次のとおりです。
  1. 顧客は GitLab CI 以外を使用していますか？ もしそうなら、CI ツールと GitLab.com の間に接続を確立できますか？ GitLab と CI/CD ツールの使用を妨げる問題が時々発生します。例えば、顧客がネットワークセキュリティチームに対し、ファイアウォールの背後で GitLab SaaS と CI/CD ツールを使用できるようにファイアウォール設定を調整するよう説得できない場合があります。
  2. 顧客が非常に多くのプロジェクトを持つ場合、これは変更管理上の課題となるだけでなく、マイグレーション実施のコストが大きくなりすぎる場合があります。例えば、最近のセルフマネージドインスタンスでパフォーマンスの問題を抱えていたある顧客の場合、SaaS へのマイグレーションには 40 万ドルと 150 日以上が必要となる予定でした（1600 ユーザー、20,000 以上のプロジェクト）。Ultimate を使用している顧客には GitLab Dedicated がより良い選択肢となる場合があります。
  3. 顧客は SaaS で利用できないセルフマネージド機能（例: サーバーフック）の使用継続を強く望んでいる場合があります。詳細は セルフマネージドと SaaS の違い を参照してください。
  4. 顧客は SaaS へのマイグレーションが困難となる非常に大きな GitLab プロジェクトを持っている可能性があり、SaaS を使用するには 追加のストレージ消費に対する支払い が必要となります。さらに、顧客が非常に大きなモノレポを持つ場合、git や CI のパフォーマンスに既知の問題があります。
• セルフマネージドから SaaS へのマイグレーション には、追加情報、概算見積り、よくある顧客の質問が含まれています。
• GitLab UI マイグレーションと Congregate マイグレーションの比較を確認し、どの機能がマイグレーションされ、どれがされないかをよりよく理解するには、Congregate Features Matrix を参照してください。
• Congregate を使用したある GitLab インスタンスから別のインスタンスへのマイグレーションでは、ソースシステムのグループとプロジェクトの構造がマイグレーション中に保持される必要があります。
• スコーピングには、標準の Automated Migration PS Engagement Estimate Template を使用します。30 個未満のリポジトリを持つ非常に小さなマイグレーションの場合、Manual Migration Estimate Template を使用して手動マイグレーションのコストと自動マイグレーションのコストを比較してください。
• SaaS Discovery、SSO 設定、セキュリティ設定のアクティビティは、通常 SaaS へのマイグレーションに追加されます。詳細は Services Calculator のアクティビティを参照してください:
  • saas_discovery_remote
  • saas_sso_configuration_remote
  • saas_security_configuration_remote
• マイグレーションアプローチの概要、どの機能がマイグレーションされるか/されないかについては、TEMPLATE Professional Services Presentation を参照してください。これには、新しい SaaS 顧客向けによく追加する SaaS Discovery、SSO 設定、セキュリティ設定のアクティビティの説明も含まれています。

GitLab セルフマネージドから GitLab セルフマネージド

• Congregate を使用できますが、他のオプションも利用可能です:
  • rake タスクを使用した バックアップと復元。これにより、ある GitLab インスタンスから別のインスタンスにすべてのデータを復元できます。これはマイグレーション期間を短縮するために使用できますが、バックアップにかかる時間中はソースインスタンスをロックする必要があるため、完全なダウンタイムが発生します。また、データのサイズによっては、これに数時間から数日かかる場合があります。
  • Geo レプリケーション。この方法では、新しい GitLab インスタンスを Geo セカンダリとしてセットアップできます。データは時間をかけて同期されます。その後、フェイルオーバーを実行して新しいインスタンスをプライマリにできます。これはバックアップ/復元アプローチよりも複雑になりがちで、より専門的なスキルセットを必要とします。

GitLab セルフマネージドから GitLab Dedicated インスタンス

• セルフマネージドからセルフマネージドへのマイグレーションと同様に、セルフマネージドから Dedicated インスタンスへのマイグレーションも、Congregate、バックアップ・復元アプローチ、または Geo レプリケーションを使用して実行できます。Congregate オプションを使用する場合、プロジェクトは最大 500 のウェーブでマイグレーションできます。
• プロジェクトを含むグループのマイグレーションは Beta 機能 であり、Dedicated インスタンスへのマイグレーションにも使用できます。Dedicated インスタンスは GitLab バージョン 15.10 以降である必要があります。この方法の制限事項と要件を理解するには、リンクされたドキュメントを参照してください。

GitHub ソース

GitHub Enterprise から GitLab セルフマネージド

• これは私たちのソースと宛先システムの最強の組み合わせの 1 つです。最良のケースで 1 ウェーブあたり 7,000 以上のプロジェクトをマイグレーションしました。
• 移行期間の最小化が懸念事項である場合、ウェーブあたりのプロジェクト数を最大化したいと考えます。
  • これを行うために、GitHub API レート制限設定を完全に制御する必要があります。
  • また、データ移動をサポートできるよう、GHE と GitLab SM インスタンス間に十分強力なネットワーク接続があることを確認したいと考えます。明確な数値はありませんが、多数の接続を介して数時間で数百 GB を移動することについて顧客に尋ねます。彼らのネットワークチームが回答できるはずです。
• 顧客がグループ/プロジェクトの構造を再編成したい場合、サポートできます（以下のよくある顧客リクエストを参照）。
• マイグレーションが正しく機能するためにメールアドレスを非公開ではなく公開にする必要があることを顧客が認識していることを確認してください。
• インポート呼び出しで特定の github ホスト名を指定できるようにする API の変更（github.com にデフォルト設定されない）を活用するため、GitLab セルフマネージドは 13.7 以降である必要があります。

GitHub Enterprise から GitLab SaaS

• 宛先システムのレート制限がこれらのマイグレーションの制限要因となります。gitlab.com のレート制限を制御することはできないため、これらはウェーブあたり 200〜300 でスコーピングする必要があります。
• インポート呼び出しで特定の github ホスト名を指定できるようにする API の変更（github.com にデフォルト設定されない）を活用するため、GitLab セルフマネージドは 13.7 以降である必要があります。
• マイグレーションが正しく機能するためにメールアドレスを非公開ではなく公開にする必要があることを顧客が認識していることを確認してください。

Github.com から GitLab セルフマネージド

• Github.com の API レート制限はユーザーごとに非常に低いため、顧客が提供する複数の userID を使用することで回避します。
• これを大規模に顧客に提供するまで、1 日あたりにマイグレーションされるプロジェクトの総数は 200 を超えるべきではありません。プロジェクト数の点で小規模に行ったことはあります。しかし、それらのプロジェクトの一部は巨大でした（70K 以上の Pull Request）。
• マイグレーションが正しく機能するためにメールアドレスを非公開ではなく公開にする必要があることを顧客が認識していることを確認してください。

Github.com から GitLab SaaS

• ソースと宛先システムの両方のレート制限によって制限されます。
• マイグレーションが正しく機能するためにメールアドレスを非公開ではなく公開にする必要があることを顧客が認識していることを確認してください。

Bitbucket ソース

注: Bitbucket のプロジェクトは GitLab のグループに相当します。Bitbucket のリポジトリは GitLab のプロジェクトに相当します。

Bitbucket Server から GitLab セルフマネージド

• 理論的には、このソース/宛先のペアでのマイグレーションは GHE から GL セルフマネージドと同じくらい高くスケールできるはずです。ウェーブあたりのプロジェクト数を 1,000 まで増やしても安全です。
• 移行期間の最小化が懸念事項である場合、ウェーブあたりのプロジェクト数を最大化したいと考えます。
  • これを行うために、BitBucket API レート制限設定を完全に制御する必要があります。
  • また、データ移動をサポートできるよう、BitBucket Server と GitLab SM インスタンス間に十分強力なネットワーク接続があることを確認したいと考えます。明確な数値はありませんが、多数の接続を介して数時間で数百 GB を移動することについて顧客に尋ねます。彼らのネットワークチームが回答できるはずです。
• 顧客がグループ/プロジェクトの構造を再編成したい場合、サポートできます（以下のよくある顧客リクエストを参照）。

Bitbucket Cloud から GitLab セルフマネージド

• GitLab には現在、Bitbucket Cloud からのインポートを開始するための API がありません。自動マイグレーションは不可能です。
• インポートを支援するために BB cloud import UI を使用する「魚の釣り方を教える」アドバイザリアプローチをポジショニングできます。

Bitbucket Server から GitLab SaaS

• GitLab SaaS のレート制限により制限されるため、スコーピングは低くなります（例: ウェーブあたり 200 プロジェクト）。

Bitbucket Cloud から GitLab SaaS

• GitLab には現在、Bitbucket Cloud からのインポートを開始するための API がありません。自動マイグレーションは不可能です。
• インポートを支援するために BB cloud import UI を使用する「魚の釣り方を教える」アドバイザリアプローチをポジショニングできます。

Team Foundation Server（TFS）/ Azure DevOps（ADO）から GitLab

Azure DevOps（旧称 Team Foundation Server）にはソースコードリポジトリ以上のものが含まれているため、ADO マイグレーションをスコーピングする際には追加の質問が必要です。ADO の 5 つの一般的なコンポーネントは次のとおりです。

• Azure Boards: バックログを通じて作業を計画、構造化、管理するためのアジャイルツールセット。GitLab の Issue または JIRA チケットに相当します。
• Azure Repos: バージョン管理システム。Git または Team Foundation Version Control（TFVC）をサポートします。
• Azure Pipelines: アプリケーションの継続的インテグレーションとデリバリーをサポートするビルドおよびリリースサービス。GitLab CI/CD に相当します。
• Azure Test Plans: 手動/探索的テストや継続的テストなど、アプリケーションをテストするための複数のツール。
• Azure Artifacts: パブリックおよびプライベートソースから Maven、npm、NuGet、generic などのパッケージを保存・共有するサービス。GitLab Package Registry に相当します。

その他の Git ベースの SCM

• 「ベア git」マイグレーション方法を使用してこれらの顧客をサポートできます。これは Import repo by URL UI またはコマンドライン（git push -u）を使って行います。
• 顧客はマイグレーションをサポートするために繰り返し処理する git URL のリストを提供する必要があります。
• git エンベロープ外のデータ要素（例: pull request コメント、ユーザーメンバーシップなど）はマイグレーションされません。git データ要素（ブランチ、コミット、ファイル、タグなど）のみがマイグレーションされます。

非 Git ベースの SCM

• CSV、ClearCase、SVN、TFVC などのソースについては、非自動マイグレーションをサポートできますが、これらのソースシステムに関する深い経験がないため、これらのエンゲージメントには考慮すべきリスクがあります。これらのソースシステムの専門知識を見つけるためにチャネルパートナーと連携することを検討してください。
• 顧客が宛先 GitLab システムでプロジェクトをどのように整理するかを調査・検討していることを確認してください。多くの場合、非 git SCM から git SCM への最初の変換時に、ソースコードの単一トランクを複数の git リポジトリに分割することがあります。

よくある顧客リクエスト

1. マイグレーション中にプロジェクトとグループを再編成できますか？

• congregate では、Github Enterprise と Bitbucket のソースシステムについてこれを実行できます。顧客は、source project url と destination parent path を含む .csv ファイルを提供して、プロジェクトが宛先システムのどこに配置されるかを伝える必要があります。また、この再編成を伴うマイグレーションの前に、顧客または当方が事前にグループ構造を作成する必要があります。新しいグループ階層の作成のための時間をスコープに追加する必要があります。
• ソースと宛先システムが GitLab の場合、これは強く推奨されません。直感に反しますが、GitLab にはリポジトリ構造外にプロジェクト/グループ構造内に存在する多くの他のデータがあり、それらを保持する必要があるため、再編成ステップはマイグレーション中に行うべきではありません。顧客がどうしてもこれを行う必要がある場合は、UI または API を使用してプロジェクトとグループのローカル移動を調整するマイグレーション前または後のステップとして行うことを推奨してください。
  • これは追加のマイグレーションアドバイザリ時間としてポジショニングできます。客観的なスコーピングを行うために、これが何の関数であるかを判断する必要があります。

2. 13.5 (またはいくつかの古いバージョン)を使用していますが、まだマイグレーションできますか？

• ソースと宛先のソフトウェアバージョンの差が大きいほど、マイグレーション中にデータ整合性が失われる可能性が高くなります。インポート機能を維持するチームは、ソースと宛先が互いに 2 マイナーリリース以下 離れている場合にインポータが動作するとドキュメント化しています。このため、顧客のソースインスタンスを宛先ソフトウェアバージョンと一致するか、2 マイナーバージョン以下にするためのアップグレードサービスを含めています。極端な状況でのみ、このガイダンスの例外を検討します。

その他のリソース

• マイグレーションサービスのデリバリー中に行われるステップを理解するのに役立つ、公開されている Migration Toolkit を参照してください。
• マイグレーションテンプレートプロジェクトの Customer フォルダ には、顧客がマイグレーションを準備するのに役立つドキュメントが含まれています。
• セルフマネージドから SaaS へのマイグレーション ハンドブックページには、gitlab.com へのマイグレーションに固有の詳細があります。

ページのソースコードを見る - ページの編集 - please contribute.