Jira Server から Jira Cloud への移行

このページの内容

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問

description Jira Server から Jira Cloud にデータを移行するための手順をご説明します。

This guide shows you how to use Jira's native site backup and restore functionality to move from Jira Server to Jira Cloud. The process described in this article can be used to migrate Jira Software, Jira Core, and Jira Service Desk from server or Data Center to cloud.

クラウドへの特定のプロジェクトのみの移行や、既存のクラウド サイトとの統合は、現在サポートされていません。しかしながら、アトラシアンでは現在、これをサポートするためのツールの開発に取り組んでいます。ご希望の移行がこれらのいずれかに該当する場合、機能リクエストをウォッチして最新情報を受け取るか、新しい Jira Cloud Migration Assistant の Early Access Program (EAP) にサインアップすることをおすすめいたします。

EAP がご要件に合わない場合、こちらで回避策の概要をご確認ください。

始める前に

移行を行う前に、いくつかの前提条件とベスト プラクティスについて確認しておく必要があります。移行を続行する前に、次のそれぞれの項目をご確認いただくことをおすすめします。

移行計画のリソースはご確認いただきましたか?

アトラシアンの計画リソースについて確認する

Start by reviewing our Jira migration planning guide and FAQs. These provide detailed step-by-step guidance from start to finish and will help you plan your migration approach. You can also find information about cloud and server comparisons, case studies, Atlassian Access and more in our Cloud Migration Center.

移行前に Jira Server をアップグレードする必要はありますか?

サポート対象バージョンについて確認する

現在ご利用のサーバー製品のバージョンによっては、移行前にアップグレードが必要な場合があります。以降でサーバー バージョンをご確認ください。

  • バージョン 7.13.1 以降: 移行前のアップグレードは不要です。
  • 7.6.0 ~ 7.13.0: アップグレードしてから移行することを推奨します。7.13.1 よりも前のサーバー バージョンでは、課題の作成日や履歴の日時を含むすべてのタイムスタンプが UTC として解釈されます。これらの日付が重要で、サーバー システムが UTC ではない場合、バージョン 7.13.1 以降にアップグレードすることをおすすめします。詳細についてはバグ レポートをご確認ください
  • 7.0.0 ~ 7.6.0: 7.13.1 以降にアップグレードしてから移行することを推奨します。7.0.0 と 7.6.0 の間のバージョンの移行は動作する可能性はありますが、これらのバージョンではアップグレードなしでの移行は保証されません。
  • ~ 7.0.0: 7.13.1 以降にアップグレードしてから移行する必要があります。

クラウド サイトへのサインアップは完了していますか?

クラウド サイトへのサインアップについて確認する

You’ll need a cloud site before you begin your migration. If you don’t already have one, there are a few ways to set one up:

  • Sign up for an extended cloud trial. This lets server and Data Center customers try cloud (Standard and Premium plans) at no cost — giving you time to assess, plan, test, and migrate from server to cloud without having to pay for both products at once.

  • Sign up for a free trial. Cloud trials start at 7 days, and can be extended to 37 days upon request if more time is needed for testing.

  • If you’ve decided on the Free plan, you can set up a site directly and use it to test a migration. Remember not to exceed your user and data limits. If you attempt to migrate more users than the plan allows, your migration will fail. Free plans don’t offer audit logs or the same permissions as Standard and Premium plans, so this isn’t a viable testing option if you ultimately intend to upgrade.

クラウド サイトに既存のデータがあるか、ユーザーがいますか?

既存のクラウド サイトに移行する場合の考慮事項を確認する

JIra のサイト バックアップを使用してそれを復元した移行を行うと、ユーザーとグループを除くすべてのサイト データが上書きされます。これには、プロジェクト、課題、および Jira 設定が含まれます。 

