Jiraからデータを移す｜持ち出せるものと、手で作り直す部分
Jiraからデータを移す作業でつまずくのは、たいてい技術的な手順ではありません。何をどこまで運ぶかを決めないまま作業を始めてしまい、途中で「これも要る」「これは運べない」が次々に出てくるからです。公式の説明ページには、書き出せるものと書き出せないものが具体的に列挙されています。まずそれを確かめ、運べないものは手で作り直すか、運ばないと決める。この順番で進めれば、作業量は見積もれます。
作業を始める前に決める3つ
手を動かす前に、次の3つを決めてください。ここが曖昧なまま進めると、作業の途中で何度も引き返すことになります。
・どの範囲を運ぶか。全件か、進行中のものだけか、直近の期間だけか ・いつの時点で入力を止めるか。止めた日以降の分をどう扱うか ・移し終えたあと、元の環境をどうするか。読み取り専用で残すか、解約するか
1つ目がいちばん効きます。全件を運ぶと決めた瞬間、作業量は数倍になります。終わった案件まで運ぶ必要があるかどうかは、その情報を後で誰が見るかで決まります。年に数回、過去の経緯を確認するために見るだけなら、元の環境を一定期間残しておくほうが安上がりです。
2つ目は、移行の日を決める話です。動いているものを運ぶ以上、運んでいる最中にも新しい入力は発生します。「この日の何時以降は新しい側にだけ書く」という線を引き、その線を全員に伝えます。線が無いと、両方に書かれたり、どちらにも書かれなかったりします。
3つ目は費用に直結します。元の環境を残すなら、その期間の契約は続きます。年間の契約なら、次の更新の時期を起点に計画を引くと重なる期間を短くできます。読み取り専用で残す場合でも、利用者の数によっては費用が発生するので、契約の条件を先に確かめてください。
持ち出す経路は2つある
Jiraからデータを持ち出す方法は、大きく2つに分かれます。1つはサイト全体をひとまとめに書き出す方法、もう1つは条件で絞った一覧を表形式で書き出す方法です。
サイト全体の書き出しは、公式の説明では設定画面のシステムの項目にある「Backup manager」から行います。添付ファイルや利用者の画像、ロゴを含めるかどうかを選び、書き出しが終わるとファイルをダウンロードできる、という流れです。出てくるのは、Jiraが自分で読み込むための形式です。
表形式の書き出しは、課題の一覧を絞り込んでから、その結果をカンマ区切りのファイルなどで出す方法です。他の道具へ移すときに実際に使うのは、多くの場合こちらです。相手側がJiraの内部形式をそのまま読み込めることはまずないためです。
どちらを使うかは、移す先で決まります。同じJiraの別のサイトや、自社で持つ形の環境へ移すならサイト全体の書き出しが向きます。まったく別のサービスへ移すなら、表形式で出したうえで、相手の求める列に整える作業が発生します。
念のため両方を出しておく、という判断も現実的です。表形式のファイルで移行を進めつつ、サイト全体の書き出しを控えとして保管しておく。あとから「あの情報も要った」と気づいたときに、元の契約を解約したあとでも中身を確認できます。ただし、控えのファイルには利用者の情報や添付が含まれるので、保管の場所と期間は先に決めておく必要があります。
サイト全体の書き出しに含まれるもの
公式の説明ページでは、書き出せるデータが具体的に列挙されています。課題とその項目の内容（標準の項目と独自に追加した項目の両方）、ボードとスプリントのデータ、利用者と利用者のグループの設定、コメント、添付や画像などのファイル、そしてプロジェクトの構成に関する情報です。構成に関する情報には、ワークフロー、全体の権限、各種のスキーム、画面の定義、独自項目の設定、課題の種類、ボードの構成が含まれると書かれています。
この一覧を読むと、かなりの範囲が持ち出せるように見えます。実際、同じ製品の別の環境へ移す場合はそのとおりです。設定ごと持っていけるので、移行後に組み直す作業はほとんど発生しません。
ただし、他の道具へ移す場合、この「構成に関する情報」はほぼ使えません。ワークフローの定義も、画面の定義も、その製品の中でしか意味を持たないからです。移行先の道具には、その道具なりの設定の形があります。結果として、他社の道具へ移すときに実際に運ぶのは、課題そのものとコメント、添付、担当と期日といった実データに絞られます。
この事実は、移行の見積もりを大きく左右します。「設定も含めて全部運べる」と考えていると、移行先での組み直しの工数が計画から抜け落ちます。逆に、最初から設定は作り直すものと決めておけば、運ぶのは実データだけになり、作業はむしろ単純になります。
書き出せないものが明記されている
同じ説明ページには、書き出せないデータも列挙されています。自動化の設定、他社製のアプリとそのデータ、特定の警報や当番の仕組みに関する内容、資産の管理に関するデータ、アプリの利用権限の設定、そして着想を集める用途の製品における表示の構成や集計、投票の項目です。
とりまとめる立場で影響が大きいのは、最初の2つです。自動化の設定が運べないということは、いま自動で動いている処理をすべて洗い出し、移行先で組み直すか、手作業に戻すか、やめるかを決める必要があるということです。同じページには、自動化については手作業で書き出して取り込む方法が別に案内されている、とも書かれています。
他社製のアプリのデータも運べません。工程表の表示、時間の記録、帳票の出力といった用途でアプリを足している場合、そのアプリの中に溜まっているデータは別の手段で取り出す必要があります。アプリごとに書き出しの機能があるかどうかが違うので、移行を決める前に確かめておくべき点です。
ここでの実務的な教訓は、棚卸しの対象に「アプリの中のデータ」を必ず入れることです。本体のデータだけを見て計画を立てると、移行の直前になって「工数の記録が持ち出せない」といった問題が表面化します。
期間と権限に関する制約
書き出しの操作そのものにも、いくつか制約があります。公式の説明では、添付や画像、ロゴを含めて書き出す場合、次の書き出しまでに48時間を空ける必要があるとされています。試しに1回出して、内容を確認してからもう1回、という進め方をすると、2回目まで待つことになります。
復元についても期限が示されています。
Starting Jan 22, 2026, Backup Manager will limit restores from backups to those that are 30 days old or less. 出典: support.atlassian.com
2026年1月22日以降、復元に使えるのは30日以内に取ったものに限られる、という内容です。古い控えを長期保管して、必要になったら書き戻すという運用は成り立たなくなります。控えとして保管する意味は残りますが、それは中身を人が確認するためのものだ、と考えておくのが安全です。
権限の制約もあります。同じページには、組織の管理者が特定の環境や分類において書き出しを禁止できる、という記載があります。自分の権限では書き出しの画面自体が使えない場合があるということです。移行の計画を立てる前に、自分がその操作を実行できる立場かどうかを確かめておいてください。ここで止まると、社内の承認から取り直すことになります。
移す先だけでなく、いまの提供形態も確かめる
移行を検討する場面では、移行先の情報ばかりを集めがちです。ただ、いま使っている側の提供形態がどうなっているかも、移す時期の判断に影響します。見ておくのは、提供の終了が告知されていないか、新しい申し込みが止まっていないか、運営する会社に変更がないか、値上げや体系の変更が予告されていないかの4つです。
Jiraについては、自分のサーバーに置く形（Server）に関する記載が公式の資料にあります。データの取り込みに関する説明ページの冒頭には、クラウド以外での主な提供形態がData Centerであり、Serverの版はもう対応していない、と書かれています。自社で持つ形を続ける前提で計画していた場合、この点は前提から見直す必要があります。
面倒を見てもらえる期間についても方針が示されています。最初に出てから2年、という考え方で、公式の説明には2025年1月22日に出された版が2027年1月22日までという具体例が載っています。移行の時期を決めるとき、この日付が事実上の締切になる場合があります。
こうした情報は、移行の急ぎ具合を決める材料になります。期限が迫っているなら、多少の妥協をしてでも先に動く判断が要ります。期限に余裕があるなら、案件の切れ目まで待って、動いているものが少ない時期に移すほうが安全です。どちらにしても、期限を知らないまま計画を引くと、途中で急かされることになります。
同じ4点は、移行先の候補にも当てるべきです。移った先が新規の受付を止めていた、という話は現実に起きます。料金ページだけを見ても、この種の変化は見えません。会社からの告知の一覧と、更新情報のページを両方見ておくと確実です。
表形式で運ぶときの決まりごと
他の道具へ移すときに実際に使うのは、表形式のファイルです。逆方向、つまり他の道具からJiraへ取り込むときの決まりが公式に整理されていて、そこから表の作り方の考え方が読み取れます。
When importing large projects, we recommend splitting data in large CSV files into smaller batches and importing them separately. This will reduce performance issues and ensure optimal speed of the import. 出典: support.atlassian.com
同じページには、1つのファイルあたり1500件を推奨とし、取り込みにかかる時間の目安を1時間程度としています。件数が多い場合は分割して、混み合わない時間帯に行うことも勧められています。
ファイルの作り方についても具体的な条件が挙がっています。見出しの行に要約の列が必ず必要なこと、見出しの行には区切りのカンマ以外の記号を入れないほうがよいこと、値にカンマや改行が含まれる場合は引用符で囲むこと。表計算ソフトで作る場合、引用符の処理は自動で行われるとも書かれています。
この決まりは、移行先が別の道具であってもおおむね共通します。日本語の項目名をそのまま見出しに使うと、記号の扱いで取り込みに失敗することがあります。移行の作業をする前に、小さいファイルを1つ作って試し取り込みを行い、文字化けや列のずれが起きないかを確かめてください。10件で試して問題が無ければ、本番の件数でも同じように通ります。
添付ファイルは別の作業になる
表形式のファイルで運べるのは文字の情報だけです。添付ファイルは別の経路で移すことになります。
方法は移行先によって変わりますが、多いのは2つです。1つは、添付ファイルを一括で取り出して、移行先の対応する項目に手で貼り直す方法。もう1つは、添付を別の保管場所に置き、課題の本文にその場所への案内を書いておく方法です。
件数が多い場合、2つ目のほうが現実的です。すべての添付を貼り直す作業は、件数に比例して増えます。500件の課題にそれぞれ添付があるなら、1件1分でも8時間を超えます。過去の資料を参照する頻度が低いなら、保管場所を1つ決めて、そこに整理して置くだけで足ります。
判断の基準は、その添付が「これから使うもの」か「記録として残すもの」かです。進行中の案件の設計資料や画像は、移行先に貼り直す価値があります。終わった案件の請求書の控えのようなものは、保管場所に置いておけば十分です。この線引きを先にすると、貼り直す件数が大きく減ります。
人の対応付けを先に用意する
見落とされやすいのが、担当者や作成者の対応付けです。書き出したファイルに入っているのは、元の環境での利用者の識別子や電子メールのアドレスです。移行先では、それが誰なのかを紐づけ直す必要があります。
準備しておくべきなのは、対応表です。左に元の環境での表記、右に移行先での表記。この表を先に作っておくと、取り込みの作業が一度で終わります。
対応表を作るときに必ず出るのが、もう在籍していない人の扱いです。退職した人が担当のまま残っている課題、既に無効になったアカウントが作成者になっている課題。これらをどうするかを決めておかないと、取り込みの途中で止まります。実務では、退職者の分をまとめて特定の担当に寄せるか、担当を空にして本文に元の担当者名を残す形が採られます。
外部の協力会社のアカウントも同様です。移行先でもアカウントを発行するのか、社内の担当に寄せるのか。人数の区切りで費用が決まる道具に移す場合、この判断が費用に直結します。
履歴とコメントをどこまで運ぶか
課題の本体は運べても、変更の履歴は運べないことがほとんどです。「いつ誰が状態を変えたか」という記録は、その道具の内部の形式で保持されているためです。
コメントは、表形式のファイルに含めて運べる場合があります。ただし、1件の課題に対して複数のコメントがある構造を、1行1件の表で表すのは無理があります。実務では3つの選び方があります。コメントは運ばない、最新の数件だけを本文に追記する形で運ぶ、あるいは別の表として出して移行先の対応する形に整える。
多く採られるのは2つ目です。進行中の案件について、直近のやり取りだけが分かれば作業は続けられます。過去の全部のやり取りが必要になる場面は、実際にはほとんどありません。
判断の際に確かめておきたいのは、契約や検収に関わるやり取りが含まれていないかです。取引先との合意の経緯がコメントに残っている場合、それは記録として保存する価値があります。この場合は、運ぶかどうかではなく、書き出したファイルを保管しておくかどうかの話になります。保管の期間は、社内の文書管理の決まりに合わせてください。
設定は運ばず、作り直す前提で組む
ここまでの整理をまとめると、他の道具へ移すときに実際に運ぶのは実データだけです。設定は運べないというより、運んでも意味を持ちません。
これは悪い話ばかりではありません。移行は、積み上がった設定をいったん白紙にできる数少ない機会です。何年も選ばれていない種類や、常に空欄のまま送信されている入力欄を、そのまま置いていけます。
作り直すときの原則は、最小から始めることです。種類は2つか3つ、状態は4つ程度、必須の項目は表題と担当だけ。元の環境と同じ設定を再現しようとすると、移行の作業が終わらないうえに、使われていなかった設定まで持ち込むことになります。
現場から「前はこの項目があった」と言われたときに足せばよい、と考えてください。実際に言われる項目は、想像しているより少ないはずです。言われなかった項目は、無くても困らなかったということです。
運ぶ前に、止まっているものを片付ける
移行の作業を軽くする方法として、実はいちばん効くのが事前の整理です。運ぶ件数そのものを減らせば、あとの工程がすべて短くなります。
対象になるのは3種類あります。1つ目は、終わっているのに状態が閉じられていない課題です。実務では、完了したのに操作を忘れたまま残っているものが一定数あります。移行の前にこれを閉じるだけで、運ぶ件数が減ります。
2つ目は、3か月以上まったく動いていない課題です。動いていないものには理由があります。誰も担当していない、前提が決まっていない、あるいはもうやらないと決まったのに残っている。移行の前に担当者へ確認して、やらないものは閉じる判断をします。
3つ目は、重複している課題です。同じ内容が別々の言葉で2件登録されていることがあります。これも移行の前にまとめておくと、移行先で混乱を招きません。
この整理には副次的な効果もあります。作業を通じて、実際に動いているものの数が分かります。2000件あると思っていた課題が、動いているのは300件だった、という結果はよくあります。この数字が分かると、運ぶ範囲の判断が現実的になります。
整理の作業自体は、一覧からまとめて更新する操作で進められます。条件で絞って、該当するものを選び、まとめて状態を変える。1件ずつ開いて直していると終わらないので、この操作を先に覚えておいてください。
段取りの組み方
作業の順番は次のようになります。
・棚卸しをして、運ぶ範囲を決める ・小さいファイルで試し取り込みを行い、形式の問題を潰す ・人の対応表を作る ・入力を止める日を決めて全員に伝える ・本番の書き出しと取り込みを行う ・元の環境を読み取り専用にする
このうち、期間として長く見るべきなのは最初と最後です。棚卸しは関わる人が増えるほど時間がかかりますし、元の環境をいつ解約するかは契約の条件に縛られます。実際の取り込み作業そのものは、件数にもよりますが1日から2日で終わることが多いです。
並行して両方を動かす期間は、できるだけ短くしてください。二重の入力は必ず抜けを生みます。どうしても必要なら、期間を1週間以内に区切り、その間はどちらが正なのかを明示します。
移行の当日ではなく、その前後に手を打っておくことも効きます。前には、よく使う操作を5つ書いた1枚の手順を配ること。後には、最初の1週間だけ質問を受ける窓口をはっきりさせること。この2つがあるだけで、問い合わせの量が変わります。
書き出したファイルの置き場所を決める
書き出したファイルには、課題の内容だけでなく、利用者の情報や添付が含まれます。作業用の端末に置いたまま忘れる、というのがいちばん避けたい状態です。
決めておくことは3つです。どこに置くか、誰が触れるか、いつまで残すか。置き場所は、社内で共有の保管場所を使うのか、担当者の端末に置いて期間を区切るのかで変わります。取引先の担当者名や連絡先が含まれる場合は、社内の取り扱いの決まりに沿った場所を選ぶ必要があります。
個人に関する情報の扱いについては、個人情報保護委員会が事業者向けの案内を出しています。移行に伴って取引先の情報を含むファイルを一時的に外部の保管場所へ置く場合は、社内の規程と照らして問題が無いかを確かめてください。判断に迷う点は、所管の窓口や社内の法務の担当に確認するのが確実です。
残す期間も先に決めます。移行が終わって3か月経てば、参照する場面はほとんど無くなります。期間を決めずに置いておくと、何年も残り続けたうえ、誰の持ち物か分からなくなります。期限を決めて予定に入れておくのが、いちばん確実な管理です。
移した後の1か月で確かめること
運び終えた時点では、移行は半分しか終わっていません。残りの半分は、新しい側で入力が続くかどうかです。
最初の1週間で見るべきなのは、更新の頻度です。移した課題の状態が誰にも動かされないまま1週間過ぎたら、その板は使われていません。原因はたいてい2つで、入力の手数が多いか、見に行く習慣が無いかのどちらかです。前者なら必須の項目を減らし、後者なら朝の短い確認を習慣にしてもらいます。
2週目から3週目にかけて出てくるのが、「前の道具にあった機能が無い」という声です。ここで慌てて設定を増やさないでください。同じ声が3人から出たものだけを足す、という基準にすると、必要なものだけが残ります。1人の要望で項目を足していくと、移行前と同じ状態に戻ります。
1か月経った時点で確かめたいのが、二重管理が始まっていないかです。誰かが表計算ソフトで一覧を作り始めていたら、板の見せ方がその人の必要を満たしていません。理由を聞いて、その人が欲しい形の一覧を用意してしまうのが早い対処です。
そして、元の環境をいつ止めるかを判断します。1か月使って、過去の情報を参照した回数を数えてください。ゼロ回か1回程度なら、書き出したファイルを保管するだけで足ります。何度も参照しているなら、もう少し残す判断になります。感覚ではなく回数で決めると、迷いません。
移行先を選ぶときに確かめること
移行先の候補を見るときは、機能の一覧よりも、取り込みの経路がどう用意されているかを見てください。自動で取り込める仕組みがあるのか、表形式のファイルから読み込めるのか、それとも手で登録するしかないのか。ここが作業量を決めます。
こちら側の制約は先に書いておきます。ボード型のプロジェクト管理ツールとして提供している側の話として、自動で取り込めるのはTrelloからのデータだけです。他のサービスからのデータについては、表形式に整えて登録する形になります。あわせて、ソースコードのリポジトリを内蔵する機能はなく、自動化や外部サービスとの連携の豊富さで勝負する作りでもありません。画面は日本語のみです。移行の可否を具体的に確かめたい場合はTrelloからの移行に手順を、預けたデータの扱いの考え方は安全性の考え方にまとめてあります。
区切り方の違いも移行の判断に効きます。ボード型の中には機能で絞らず、区切るのは人数とボードの数だけという考え方を取っているものもあり、この場合は移行後に「この機能を使うには上の契約に」という説明が発生しません。使える範囲はできることに、費用の区切り方は料金に整理しています。
他の候補と並べたい場合は、形の近いものから見るのが早いです。国産のものならBacklogとの比較とJootoとの比較、海外のものならTrelloとの比較、Asanaとの比較、Notionとの比較、monday.comとの比較にそれぞれの向き不向きを書いています。候補が定まらない段階なら比較の一覧から見るのが早く、細かい条件はよくある質問で確かめられます。
移行の作業で本当に難しいのは、データを運ぶことではありません。運ばないものを決めることです。決めてから始めれば、作業は見積もりどおりに終わります。運ぶ範囲を決める会議を1回開き、そこで決めたことを書き残す。この1時間が、後の数十時間を左右します。
Q1. Jiraのデータはどこまで書き出せますか？
公式の説明ページには、課題と項目の内容、ボードとスプリントのデータ、利用者とグループの設定、コメント、添付などのファイル、プロジェクトの構成に関する情報が書き出せると記載されています。一方、自動化の設定、他社製アプリとそのデータ、資産の管理に関するデータなどは書き出せないと明記されています。
Q2. 書き出しに回数や期間の制限はありますか？
添付や画像、ロゴを含めて書き出す場合、次の書き出しまでに48時間空ける必要があると公式の説明にあります。また2026年1月22日以降、復元に使えるのは30日以内に取ったものに限られると記載されています。組織の管理者が書き出しそのものを禁止している場合もあるため、権限も先に確認してください。
Q3. 表形式のファイルは何件ずつに分けるべきですか？
公式の取り込みに関する説明では、1つのファイルあたり1500件を推奨し、所要時間の目安を1時間程度としています。件数が多い場合は分割し、混み合わない時間帯に行うことも勧められています。本番の前に10件ほどの小さいファイルで試し、文字化けや列のずれが無いか確認すると安全です。
Q4. 設定やワークフローも移行できますか？
同じ製品の別の環境へ移す場合は構成の情報ごと運べますが、他社の道具へ移す場合は形式が違うため実質的に運べません。設定は作り直す前提で計画してください。むしろ、使われていない種類や埋まらない項目を引き継がずに済む機会と考え、種類2つから3つ、状態4つ程度の最小から始めるのが定着します。