Content last updated 2025-12-19

チャネルパートナーマイグレーションサービス

GitLab はパートナーが GitLab への移行などのテクニカルサービスに関与し、リードすることを推奨しています。このページでは、さまざまな GitLab 移行先に対して転送できる、さまざまなデータソースを概観します。より深い技術的理解を得るために、エンジニアは GitLab University の GitLab Certified Migration Services Specialist Learning Path に登録して学んでください。

コンテンツを視聴覚形式で消費したい方で、かつ GitLab Partner でもある方は、GitLab Ecosystem Solutions Architects がこのハンドブックページのコンテンツや その他 を議論する以下の動画をご覧いただけます。このセクションのリンクについては、先に GitLab Partner Portal にログインしてから、リンクをクリックしてください:

GitLab パートナーの一般的な移行ステップ

このセクションのリンクについては、先に GitLab Partner Portal にログインしてから、リンクをクリックしてください:

顧客向けの移行で成功している GitLab パートナーは、クライアントエンゲージメントで次の例のような経路をたどることが多いです。

移行のスコープ／サイズ: ユーザー数は何人か? コードリポジトリはいくつか? グループ構造はそのまま維持するのか、それとも移行を機に GitLab 内の「未使用プロジェクトを整理」するのか? GitLab インスタンスおよび／またはグループ（サブグループを含む）のすべてのプロジェクトに関する情報を収集するために実行できるオープンソーススクリプト GitLab Evaluate の実行を検討してください。また、プロジェクトストレージ使用量の CSV レポートを作成する Project storage report の実行も検討してください。単一グループおよびセルフマネージドインスタンス上のすべてのプロジェクトのレポートがサポートされています。
顧客のビジネスを理解する: 移行すべきアーティファクトは何か? ユーザー、Issue、マージリクエストの監査コンプライアンス履歴は会社にとって重要か? それとも Git コードリポジトリの移行だけで十分か? お客様が移行に対して機密と考えるデータは何か? GitLab Partner Led Optimization Service を最初のステップとしたほうがよいか?
ヘルスチェック: インポートデータソースは健全か、それとも Readiness Assessment で GitLab ソースのヘルス状況を確認するべきか? クローンできない Git リポジトリや、クリーンアップが必要なリポジトリはあるか? 長期にわたる履歴を持つ大規模なコードリポジトリはあるか?
移行後のニーズ: 移行および GitLab または GitLab.com への採用の一環として構成が必要な、アクセス制御や Single-Sign-On (SSO) など、他のコンサルティング上の考慮事項はあるか?

技術的なスコープ／サイズに関する会話をお客様と行った後、GitLab パートナーは GitLab Channel Service Packages が役立つと感じるでしょう。これらにはテンプレートのデータシート、Statement of Work (SOW)、プロジェクトプランが含まれています。GitLab パートナーは、これらの GitLab Channel Service Packages をお客様の業務向けのテンプレートとして自由に利用できます。独自のテクニカルサービスオファリングに合わせてリブランド・リワードすることが推奨されます。表には、Aligned Partner Certification 列でパートナーが保有すべき認定に関する GitLab の期待も示されています。

GitLab Professional Services が提供する Migration Readiness Checklist は、活用できる役立つサンプルです。アクセス、コミュニケーション、ユーザー移行計画、移行準備、Wave 計画、移行後のチェック、移行後の検討事項、投資の最大化に関する技術的な要件が含まれています。本ドキュメントは GitLab の Congregate というオープンソースのコマンドラインインターフェース (CLI) 移行ツールの使用を前提としています。Congregate は GitLab Professional Services が推奨する方法です。

顧客の移行前・移行中・移行後の義務と責任とはと移行に必要なインスタンスアクセスと権限のレベルについて顧客と明確にコミュニケーションすることも、円滑な移行を確実にします。

同様に、GitLab Professional Services Delivery Kits の Migration グループも非常に役立ちます。これらのプロジェクトは「単一のアクティビティから Statement of Work (SOW) 全体まで、あらゆる作業の提供に関するステップバイステップの手順を提供する」ためです。

他の DevOps プラットフォームから GitLab へ

GitLab 以外のシステムからプロジェクトを移行するには、Supported import sources および Other Import Sources（同一ページ内のアンカーリンク）のリストを確認してください。

他システムからパイプラインを移行することは、付加価値のある手動の開発プロセスです。そのような移行のための自動化ツールも存在しますが、GitLab が公式にサポートしているものはありません。パイプラインの数、現在のパイプラインパフォーマンス、環境変数、使用されているシークレットを理解してスコープを設定することをパートナーに推奨します。パートナーは、他のソースシステムと GitLab のパイプライン構文との間でパイプラインを開発するコンサルティングを行う際に、タイム & マテリアル方式の契約が有用だと感じています。

Jenkins