すべてのユーザーを上書きすることも、インポート ファイルのユーザーを既存のユーザーに統合することもできます。

  • すべてのユーザーを上書きすることを選択した場合、Confluence へのアクセス権のみを持つユーザーを含む、クラウド サイトのすべての既存のユーザーが削除されます。

  • ユーザーを統合した場合、インポート時にサーバー ユーザーの権限昇格が発生する可能性があります。クラウド サイトに統合するグループをよくご確認ください。 

この記事は、新しい Jira Cloud サイトへの移行を支援することを目的としています。データを持つ既存の Jira Cloud サイトと統合する必要がある場合、データが移行中に上書きされるのを防ぐため、Jira Cloud に移行する前に Jira Server でクラウド製品とサーバー製品のデータを統合する必要があります。

サーバー製品のセキュリティ セットアップは確認しましたか?

セキュリティ チェックについて確認する

多くの場合、Jira Server のセキュリティの一部は、Jira を企業ネットワークの内部で実行することで保証されています。クラウドに移行する前に、セキュリティ設定を確認し、必要に応じて更新することをおすすめします。 

  1. 未ログインの匿名ユーザーによる Jira Cloud のデータへのアクセスを禁止したい場合、移行前に Jira Server プロジェクトで使用されているすべての権限スキームを確認します。次の項目を確認することをおすすめします。
    1. 匿名アクセスがすべてのプロジェクトで禁止されていること。
    2. プロジェクトの閲覧権限に全ユーザー グループが追加されていないこと。
  2. ユーザーの参照グローバル権限がクラウドでの使用を意図してセットアップされているかどうかを客員します。
  3. データをエクスポートする前に、公開ダッシュボード、フィルター、またはアジャイル ボードでデータの漏えいが発生する可能性がないことを確認します。次のクエリを使用すると、ユーザーはこれらのアセットを確認する前に、少なくとも認証が必要になります。 

    update sharepermissions set sharetype = 'loggedin' where sharetype ='global';

ストレージの使用量はどれくらいですか?

クラウド製品でのストレージ制限について確認する

Atlassian's cloud plans have different storage limits. Before migrating, take a few minutes to check how much disk space you're currently using and review our cloud storage policy.

Have you learned about next-gen projects?

Learn more about Jira next-gen projects

What are next-gen projects?

Unlike self-hosted Jira, in cloud we also offer next-gen projects for Jira Software and Jira Service desk. As the name implies, next-gen projects are the newest project type, and are designed to empower autonomous teams who want to get up and running quickly. They're perfect for teams who want to easily jump in and design their own unique workflow, without the need for a Jira admin or added complexity.

Next-gen appeals to some teams because it helps reduce the complexity of Jira and the strict standardization of agile methodology. Next-gen allows teams to be fully autonomous, customize their project components (sprints, reports, etc), and adapt Jira to their workflows, not the other way around.

We're building next-gen Jira Software from the ground up, so it doesn't yet have all the features that our classic Jira Software does. You can keep track of what's been recently released and we're working on next at our Jira Software Cloud public roadmap.

Next-gen and migrations

By default, when you migrate from self-hosted to cloud your projects will be imported as classic projects – the project type you know and love today in self-hosted Jira.

We recommend continuing to work with classic projects initially, as they more closely match your server experience (although there are still navigational and UI differences). Over time, you can let your teams decide which is right as they adapt to working in cloud and learn more about next-gen capabilities and how it's evolving.

次世代プロジェクトと Portfolio for Jira Cloud

現在、Portfolio for Jira では次世代プロジェクトはサポートされません。Portfolio for Cloud を使用する予定がある場合、クラシック プロジェクトを引き続き使用することをおすすめします。

Portfolio for Jira を次世代プロジェクトに拡張するためのオープンな機能リクエストがあります。この機能の実装を希望する場合は投票を行うことをおすすめします。

移行手順

上記の質問を確認し、移行前のチェックを完了したら、移行を開始しましょう。

