Azure DevOps データ移行ツールの概要

Azure DevOps データ移行ツールを使用して、忠実度の高いデータベースを移行する前に、この記事の基本的な概念をいくつか学習してください。

[作業の開始] ステージを順番に強調表示した図。

移行されるデータについて説明します

すべてのデータが移行されるわけではありません。 レポートデータや SharePoint データなど、コレクション外のデータベースを分離しても移行されません。 次のセクションでは、移行されるデータの詳細を示します。

付属データ量

次の表に、移行に含まれるデータを示します。

付属データ量 説明
コレクション マッピング Azure DevOps Server の各コレクションは、1 つのデータベースに対応します。 移行中、作業項目、履歴、Team Foundation バージョン管理 (TFVC) 変更セット、Git データ、ビルド定義など、コレクション全体が Azure DevOps Services に移行されます。 作業項目、TFVC 変更セット、Git コミット番号/ID メイン変更されません。

除外されたデータ

次の表に、移行における特定のデータ除外を示します。

除外されたデータ 説明
Extensions 移行後に拡張機能を再インストールする必要があります。 ローカル拡張機能をプライベート拡張機能として Marketplace に公開し、アカウントと共有する必要があります。
サービス フック サービス フック データは移行に含まれません。移行後に再構成します。
ロード テスト ロード テスト データは引き継がれない。移行後にロード テストを再構成します。
パイプライン エージェントとエージェント プール 移行後にパイプライン エージェントとエージェント プールを再構成します。
メンション 作業項目ディスカッションのユーザー メンションは、新しい Microsoft Entra ID ではなく、オンプレミス ID を保持します。 ユーザー名をポイントしても連絡先のカードが表示されないため、一部のハイパーリンクが無効な場合があります。
Project Server の統合 Azure DevOps Services では使用できません。 たとえば、XAML ビルド、Microsoft Test Manager、SharePoint、SQL Data Warehouse などです。
プレビュー機能 Azure DevOps Server の一部の機能は、Azure DevOps Services への移行中にプレビューできます。

プロジェクトの制限

コレクションに多数のプロジェクトが含まれている場合、Azure DevOps Services では 1 組織あたり 1,000 プロジェクトの制限が課されますが、300 以下をお勧めします。 このしきい値を超えると、Visual Studio から組織に接続するなど、特定のエクスペリエンスが低下する可能性があります。 制限内に収まるようにするには、コレクションを分割するか、古いプロジェクトを削除することを検討してください。

オンプレミス データベースと Azure DevOps 組織の関係を理解します。

移行の計画について深く掘り下げすぎる前に、データベース移行プロセスがどのように機能するかを管理者特権で理解しておくことが重要です。 移行は、次のメインの概念に基づいて動作します。

  • チーム プロジェクト コレクション: Azure DevOps Server のコレクションは、チーム プロジェクトとその成果物の物理コンテナーです。 各コレクションは 1 つの SQL データベースに相当し、Azure DevOps Services への移行のソースです。
  • Azure DevOps Services 組織: 組織は、クラウドでホストされるサービスの管理単位です。 論理的には、1:1 は Azure DevOps Server のチーム プロジェクト コレクションの概念にマップされます。 そのため、組織は Azure DevOps Services への移行先となります。 たとえば、Azure DevOps Services 組織は、Contoso が Azure DevOps Services 組織の名前を表す場所として https://dev.azure.com/Contoso 表されます。

チーム プロジェクト コレクション SQL データベースを移行すると、データ移行ツールによって、ユーザー指定の名前を持つ新しい Azure DevOps 組織が作成されます。 コレクション データベースを既存の Azure DevOps Services 組織に移行したり、複数のコレクション データベースを 1 つの Azure DevOps Services 組織に統合したりすることはできません。 マッピングは、チーム プロジェクト コレクションと Azure DevOps Services 組織の間で厳密に 1 対 1 です。

データ センターの選択

Azure DevOps Services 組織を設定するときに、データの場所を選択できます。 最初のサインアップと組織の作成中に、ニーズに合ったリージョンを選択します。 後で移行に使用するには、リージョンの短縮コードを書き留めておきます。 詳細については、「移行でサポートされているリージョン」を参照してください。

価格について