GitLab Duo Agent Platform の Convert to GitLab CI/CD Flow は、これらの移行に大いに役立ちます。

Azure DevOps

GitLab Professional Services チーム自身が執筆した、Azure DevOps から GitLab への移行に関する詳細ガイドを参照してください。

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

セルフマネージドの GitLab サーバーから別の GitLab サーバーへ移行する最良の方法は、ソースインスタンスでフルバックアップを取り、ターゲットインスタンスでリストアすることです。ステップバイステップの手順は Migrate to a new server のドキュメントページで確認できます。

この移行方法はソースとターゲットインスタンスがまったく同じバージョンである場合にのみ機能することに注意してください。お客様の環境がそうでない場合（通常はソースシステムが遅れている）、Upgrade Path tool でソースシステムの必要なアップグレード計画を立てられます。（アップグレード前にフルバックアップを必ず取得してください！）

GitLab セルフマネージドから GitLab SaaS、またはその逆へ

顧客移行向けの 3 つの異なるオプションから選択するには、移行後のお客様のニーズを理解することが必要です。各方法の長所と短所を表形式で比較した完全な技術ページが Migration features に概説されています。Congregate は移行する機能の大半をサポートしていますが、Congregate を使用した GitLab.com への／からの移行は、GitLab.com SaaS（マルチテナント）データへのアクセスが制限されているため、GitLab Professional Services チームのサポートが必要です。移行サービスは他の方法の 1 つを使用することで達成できる場合があります。

これらの移行には 3 つの異なるオプションがあります。

1. Direct transfer

Direct transfer は、インスタンス間で顧客データを移動するための GitLab の組み込み機能です。これは移行を行うための推奨される方法です。この機能の最適な使い方に関する詳細な見識は、一般提供開始を発表したブログ記事を参照してください。

GitLab Log Analysis Tool

このツールは、direct transfer 移行が失敗した場合のデバッグに役立ちます。

GitLab ログ専用に調整された完全な ELK Stack（Elasticsearch、Logstash、Kibana）環境を立ち上げます。

リポジトリをクローンし、たった 1 つのコマンドで環境が準備完了です！顧客のログが自動的にインデックス化され、Kibana が事前構成済みダッシュボードと共に起動し、GitLabSOS、KubeSOS、GDK ログの即時の視覚分析を提供します。

2. File exports

direct transfer が対応できない、または対応しない場合のためのものです。良い例は air-gapped 環境です。

3. Congregate

file exports と同様に、direct transfer が対応できない／対応しない場合のために、Congregate があります。

これは GitLab Professional Services が使用しており、GitLab で最も成熟した移行ソリューションで、多くのオプションをサポートします。SaaS への移行は、GitLab SaaS（マルチテナント）データへのアクセスが制限されているため、GitLab PS の関与が必要であることに注意してください。 後者に関する詳細はこちらで確認できます。

Congregate について重要な点:

Air-gapped 環境

GitLab はオフライン環境でインストールおよび運用できます。このセットアップは移行プロジェクトをより複雑にします。

Direct transfer はこれをサポートしていません。Project/export import が回避策です。これを実行するための微妙な技術詳細については、GitLab Issue Direct transfer - Support for air-gapped solutions および maintain project and group file-based import/export as a workaround for migrations over air-gapped networks and to serve other use cases を参照してください。
GitLab のオープンソース CLI 移行ツール Congregate は Air-gapped 環境をサポートしています。Support air-gapped environment migrations および Migrating data in an air-gapped environment を参照してください。

パッケージ／コンテナレジストリの移行

推奨事項（Congregate の使用にかかわらず）: 「通常は、ソースコード移行後に GitLab でパイプラインジョブを確立し、これらのコンテナ／パッケージを希望どおりに GitLab レジストリにパブリッシュすることを顧客にお勧めしています。監査履歴の維持に関心のある顧客には、監査期間が終了するまで、ライセンス支出を削減しつつレガシーのパッケージ／コンテナレジストリツールを残しておくことをお勧めします。」

セルフマネージドの GitLab インスタンスから移行する際に監査履歴を保持する必要がある場合、良い選択肢は旧インスタンスのバックアップを保持することです。バックアップにはパッケージデータが含まれます。

古いパッケージの移行も必要な場合は、packages importer tool を使用できます。ドキュメントはこちらです。

GitLab Professional Migration Services

GitLab Professional Services チームは、直接の顧客向けに利用可能な完全なサービスカタログを提供しています。パートナーは、類似のプロフェッショナル（コンサルティング）サービスオファリングを提供するためのインスピレーションとしてオファリングを確認できます。

GitLab Professional Services Migration Package は人気のあるオファリングの 1 つです。

最終更新 June 14, 2026: Merge pull request #403 from kyama0/claude/cool-turing-ls6eck (bfd74782)

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