Jira Server から Jira Cloud への移行で必要な手順の概要は、次のとおりです。

  1. (任意) ユーザーとグループを CSV にエクスポート
  2. Jira Server データベースのバックアップ
  3. Jira Server の添付ファイル、プロジェクト アバター、およびロゴのバックアップ
  4. サーバーのデータベース バックアップの Jira Cloud へのインポート
  5. Jira Server の添付ファイル、プロジェクト アバター、およびロゴの Jira Cloud へのインポート
  6. サーバーにインポートされたグループの確認およびそれらへのアクセス権の付与
  7. サーバーからインポートされたグループに自身を追加
  8. 移行後のチェックを完了

Before starting, check that you have the right permissions on both the server and the cloud side:

  1. Jira Server: Jira システム管理者権限を持つグループに所属していることを確認します。
  2. In Jira Cloud: Check that you're in the site-admins group. If you've just created your new cloud site, you're the site administrator and will have the permissions you need.

If you don't have the required permissions, work with your Jira administrator to grant them before you begin your migration. Not having the right permissions will mean you won't be able to complete the migration and may see different information than what's indicated in the steps below.


(任意) ステップ 1: ユーザーおよびグループを CSV にエクスポート

ユーザーの管理に内部の Jira ユーザー ディレクトリを使用している場合、それらは Jira Server のデータベース バックアップに含まれるため、ステップ 2 に進んでください。

LDAP、AD、または Crowd などの外部のユーザー ディレクトリを使用している場合、ユーザーをクラウドに移行するためには 3 つのオプションを使用できます。

  1. 移行前にユーザーを内部の Jira ディレクトリに移動できます。認証の委任のために Jira を LDAP ディレクトリに接続している場合、このオプションをおすすめします。

  2. ユーザーおよびグループの数が少ない場合、サーバーのデータベース バックアップのインポート後にそれらをクラウドで手動で作成できます。

  3. ユーザーの数が多い場合 (50 人以上)、アトラシアンのサポート チームがユーザーおよびグループの移行を支援できます。

手順を確認

最初に、Jira Server データベースに対して次の SQL クエリを実行し、ユーザーおよびグループの CSV ファイルを作成します。

ユーザー

SELECT email_address AS mail,user_name AS username, display_name FROM cwd_user;

グループ

SELECT DISTINCT parent_name AS group, child_name AS username FROM cwd_membership;

次に、前のステップで作成した 2 つの CSV ファイルをアトラシアンのサポート チームに提供し、ユーザーおよびグループの Jira Cloud への移行を依頼してください。 

ステップ 2: Jira Server データベースのバックアップ

This step will back up your Jira Server database in a portable XML format. If you have multiple Jira applications on the same site, for example Jira Software, Jira Core and Jira Service Desk, this backup will contain all project types (Software, Business and Service Desk) by default. 

  1. Jira システム管理者権限を持つユーザーとしてログインします。
  2.  > [システム] の順に選択します。
  3. [インポートとエクスポート] > [システムをバックアップ] を選択して Jira のバックアップ ページを開きます。 
  4. [ファイル名] フィールドに、バックアップ ファイルの名前を入力します。
  5. [バックアップ] ボタンをクリックし、Jira データのバックアップが完了するのを待ちます。Jira はバックアップを Jira アプリケーションのホーム ディレクトリ (jira-home) の export サブディレクトリに、zip 化された XML アーカイブ ファイルとして保存します。この場所に書き込むために必要なファイル システム権限が Jira に与えられていることを確認します。
  6. バックアップが完了したら、確認メッセージが表示されます。これで、サーバーからファイルを取得できます。

ステップ 3: Jira Server の添付ファイル、プロジェクト アバター、およびロゴのバックアップ

添付ファイル、プロジェクト アバター、またはロゴを移行したい場合、それらも同様にバックアップする必要があります。これらは、Jira アプリケーションのホーム ディレクトリのサブディレクトリである、Jira アプリケーションの data ディレクトリに保管されています。 

このステップを完了するには、 /data/attachments、/data/avatars、および /logos/ ディレクトリの zip アーカイブを作成する必要があります。次の構造を使用していることを確認します。

