Redmineからデータを移す｜持ち出せるものと、手で作り直す部分
Redmineから別の道具へ移すとき、いちばん気になるのは「これまでの記録がどこまで運べるのか」です。結論から書くと、チケットの本文と主要な項目はほぼ運べます。運べないのは、番号、更新の履歴、権限の設定、リポジトリとの紐づけです。この記事では、持ち出しの経路が3つあることと、それぞれで何が落ちるのかを順に見ていきます。
移す前に、何を運んで何を捨てるかを先に決める
移行の作業で時間を食うのは、書き出しや取り込みそのものではありません。「これは運ぶのか」を1件ずつ判断している時間です。だから先に線を引きます。
線の引き方は3つあります。1つ目は期間です。閉じてから1年以上経ったチケットは運ばない、と決める。2つ目はプロジェクト単位です。稼働中のプロジェクトだけ運び、終わったプロジェクトは元のRedmineを読み取り専用で残す。3つ目は状態です。開いているチケットだけ運び、閉じたものは運ばない。
現場でいちばん揉めにくいのは2つ目です。プロジェクト単位なら、判断する対象が数十件に収まります。1件ずつ見る必要がありません。
そして、運ばないと決めたものをどう保存するかを同時に決めます。元のRedmineをそのまま止めずに、書き込みだけできなくして残しておくのがいちばん手間が少ない方法です。自分で立てているRedmineなら、全員の役割を閲覧のみに変えるだけで済みます。数か月経って誰も開かなくなったら、そのときに落とします。
ここを決めずに始めると、移行の途中で「終わった案件も見たい」という声が出て、作業がやり直しになります。実際、移行が止まる原因の多くはデータの技術的な問題ではなく、この線引きの合意が取れていないことです。
持ち出しの経路は3つある
Redmineからデータを取り出す方法は、大きく3つです。それぞれ取れるものと手間が違います。
1つ目は、画面からのCSV書き出しです。チケットの一覧を絞り込んで、下にある書き出しのリンクからCSVを落とします。管理者でなくても、閲覧できる範囲なら誰でもできます。いちばん手軽ですが、後述する上限があります。
2つ目は、REST APIです。Redmineは自分のデータの一部をAPIで公開していて、XMLとJSONの両方の形式に対応しています。プログラムを書ける人がいるなら、これがいちばん取りこぼしが少ない経路です。
3つ目は、データベースの複製です。自分で立てているRedmineなら、MySQLやPostgreSQLのダンプを取れば、そこに全部入っています。ただし、そのダンプをそのまま読める移行先はまずありません。中を解析して必要な表を取り出す作業が要ります。時間はかかりますが、失われるものはゼロです。
クラウドで提供されているRedmineを使っている場合、3つ目は自分では取れません。提供元にデータを出してもらう形になります。この作業が有償のオプションになっている場合があるので、後段で触れます。
どれを選ぶかは、移行先が何を受け取れるかで決まります。移行先がCSVの取り込みしか持っていないなら、APIで丁寧に取っても入り口が無いので意味がありません。先に移行先の受け取り口を確かめてから、経路を選びます。
CSVで書き出すときに、まず引っかかる上限
CSVでの書き出しには、設定で決まっている件数の上限があります。公式の設定説明にはこう書かれています。
Issues export limit. Maximum number of issues contained in CSV and PDF exports. Default: 500 出典: redmine.org
つまり、初期状態では1回の書き出しで500件までしか出ません。チケットが3,000件あるプロジェクトを1回で落とそうとすると、途中で切れます。しかも警告が目立つ形で出るとは限らないので、切れていることに気づかないまま作業を進めてしまうことがあります。
対処は2つです。管理者であれば、この上限の設定値を一時的に大きくしてから書き出します。数万件に上げると書き出しに時間がかかり、途中で止まることがあるので、様子を見ながら上げます。管理者でない場合は、絞り込みを分けて複数回に分けます。作成日の年ごと、プロジェクトごと、といった分け方が扱いやすいです。
分けて出した場合は、必ず合計件数を確かめます。元のチケット一覧に出ている件数と、落としたCSVの行数の合計が一致するかどうか。ここを数えずに進めると、後で「あの案件が無い」と言われたときに、どこで落ちたのか追えなくなります。
書き出す列も、既定のままにしないでください。書き出しの画面では、表示している列だけを出すか、すべての項目を出すかを選べます。移行のときは、すべての項目を選びます。表示していない独自項目が入っているケースがあるためです。
CSVで運べるものと、運べないもの
CSVで出せるのは、チケットの一覧に列として並べられる値です。具体的には、番号、プロジェクト、トラッカー（種別）、ステータス、優先度、題名、担当者、作成者、開始日、期日、進捗率、予定工数、親チケット、独自項目、そして説明の本文です。
運べないものははっきりしています。
・コメントの履歴です。CSVには最新の説明文しか入りません。誰がいつ何を書いたかというやり取りは、この経路では出ません ・項目の変更履歴です。ステータスがいつ変わったか、担当者がいつ替わったかという記録は、CSVには含まれません ・添付ファイルです。ファイル名すら列には出ません ・関連するチケットの紐づけです。親子は親チケットの列で運べますが、「関連する」「先行する」といった関係は出ません
コメントの履歴を運びたい場合、CSVでは足りません。APIかデータベースの複製が要ります。ここで判断が分かれます。多くのチームでは、閉じたチケットのコメントまで運ぶ必要はなく、開いているチケットについてだけ、直近のやり取りを本文に貼り付ける形で足りています。全件のコメントを運ぶには、その分だけ手間と時間がかかることを見込んでおきます。
REST APIで取れる範囲は、資源ごとに完成度が違う
APIを使う場合、資源ごとに扱いの安定度が違う点に注意します。公式の一覧では、Issues と Projects と Users と Time Entries と News が Stable、Attachments が Beta、Wiki Pages や Journals や Issue Relations や Versions や Custom Fields が Alpha と記載されています。
Stable は仕様が固まっていて大きな変更が予定されていないもの、Beta は使えるが不具合や不足があるもの、Alpha は主要な機能はあるが利用者からの反応を待っている段階のもの、という区分です。
移行で効いてくるのは、Journals が Alpha だという点です。Journals はチケットの更新履歴、つまりコメントと項目の変更の記録です。ここが Alpha ということは、取得はできるが、細かい挙動が期待どおりとは限らないということです。実際に少数のチケットで試してから、全件に広げます。
もう1点。APIの一覧を取るときは、1回の応答に含まれる件数に上限があります。全件を取るには、位置をずらしながら繰り返し呼ぶ形になります。この繰り返しの途中で、誰かがチケットを更新すると、並び順がずれて取りこぼしが起きます。取り込みの最中は、Redmine側を読み取り専用にしておくのが確実です。
APIを使う前提として、管理画面でREST APIの利用を有効にする必要があります。利用者ごとのAPIキーは、個人設定の画面から確認できます。クラウドで提供されているRedmineの場合、プランによってAPIの利用可否が違うことがあるので、契約内容を確かめます。
添付ファイルは、別の作業として組む
添付ファイルは、どの経路でも別立ての作業になります。
自分で立てているRedmineなら、ファイルはサーバのファイル置き場に保存されています。設定ファイルで置き場所を指定していて、そこを丸ごとコピーすれば実体は手に入ります。ただし、保存されているファイル名は元のファイル名ではなく、重複を避けるための名前に変わっています。どのチケットのどのファイルなのかは、データベースの表と突き合わせないと分かりません。
APIを使う場合、添付ファイルの一覧と、それぞれのダウンロード用のURLは取れます。1件ずつ落としていく形になります。件数が数千あると、それなりの時間がかかります。
現実的な進め方は、こうです。まず添付ファイルの総数と総容量を数えます。開いているチケットに付いているものだけに絞ると、たいてい1割以下になります。その1割だけを運び、残りは元のRedmineを読み取り専用で残して参照できるようにする。この形なら作業は1日で終わることが多いです。
移行先の容量制限も先に確かめます。総容量が移行先のプランの上限を超えていれば、そもそも全部は入りません。ここは移す前に計算しておく数字です。
必ず切れるものが4つある
どの経路を使っても、移行で必ず切れるものがあります。先に知っておくと、現場に説明しやすくなります。
1つ目は、チケットの番号です。Redmineの番号は連番で振られていて、移行先では別の番号が振られます。過去のメールや議事録に「#1234の件」と書いてある参照は、すべて別のものを指すことになります。対策としては、移行先に「旧番号」という独自項目を作って、そこに元の番号を入れておく方法があります。CSVの列を1つ増やすだけなので手間は小さく、後から効きます。
2つ目は、記録の日時です。移行先に取り込むと、作成日時と更新日時は取り込んだ日になります。元の日付を残したいなら、独自項目として持たせるしかありません。並べ替えや絞り込みに使うなら、日付の形式で作ります。
3つ目は、権限の設定です。役割と権限の組み合わせは、製品ごとに考え方が違うので、そのまま移すことはできません。ここは手で作り直します。作り直す前に、現在の役割の一覧と、それぞれが何をできるのかを紙に書き出しておきます。移行先の権限が粗い場合、いくつかの役割を1つにまとめる判断が要ります。
4つ目は、リポジトリとの紐づけです。コミットのメッセージにチケット番号を書くと、そのチケットに変更履歴が表示される仕組みは、Redmine側に紐づけの設定があって初めて動きます。移行先が別の考え方で作られていれば、この結びつきは切れます。ソースの履歴を見る場所は別に持つ、と割り切るのが現実的です。板の型の道具には、そもそもリポジトリを閲覧する機能が入っていないのが普通です。
独自項目とワークフローの置き換え
Redmineで長く使っていると、独自項目が増えます。受注番号、原価コード、顧客名、検収の予定日といった値が、チケットの中に入っています。ここが移行のいちばん厄介な部分です。
まず、独自項目の一覧を出します。管理画面から見られます。そのうえで、1つずつ次の3つに分けます。
・移行先にも同じ形式の項目を作れる。テキスト、日付、数値、選択肢はたいてい作れます ・移行先には無い形式なので、別の形で持つ。真偽値のチェックボックスをラベルで表す、といった置き換えです ・そもそも使われていない。作ったが空欄のままの項目は、意外と多くあります
3つ目を先に落とすと、作業量が減ります。値が入っているチケットの件数を数えれば、使われているかどうかはすぐ分かります。1割未満のチケットにしか値が入っていない項目は、移さずに済むことがほとんどです。
ワークフローについては、置き換えではなく作り直しになります。Redmineが持っている状態の遷移の定義は、種別と役割の掛け合わせで表の形になっており、この構造をそのまま受け取れる道具はほとんどありません。表を書き出して眺め、実際に使われている経路だけを抜き出す作業から始めます。使われていない経路が半分以上あることは珍しくありません。移行先が板の形なら、列の並びがステータスの流れそのものになります。列を作るときに、どの列からどの列へ動かしてよいかを運用の約束として決め直します。
置き換えの候補を機能ごとに見比べるなら、できることに並んでいる項目と、いま使っている独自項目の一覧を突き合わせるのが確実です。一覧に無いものは無い前提で組みます。
クラウド版から出るときの手続きと費用
自分で立てているRedmineなら、データは手元にあります。クラウドで提供されているRedmineを使っている場合は、出るときの手続きが要ります。
たとえば、ファーエンドテクノロジーが提供する My Redmine では、解約時のバックアップデータ取得がオプションサービスとして用意されています。同社は、このオプションの料金を2026年11月1日から改定すると告知しています。
バックアップデータ取得（解約時用）通常対応 現行料金（2026年10月31日まで）3,500円 新料金（2026年11月1日より）5,000円 出典: hosting.redmine.jp
同じ告知には、作業開始日を指定する場合が6,000円から10,000円へ、日時まで指定する場合が10,000円から15,000円へ改定されると記載されています。表示は税別です。また、2026年10月31日までに作業を実施した場合は現行料金、11月1日以降に実施した場合は新料金という扱いも書かれています。
金額の多寡より、段取りに時間が要るという点が重要です。日時を指定する場合は追加の費用がかかるということは、通常は「いつ作業されるか」をこちらでは決められないということです。解約日から逆算して、余裕を持って申し込む必要があります。移行の日程を組むときは、この待ち時間を先に見込みます。
なお、どのサービスを使う場合でも、契約前に「解約時にデータをどの形式で受け取れるか」「有償か無償か」「申し込みから受け取りまで何日か」の3点を文書で確かめておくと、次の移動が楽になります。データの持ち出しについての考え方は安全性の考え方にも整理してあります。
移行の手順を7つに分ける
ここまでの内容を、実際の順番に並べ直します。
- 運ぶ範囲を決める。プロジェクト単位で線を引き、運ばないものは元のRedmineを読み取り専用で残す
- 移行先の受け取り口を確かめる。CSVの取り込みがあるか、列の対応をどう指定するか、1回に何件まで入るか
- 独自項目の一覧を出し、使われている項目だけに絞る。移行先に同じ形式があるかを1つずつ確かめる
- 元のRedmineを読み取り専用にする。取り込みの最中に更新が入ると、取りこぼしが起きる
- 書き出す。CSVなら上限に注意し、分けて出したら合計件数を照合する
- 少数で試す。まず20件だけ取り込んで、列の対応と文字化けと改行の扱いを確かめる。ここを飛ばして全件入れると、やり直しになる
- 全件を取り込み、件数と、抜き取りで10件ほどの中身を照合する
6番の試し取り込みで、いちばんよく出るのは改行の扱いです。チケットの説明に改行が入っていると、CSVの行がずれることがあります。取り込み側が引用符の中の改行を正しく扱えるかどうかは、20件で試せば分かります。
もう1つよく出るのが、担当者の名前の一致です。Redmineの利用者名と、移行先の利用者名が違うと、担当者が空欄で入ります。先に利用者の一覧を移行先に作り、表記を揃えておきます。取り込みの手順そのものは製品ごとに違うので、Trelloからの移行のような移行の説明ページを、書き出しの前に一度読んでおくと段取りが立てやすくなります。
移した直後の2週間に起きること
取り込みが終わって、件数も合った。ここで移行が終わったと考えると、たいてい2週間後に元へ戻ります。移した直後には決まった順番で問題が出るので、先に挙げておきます。
最初の数日に出るのは、探せないという声です。Redmineでは、絞り込みの条件を保存して、名前を付けて呼び出す使い方が定着しています。「自分の担当で期限切れ」「今週が期日のもの」といった条件を、それぞれが持っています。移った先では、この保存した条件が全部無くなっています。移行の日に合わせて、よく使われていた条件を移行先でも作っておくと、この声はほとんど出ません。管理画面から、公開されている保存条件の一覧を見れば、何が使われていたかは分かります。
次の週に出るのは、通知が多すぎるという声です。移行先の初期設定は、たいてい通知が広めに出るようになっています。Redmineでは通知の範囲を細かく決めていたのに、移った先で全部が届くようになると、数日でメールを読まなくなります。読まなくなると、期日の連絡も届かなくなります。移行の翌日には、通知の設定を全員分そろえて見直します。
2週間目に出るのは、入力が止まる現象です。移行の直後は全員が新しい画面を意識して触りますが、通常の忙しさが戻ると、元の習慣に引っ張られます。ここで効くのは、会議で開く画面を新しいほうに固定することです。会議で映る画面が新しい道具なら、その前日に更新されます。逆に、会議で別の資料を映していると、道具の中身は更新されなくなります。
この3つは、どれもデータの問題ではありません。移行の計画に、取り込みの後の2週間を作業として入れておくかどうかで、結果が変わります。
移行を止めてしまう3つの場所
移行が途中で止まる原因は、だいたい決まっています。技術的に難しいから止まるのではなく、次の3つで止まります。
1つ目は、決裁の途中で範囲が広がることです。「せっかく移すなら、あの部署のデータも一緒に」という話が出て、対象が2倍になる。対象が広がると調整の相手が増え、日程が後ろへずれ、そのうち担当者が別の仕事に引っ張られます。範囲を広げる提案が出たら、今回の対象は変えず、次の段として日付を分けて置きます。
2つ目は、完璧に移そうとすることです。コメントの履歴も、添付ファイルも、閉じたチケットも全部。ここを目指すと、作業量が数倍になります。しかも、その大半は移した後に一度も開かれません。開いているチケットと直近1年の更新だけに絞れば、作業は数分の1になります。残りは元のRedmineを読み取り専用で残せば、参照はできます。
3つ目は、書き込みを止める日を決めないことです。日付が決まっていないと、片方に入れ続ける人が残り、どちらが正しいのか分からない期間が続きます。この状態が1か月続くと、移行そのものが失敗したと判断されます。日付は、取り込みの作業を始める前に決めて、全員に伝えます。
止まらないための現実的な進め方は、対象を1つのプロジェクトに絞って最後まで通すことです。1つ通すと、手順の抜けと所要時間が実測で分かります。その実測をもとに残りを見積もれば、日程が根拠のあるものになります。全プロジェクトを同時に動かすより、結果として早く終わります。
並行して動かす期間をどう決めるか
移行の日を1日決めて、その日から全員が新しい道具に移る。この進め方は、うまくいくときと、大きく崩れるときの差が激しいやり方です。
崩れるのは、移行先の設定が固まりきっていない場合です。列の並びや通知の設定を触りながら使うことになり、使う人からすると「毎日画面が変わる」状態になります。これが数日続くと、元のRedmineに戻ってしまいます。
安全なのは、期間を区切って両方を動かす形です。ただし、両方に同じ内容を入れる二重入力は2週間が限度です。それを超えると必ず片方が放置されます。
現実的な区切り方は、新しく発生する作業だけを新しい道具に入れ、既存のチケットは元のRedmineで閉じきる、という分け方です。新規と既存で場所が分かれるので、二重入力は起きません。既存のチケットが減っていけば、自然に片方だけになります。この形なら、期間は1か月から2か月を見ておけば足ります。
いずれの形でも、いつ元のRedmineへの書き込みを止めるかを、最初に日付で決めて全員に伝えます。日付が決まっていないと、いつまでも古いほうに書き込む人が残ります。
文字コードと改行で崩れる場所
取り込みの段階で最も多い失敗は、文字コードと改行です。どちらも原因がはっきりしていて、先に手を打てます。
文字コードは、Redmineの書き出しの画面で選べます。日本語環境ではShift_JISが選ばれていることがあり、この形式で出したものを取り込むと、環境依存の文字が化けます。丸囲みの数字、ローマ数字、単位の記号、一部の漢字が対象です。移行先がUTF-8を受け取れるなら、書き出しの時点でUTF-8を選びます。選べない場合は、書き出した後に変換します。
改行は、チケットの説明に複数行が入っているときに起きます。CSVでは、値の中の改行を引用符で囲んで表すのが決まりですが、取り込む側がこれを正しく扱えないと、1件のチケットが複数行に分かれて読み込まれます。件数が合わない原因の多くはここです。
対策は、先に20件で試すことです。試す20件には、必ず「説明が長くて改行が多いチケット」と「環境依存の文字が入っているチケット」を混ぜます。ふつうの短いチケットだけで試すと、どちらの問題も表面化しません。ここで問題が出れば、書き出しの設定を変えるか、間に変換の手順を挟むかを決められます。
もう1つ、日付の形式も確かめます。Redmineの表示形式は設定で変えられるため、書き出したCSVの日付が年月日の並びなのか、月日年の並びなのかが環境によって違います。取り込み側が別の並びで読むと、日付が意味のない値になります。20件の試しのときに、期日が正しく入っているかを目で確かめておきます。
移行の判断材料を、3つの数字で持つ
最後に、移行を進めるかどうかを判断するときに手元に持っておく数字を挙げます。どれも今のRedmineから取り出せます。
1つ目は、運ぶ対象のチケット件数です。開いているチケットの件数と、直近1年に更新のあったチケットの件数。この2つが分かれば、作業の規模が見えます。数百件なら手作業でも足り、数千件を超えるならAPIかデータベースの複製を検討する分岐点になります。
2つ目は、独自項目のうち実際に値が入っているものの数です。ここが多いほど、移行先の選択肢は狭まります。10個を超えるなら、移行先の独自項目の上限を必ず確かめます。
3つ目は、添付ファイルの総容量です。移行先の容量の上限と比べて、収まるかどうか。収まらない場合、開いているチケットの分だけに絞る判断が要ります。
この3つの数字を並べると、移行にかかる時間の見当が付きます。そのうえで、移行先の料金体系を見ます。人数で費用が動く体系と、人数では動かない体系があり、チームの人数の見込みによって総額が大きく変わります。条件の並べ方は料金のページで比べられます。移行そのものより、移った後で使い続けられるかどうかのほうが、結果に効いてきます。移った先で出る細かい疑問はよくある質問にまとめてあるものが多いので、書き出しの前に目を通しておくと、確かめるべき点が具体的になります。
Q1. Redmineのチケットをまとめて書き出す方法はありますか？
チケット一覧の画面からCSVで書き出せます。ただし初期設定では1回の書き出しが500件までという上限があります。管理者ならこの設定値を上げられます。管理者でない場合は、作成年やプロジェクトで絞り込んで複数回に分け、最後に合計件数を照合してください。
Q2. コメントの履歴も移せますか？
CSVでの書き出しには含まれません。運ぶにはREST APIかデータベースの複製が必要です。ただしAPIの更新履歴（Journals）はAlpha扱いなので、少数で試してから全件に広げてください。開いているチケットの直近のやり取りだけを本文に貼る形で足りる場合も多くあります。
Q3. 移行すると必ず失われるものは何ですか？
チケットの番号、作成日時と更新日時、役割ごとの権限の設定、リポジトリとの紐づけの4つです。番号と日付は、移行先に独自項目を作って持たせれば残せます。権限は手で作り直すことになるので、現在の役割の一覧を先に書き出しておいてください。
Q4. クラウド版のRedmineから出るとき、費用はかかりますか？
サービスによります。ファーエンドテクノロジーの My Redmine では解約時のバックアップデータ取得が有償のオプションで、2026年11月1日から通常対応が税別3,500円から5,000円に改定されると告知されています。契約前に受け取れる形式と費用と所要日数を確かめておくと安全です。