通常、移行に伴う問題は、会社が Azure DevOps Services を使用するために必要なライセンスの種類です。 良いニュースは、あなたがすでに必要とするすべてのライセンスを持っている可能性が高いことです。 ほとんどのケースに対応するサンプル ワークシートを作成しました。 状況に関する具体的な質問がある場合は、開発者ソリューション販売スペシャリストまたは Microsoft リセラーにお問い合わせください。 詳細については、「Azure DevOps の価格」を参照してください。

ユーザー ライセンス ワークシート

# 列 1 列 2
1 チーム メンバーの数
2 利害関係者の数
3 行 (1) から行 (2) を減算します*
4 #of Visual Studio サブスクライバー**
5 行 (3) から行 (4) を減算する
6 行 (5) から行 (5) を減算します***
  • *利害関係者は無料です
  • ** Visual Studio サブスクライバーには、サブスクリプションの特典として Azure DevOps Services が含まれています
  • 各 Azure DevOps Services 組織には、5 人の無料ユーザーが付与されます

機能にアクセスするためのコスト効率の高いオプションの詳細については、課金の 概要 と Azure 料金計算ツールを 参照してください

Visual Studio Marketplace または Azure portal を使用して、必要な Azure DevOps Services ユーザー ライセンスを購入します。 テスト実行の準備フェーズでは、 このプロセスについて詳しく説明します

コア機能に加えて、Azure DevOps では次の付加価値サービスを利用できます。役に立つ可能性があります。

  • ホスト型ロード テスト サービス: 負荷の下にあるアプリケーションのパフォーマンスをシミュレートして分析する必要がある場合、Azure DevOps はホスト型ロード テスト サービスを提供します。 これらのサービスを使用すると、アプリケーションをストレス テストし、ボトルネックやパフォーマンスの問題を特定できます。
  • テスト マネージャー拡張機能: 包括的なテスト管理を行う場合は、Test Manager 拡張機能の使用を検討してください。 これらの拡張機能は、テスト ケース管理、探索的テスト、テスト実行追跡などの機能を提供することで、テスト機能を強化します。
  • その他の機能: Azure DevOps には、特定のニーズに対応するさまざまな拡張機能と統合が用意されています。 Microsoft 以外のツールと統合する場合でも、セキュリティを強化する場合でも、デプロイ パイプラインを自動化する場合でも、さまざまなオプションがあります。

これらのサービスの一部には追加コストが発生する場合があるため、それに応じて要件と予算を評価することが不可欠です。 これらのコストは、関連するサブスクリプションの請求書に表示されます。 詳細については、「課金の設定」を参照してください。 状況に関して具体的な質問がある場合は、DevOps パートナー、Microsoft リセラー、または Microsoft Developer Solutions Sales スペシャリストに問い合わせて、パーソナライズされたガイダンスを確認してください。

新しい組織を予約する

移行プロジェクトのタイムラインを考慮して、最終的な移行で目的の名前を使用できるように、早い段階で組織の名前を予約することをお勧めします。

たとえば、会社が Contoso で、名前が一致する組織が必要な場合は、 https://dev.azure.com/contosoその名前の組織を今すぐ作成できます。 ただし、新しい Azure DevOps Services 組織にのみ移行できることに注意してください。

組織名を予約するには、次の手順を実行します。

  1. 初期予約:
    1. たとえば https://dev.azure.com/contoso-temporary、一時的な名前を持つ組織を作成します。
    2. この一時的な名前は、将来の移行のために予約してください。
  2. 最終的な移行:
    1. 最終的な移行を開始する準備ができたら、それを組織に https://dev.azure.com/contoso-temporary 実行します。
    2. 移行が成功したら、予約された組織の名前を変更して、インポートした組織の目的の名前を開きます。 名前の変更がすぐに行われるときに、名前を解放するのに最大 1 時間かかる可能性があるため、削除するのではなく名前を変更します。
    3. 移行した組織の名前を、名前を変更してクリアした名前に変更します。たとえば、 https://dev.azure.com/contosoこの名前をすぐに変更します。
    4. 必要に応じて、この時点で最初に予約および名前を変更した組織を削除できます。

このアプローチに従うことで、希望する組織名を確実に再メイン利用できるようにしながら、スムーズに移行できます。

次のステップ