attachments-1.zip
└─── data
		├── attachments
		│ 		├── ProjectKey1
		│ 				│ └── 10000
		│					│ ├── IssueKey-1
		│ 					│ ├── IssueKey-2
		│ 					│ └── IssueKey-3
		│ 		├── ProjectKey2
		│		└── ProjectKey3
		└── avatars
└── logos
手順を確認

data ディレクトリをバックアップするための特別な手順は提供していませんが、「データをバックアップする」でいくつかの考慮事項の概要を確認できます。

*nix サーバーでは次のようなコマンドを実行できます。

cd <Jira Home Dir> 
zip -r data.zip logos/ data/avatars/ data/attachments/

zip ファイルを作成したら、それをサーバーからローカルのワークステーションに転送する必要があります。これを行うための一般的な方法には、SFTP、rsync、wget、curl の使用が含まれます。

ステップ 4: サーバーのデータベース バックアップの Jira Cloud へのインポート

  1. 新しい Jira Cloud サイトに site-admin 権限を持つユーザーとしてログインします。

  2. > [Jira 設定] > [システム] の順にクリックします。

  3. [インポートとエクスポート] セクションで [システムの復元] をクリックします。

  4. [データのインポート] を選択し、「ステップ 2: Jira Server データベースのバックアップ」でダウンロードしたファイルを選択します。 
  5. Jira によってファイルの確認が行われ、データのインポート方法の設定を選択するプロンプトが表示されます。
    1. First, select your outgoing mail setting. Whichever option you choose, you can manually change after you migrate in the outgoing mail settings.
      1. You can choose to Enable outgoing mail, which allows Jira to send automated emails for interactions – for example, new comments on issues or issue transitions.

      2. If you choose to Disable outgoing mail, Jira won't send automated emails for interactions.

    2. 次に、サーバー サイトのユーザーでクラウド サイトのユーザーを上書きするか、それらと統合するかを選択します。

      1. [overwrite] を選択すると、Confluence および Jira のすべてのユーザーが、バックアップ ファイルのユーザーで上書きされます。

      2. ユーザーの [merge] を選択すると、グループも統合されます。クラウド サイト (Jira または Confluence) のグループと同じ名前を持つグループがサーバー インスタンス内に見つかった場合、ユーザーはサーバーのグループからクラウドのグループに統合されます。サーバー グループにはクラウド グループの権限が適用されます。このオプションを選択する場合、権限昇格の可能性をよくご検討ください。

  6. [インポートの実行] をクリックします。インポートの進捗を追跡できるページに転送されます。バックアップのサイズによっては、インポートの完了に時間がかかる場合があります。
  7. インポートが完了すると、確認画面に転送されます。
  8. メディア (添付ファイル、ロゴ、プロジェクト アバター) を引き続きインポートする必要がある場合、ここで [メディアのインポート] を選択します。アプリケーション アクセスを管理する前に [インポートとエクスポート] ページに戻る必要があります。このステップを完了済みの場合、またはメディアのインポートを計画していない場合は、[アプリケーション アクセスを付与] をクリックしてステップ 6 にスキップできます。

このステップのトラブルシューティング

バックアップ ファイルのフォーマット

インポートする前に、バックアップ ファイルを解凍し、ファイル構造が以下のようになっていることを確認します。

JIRA-backup-20161021
├── activeobjects.xml
├── entities.xml

次のエラーが発生した場合:

Import error

There was an error importing file JIRA-backup-20161021.zip: Validation failed. The following issues were reported:

The import archive doesn't contain entities.xml file.

XML ファイルを直接 zip 化するのではなく .xml ファイルを含むフォルダを zip 化している可能性があります。

XML に無効な文字がある場合

Jira Cloud へのインポートの前に、バックアップから無効な文字を削除する必要がある場合があります。このドキュメントを確認し、移行計画に含めることをおすすめします。

インポートが進まない場合

インポート中、次のパーセント値 / ステップで時間がかかる場合があります。 

  1. 50% - データベースのアップグレード中
  2. 90% - ユーザーおよびグループのインポート中

これは通常の挙動です。完了までお待ちください。

ユーザー名またはメール アドレスでエラーが発生した場合

クラウドへの移行を完了するにあたり、ユーザー名やメール アドレスの監査を行う必要がある場合があります。主に次の点を確認します。

  1. すべてのメール アドレスはトップレベル ドメインで終了している必要があります。たとえば、john_doe@company.com を含まないため無効であり、インポートをブロックします。

  2. すべてのメール アドレスは有効なドメインを使用している必要があります。たとえば、example.com は有効なドメインと認識されないため、john_doe@example.com は許可されません。 

  3. すべてのユーザーが一意のメール アドレスを持っている必要があります。次のクエリを使用して、重複したメール アドレスを持つユーザーを特定できます。 

    select email_address, count(*) from cwd_user group by email_address having count(*) > 1
  4. addon_ から始まるユーザー名は名前を変更するか削除する必要があります。このプレフィックスは Atlassian Marketplace アプリ用に予約されています。この問題は、過去にアトラシアンのクラウド製品からの移行を行っている場合に発生することがあります。

クラウドでマッピングする必要があるリンクがある場合

At this step, you may see a list of URLs for Atlassian server sites. To make sure links point to the new Jira Cloud site instead of the old server site after you migrate:

  1. Select the URL of the Jira server instance you're importing to cloud from the list.
  2. [インポートを実行] をクリックして移行を続行します。

ステップ 5: Jira Server メディアの Jira Cloud へのインポート

  1. 新しい Jira Cloud サイトに site-admin 権限を持つユーザーとしてログインします (まだ行っていない場合)。

  2. > [Jira 設定] > [システム] の順にクリックします。

  3. [インポートとエクスポート] セクションで [システムの復元] をクリックします。

  4. [メディアのインポート] を選択し、「ステップ 3: Jira Server の添付ファイル、プロジェクト アバター、およびロゴのバックアップ」で作成およびダウンロードしたメディア zip を見つけて選択します。
  5. This will take you to a page where you can track your import progress. It may take a while for your import to finish, depending on the size of your file.
  6. インポートが完了すると、確認画面に転送されます。
  7. メディアをさらにインポートする必要がある場合、すべてのメディア ファイルのインポートが完了するまでこのステップを繰り返します。次のメディアをエクスポートする前に、前回のメディア インポートが正常に完了したことを新しいタブでテストすることをおすすめします。

このステップのトラブルシューティング

大規模なファイルのインポートに失敗する場合

大規模なファイルのインポートに失敗したり、完了に時間がかかったりする場合があります。

ファイルが 10 GB よりも大きい場合、バックアップを 2 ~ 5 GB に分割してそれぞれを個別にインポートする必要がある場合があります。ファイル構造は次のようにします。

attachments-1.zip 
└─── data 
		├── attachments 
		│ 		├── ProjectKey1 
		│ 				│ └── 10000 
		│ 					│ ├── IssueKey-1 
		│ 					│ ├── IssueKey-2 
		│					│ └── IssueKey-3 
		│ 		├── ProjectKey2 
		│ 		└── ProjectKey3 
		└── avatars 
└── logos
attachments-2.zip 
└─── data 
		└── attachments 
				├── ProjectKey4 
				├── ProjectKey5 
				└── ProjectKey6 
attachments-3.zip 
└─── data 
		└── attachments 
				└── ProjectKey#

詳細な手順については「Jira エクスポートの一部を Jira Cloud にインポートする方法」をご参照ください。

添付ファイルのインポートが進まない場合

添付ファイルのインポート ステップには、アップロード、処理、および実際のインポートを含む独自のフェーズがあります。大規模な添付ファイルの処理フェーズで中断が発生する場合があります。これが起こった場合、ページが突然リロードされ、以降は進捗やメッセージが表示されなくなります。

問題が発生しなかった場合、処理ステップのあとに次のようなメッセージが表示されます。

Attention

This will import non-database content (such as attachments and avatars) into your Jira instance. You should only do this after a full database import because the full import will remove any existing data that you import using this page.

This operation could take anywhere from several minutes to several hours depending on the size and number of attachments.

Note that this operation cannot be undone.

これが表示された場合、処理は完了しています。[Proceed] ボタンをクリックし、添付ファイルのインポートを完了します。

処理中にインポートに失敗した場合、添付ファイルを小規模な zip ファイルに分割してそれぞれを個別にインポートします。

ステップ 6: サーバーにインポートされたグループの確認およびそれらへのアクセス権の付与

クラウド サイトにすべてのデータをインポートしたら、サーバーからインポートされたグループを確認し、アクセス権を付与する対象を決定する必要があります。 

セキュリティ上の理由により、インポート プロセスで既定のアプリケーション アクセス設定の適用や新規ユーザーへのアクセス権の付与が自動的に行われることはありません。ユーザーがログインできるようにするためには、管理者がアプリケーション アクセスを付与する必要があります。

  1. 新しい Jira Cloud サイトにログインして > [Jira 設定] > [ユーザー管理] の順にクリックします。
  2. [サイト設定] セクションで [製品アクセス] を選択します。
  3. [Review imported groups] を選択し、既定グループのアクセスを確認します。

インポートにより、既定の Jira Server グループ Jira-administrators は Jira Cloud で administrators に変更される点にご注意ください。

ステップ 7: サーバーからインポートされたグループに自身を追加

セキュリティ上の理由により、移行を実行しているユーザーのグループ設定はインポートされません。つまり、移行を実行したユーザーは自分自身を以前のグループに再度追加する必要があります。これは、https://admin.atlassian.com の [グループ] セクションまたは [ユーザー] セクションで行えます。

ユーザー セクションで行う場合

  1. https://admin.atlassian.com に移動します。
  2. 複数のクラウド サイトをお持ちの場合、移行を行ったクラウド サイトを選択する必要があります。
  3. [ユーザー管理] セクションで、[ユーザー] を選択します。
  4. 自身のプロファイルを見つけます。
  5. ... アイコンをクリックします。
  6. [ユーザーをグループに追加] を選択します。
  7. 自身を追加する必要があるグループを選択します。
  8. [グループに追加] をクリックします。

グループ セクションで行う場合

  1. https://admin.atlassian.com に移動します。
  2. 複数のクラウド サイトをお持ちの場合、移行を行ったクラウド サイトを選択する必要があります。
  3. [ユーザー管理] セクションで、[グループ] を選択します。
  4. 自身を追加する必要があるグループを選択します。
  5. [メンバーを追加] を選択し、自身をグループに追加します。 
  6. 残りのグループについて、必要に応じて手順を繰り返します。

ステップ 8: 移行後のチェックを完了

移行のタイプによっては、移行の完了後に実行が必要な操作があります。移行後の推奨事項の完全な一覧については、「Jira 移行計画ガイド」を参照してください。

このステップのトラブルシューティング

クラウドへのインポート後にコンテンツが "Admin" に紐付けられている場合

クラウド サイトの管理者に影響する既知の不具合があります。データをクラウドにインポート後、サーバーで自身のアカウントに紐付けられていたコンテンツが "Admin" に紐付けられる場合があります。この問題が発生した場合、問題の解決の支援をアトラシアンのサポート チームにお問い合わせください。

その他のトラブルシューティング

移行中に問題が発生した場合、アトラシアンのさまざまなリソースを活用できます。最初に、アトラシアンの公開課題トラッカーで既知の問題を検索することをおすすめします。Jira の移行で発生する一般的な問題についての情報 (ステータスや推奨される回避策など) を見つけることができます。

次のような既知の問題があります。

詳細情報とサポート

移行をサポートする多数のチャネルをご用意しています。


最終更新日: 2019 年 9 月 14 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.