Lychee Redmineからデータを移す｜持ち出せるものと、手で作り直す部分
Lychee Redmineからデータを移すことを検討しているなら、最初に確かめるのは移行先の機能ではありません。いま入っている情報をどんな形で持ち出せるのか、その持ち出しにいくらかかるのか、いつなら無料なのか。この3点が分かっていないまま乗り換えを決めると、契約が切れた後に「あの情報が取り出せない」という事態になります。ここでは、公開されている資料で確かめられる範囲から、持ち出しの実際を整理します。
持ち出しの入り口は、3つある
データを外に出す方法は、大きく3つに分かれます。それぞれ取れるものと手間が違うので、先に整理しておきます。
1つ目が、提供元からバックアップデータを受け取る方法です。データベースの中身をまるごと受け取る形になるため、情報の抜けはいちばん少なくなります。ただし、受け取ったものをそのまま別の道具に入れられるわけではありません。読み解いて必要な部分を取り出す作業が別に要ります。
2つ目が、画面からの出力です。チケットの一覧をCSVで書き出したり、ガントチャートをPDFで出力したりする形です。手軽ですが、取れるのは画面に出ている範囲に限られます。添付ファイルや、チケットに付いたコメントの履歴は、この方法では丸ごとは取れません。
3つ目が、REST APIを使って自分で取り出す方法です。価格表の機能表を見ると、REST APIの利用は有料プランの機能として並んでおり、フリープランは対象外と示されています。プログラムを書ける人が社内にいれば、必要な項目だけを選んで構造化された形で取り出せます。移行先が決まっていて、その形式に合わせて整えたい場合は、この方法がいちばん融通が利きます。
この3つには、取れる情報の深さに順番があります。バックアップは全部入っているが読み解く手間が大きい。APIは必要な範囲を選べるが書ける人が要る。画面からの出力は誰でもできるが取れる範囲が狭い。手間と網羅性が反比例する構造なので、どれか1つで済ませようとすると、必ずどこかで無理が出ます。
多くのチームでは、この3つを組み合わせることになります。全体の保全としてバックアップを受け取り、実際に移すデータはCSVかAPIで取り出し、参照用に工程表のPDFを残す。この形が現実的です。
解約時のバックアップは、1回だけ無料になる
いちばん重要なのが、バックアップデータの受け取り条件です。公開されている価格表には、この項目が明記されています。費用は解約時に1回のみ無料、それ以外のタイミングでの提供を希望する場合は75,000円から（1回あたり、税別）とされています。
提供されるデータの中身も、3つが挙げられています。Redmineのデータ（データベースのダンプデータ）、チケットやWikiなどへの添付ファイル（インストールディレクトリのfiles以下をtar.gz形式で圧縮したもの）、そしてSubversionのデータ（ダンプデータ）です。
この条件から、実務上の判断が2つ導けます。
1つは、乗り換えを決めたら解約のタイミングを移行計画の中心に置くべきだということです。無料で受け取れるのは解約時の1回だけなので、その1回で必要なものが全部揃う状態にしておく必要があります。解約を申し出る前に、移行先で何が必要になるかを洗い出しておかないと、追加で受け取るたびに75,000円からの費用が乗ります。
もう1つは、検討の途中で中身を確かめたいなら費用がかかるということです。「移せるかどうか判断するために、まずデータを見せてほしい」という進め方は、解約前だと有料になります。判断材料が要るなら、CSVの出力やAPIで自分で取り出せる範囲から先に確かめるほうが安く済みます。
なお、契約期間はクラウド版が6ヶ月または12ヶ月です。解約のタイミングは自由に選べるわけではないので、次の更新日から逆算して移行の日程を組むことになります。
ダンプデータを受け取った後に、何をするか
データベースのダンプデータは、そのままでは読めません。移行先に入れるには、いくつかの段階を踏みます。
まず、ダンプを読み込める環境を用意します。価格表の記載によれば、対象になるデータベースはPostgreSQLかMySQLです。移行の作業を依頼する側の説明として書かれている項目ですが、出てくるデータの形式も同じ系統になります。データベースを扱える人が社内にいない場合、この時点で外部に依頼するか、別の方法に切り替えるかの判断が要ります。
読み込めたら、必要なテーブルから情報を取り出します。Redmineの構造を土台にしているため、チケット、プロジェクト、ユーザー、コメントの履歴、カスタムフィールドの値といった単位で並んでいます。移行先の形式に合わせてCSVに整形する作業がここに入ります。
添付ファイルは別に届きます。tar.gz形式で圧縮された、インストールディレクトリのfiles以下です。ここで注意が要るのは、ファイルの実体とチケットの紐づけです。ファイル名が元のまま保存されているとは限らず、データベース側の情報と突き合わせないと、どのファイルがどのチケットのものか分かりません。この突き合わせが、移行作業の中で最も手間のかかる部分になることがあります。
Subversionのデータも同じくダンプの形です。バージョン管理を別のサービスに移すなら、この形式から読み込める先を選ぶ必要があります。
作業量の目安を出すのは難しいのですが、チケットが数千枚の規模で、添付ファイルが数千個ある環境なら、データベースを扱える人が数日から1週間ほどかかると見ておくと、計画が崩れにくくなります。
逆方向、つまり入ってくる側の費用も公開されている
参考までに、他のRedmine環境からデータを持ち込む場合の条件も価格表に載っています。移行の考え方を知るうえで、こちらも読んでおく価値があります。
費用は75,000円から（1回あたり、税別）で、対応は平日の日中のみとされています。利用者側が用意するのは、Redmineのデータベースのダンプデータ（PostgreSQLかMySQLのいずれか）と、添付ファイルのデータ（インストールディレクトリのfiles以下）です。
そして、注意事項として次の4点が明記されています。SubversionとGitのデータは対象外であること。一部のデータや、特定のプロジェクトやユーザーのデータのみを取り出しての移行はできないこと。1つのRedmineのデータが移行の対象であること。複数のRedmineのデータを1つの環境に集約することはできないこと。
この4点は、移行という作業の性質をよく表しています。データベースまるごとの移し替えは比較的やりやすい一方で、「この案件だけ移したい」「2つの環境を1つにまとめたい」という要望は、まるごとの移し替えでは対応できません。部分的な移行が必要なら、CSVやAPIで自分で取り出して入れ直す形になります。
出ていく側でも、同じことが言えます。過去の案件は置いていって、動いている案件だけ移したい、という要望はよく出ますが、これはバックアップデータの受け取りでは解決しません。動いている案件のチケットをCSVで書き出して、移行先に入れるほうが早くなります。
移した先で、手で作り直すことになるもの
データが移っても、そのまま同じように使える状態にはなりません。移行を経験したチームからよく聞くのは、データより設定の作り直しに時間がかかったという話です。手で作り直すことになるものを挙げます。
・ワークフローの定義。どの役割がどの状態にチケットを動かせるかの設定は、道具ごとに考え方が違うため、そのままは移りません ・ロールと権限の設計。誰が何を見られて何を編集できるかの設計も、移行先の権限モデルに合わせて作り直します ・カスタムフィールド。項目名は移せても、選択肢の並びや必須の設定は入れ直すことが多くなります ・工程表の依存関係。棒と棒を結ぶ線の情報は、移行先が同じ形式を持っていないと失われます ・通知の設定。誰にどのタイミングで通知するかは、個人ごとの設定であることが多く、まとめては移せません ・ダッシュボードの構成。どのパネルをどう並べるかは、移行先の画面に合わせて組み直します
このうち、いちばん時間を取られるのがワークフローとカスタムフィールドです。細かく作り込んでいた環境ほど、作り直しに時間がかかります。移行を機に、使っていない項目を落とす整理をするチームが多いのは、このためです。
逆に、比較的そのまま移りやすいのは、チケットのタイトル、説明、担当者、期日、ステータスの名前、コメントの本文といった、テキストで表現される情報です。移行の計画を立てるときは、「テキストで表現できるものは移る、設定として表現されているものは作り直す」という線で分けると、見積もりがぶれません。
オンプレミス版を使っている場合の、期限の話
自社のサーバーで動かしているオンプレミス版は、条件が違います。価格表では「タイムドライセンス」と呼ばれており、利用期間が定められたライセンスで、利用期間の後はアンインストールする、と明記されています。
つまり、契約を止めた時点でプラグインは使えなくなります。ここで重要なのは、土台になっているRedmine自体は自社のサーバーで動き続けるという点です。Redmineはオープンソースなので、プラグインを外した状態のRedmineとして残せます。チケット、プロジェクト、コメント、添付ファイルといったRedmine標準の情報は、自社のデータベースの中にあり続けます。
これが、クラウド版とオンプレミス版の最も大きな違いです。クラウド版では、データは提供元が契約するAWS上にあり、受け取るには前述の手続きが要ります。オンプレミス版では、データベースは最初から自社の管理下にあるので、いつでも自分でダンプを取れます。
ただし、Lycheeのプラグインが独自に持っていた情報は、プラグインを外すと画面から見えなくなります。ガントチャートの配置、工数の集計の設定、EVMの基準線といった、プラグイン側の機能に紐づく情報がこれにあたります。データベースの中にテーブルとして残っていたとしても、読み解いて使える形にするのは自力の作業です。
オンプレミス版から移る場合の段取りとしては、ライセンスの期限が来る前に、必要な情報をCSVやPDFで書き出しておくことをおすすめします。期限を過ぎてプラグインを外した後では、画面から出力する手段がなくなります。
移行のタイミングを、いつに置くか
移行の日程を決めるとき、押さえておくべき制約が4つあります。
1つ目が契約期間です。クラウド版は6ヶ月または12ヶ月が最低契約期間で、サーバーのオプションを追加した場合は初回3ヶ月から、2回目以降は12ヶ月からとされています。オンプレミス版は初回3ヶ月から、2回目以降は12ヶ月からです。途中で止めても、契約期間の分は残ります。
2つ目が、バックアップデータの受け取りが解約時の1回のみ無料である点です。解約の手続きと、データの受け取りと、移行先での確認を、同じ時期に並べる必要があります。受け取ったデータに不備があったときに、もう一度もらうと75,000円からかかるので、受け取り後の確認は入念に行ってください。
3つ目が、案件の切れ目です。動いている案件の途中で道具を替えると、同じ案件の情報が2つの場所に分かれます。可能なら、大きな案件が1本終わるタイミングに合わせて切り替えるほうが、混乱が少なくなります。
4つ目が、いま提供元の側で起きている状況です。運営会社は2026年9月3日付で、製品サイトのサーバー障害を告知しました。2026年9月10日を過ぎてもこの案内は取り下げられておらず、製品の情報を載せていたページは開けないままです。既存の契約者が使う環境と製品サイトは別ですが、問い合わせの経路が通常と違う状態が続いています。解約やデータの受け取りについて相談するなら、運営会社側に用意されている窓口を使うことになります。往復に時間がかかると見込んで、日程には余裕を持たせてください。
なお、サービスの終了や運営会社の変更を示す告知は、公開されているお知らせとプレスリリースを2024年末までさかのぼっても見当たりません。2026年に入ってからも新機能のリリースが続いています。一方で料金は動いており、2026年5月28日付で2026年7月1日からのクラウドご利用価格の改定が告知されました。ここには、すでに契約している側への配慮も書かれています。
2027年6月30日までは現在の価格体系で契約更新できます。 2027年7月1日以降の契約更新より、新価格が適用されます。 出典: web.archive.org
移行を検討する理由が費用であれば、この猶予をどう使うかも判断の材料になります。2027年6月までは現行の体系で更新できるので、その間に移行先を吟味する時間は取れます。逆に、その先の更新から金額が変わるなら、次の次の更新日を締め切りとして逆算する組み立てになります。
CSVで書き出す範囲を、先に決めておく
バックアップデータを待たずに、いま自分でできることがあります。チケットの一覧をCSVで書き出しておくことです。これは検討の段階からできますし、費用もかかりません。
書き出すときに決めるのは、列の選び方です。全部の列を入れると、移行先で使わない項目まで抱えることになり、整形の手間が増えます。実務で必要になるのは、だいたい次の範囲です。
・チケットの識別番号、タイトル、説明 ・プロジェクト名、トラッカー、ステータス、優先度 ・担当者、作成者 ・開始日、期日、完了日 ・予定工数、実績工数 ・親チケットの識別番号 ・実際に値が入っているカスタムフィールドだけ
ここに含まれないもので、後から欲しくなるのがコメントの履歴です。一覧のCSVには、通常コメントの本文は含まれません。過去のやり取りが判断の根拠になっている案件では、この部分が抜けると困ります。有料プランで使えるREST APIなら、チケットごとにコメントの履歴を含めて取得できるので、必要なら早い段階でこの方法を試しておいてください。
もう1つ、書き出しておくと後で助かるのがガントチャートのPDFです。料金ページの機能表にはガントチャートのPDF出力が並んでいます。工程表の依存関係は移行先に構造としては移りませんが、当時どう計画していたかの記録としてPDFが残っていれば、引き直すときの下敷きになります。案件ごとに1枚ずつ出しておくだけで、移行後の作業が軽くなります。
書き出したCSVとPDFは、社内の共有ドライブに案件ごとのフォルダを作って置いてください。移行が終わった後も、過去の経緯を確かめる場面は必ず来ます。契約が切れた後に「あの案件の当初の期日はいつだったか」を調べる手段が、これしかなくなります。
移行先を選ぶときは、出口の条件も確かめる
一度乗り換えを経験すると分かるのですが、道具を選ぶときに見るべき項目に「出口」が加わります。次に移るときに、どんな形でデータを持ち出せるのか。ここを確かめずに選ぶと、同じ苦労を数年後にもう一度することになります。
確かめる項目は4つです。
1つ目は、標準の機能でエクスポートできる形式です。CSVで出せるのか、JSONで出せるのか、添付ファイルも含めて一括で落とせるのか。画面から誰でも押せるボタンとして用意されているかどうかが分かれ目になります。
2つ目は、その出力に費用がかかるかどうかです。データの持ち出しを有料のサービスとして扱う場合、金額と条件が公開されているかを見てください。公開されていれば、少なくとも予算が立ちます。
3つ目は、解約後にどれだけの期間データが残るかです。解約と同時に消えるのか、一定期間は取り出せるのか。ここは契約の条件として書かれていることが多い部分です。
4つ目が、APIの有無とその範囲です。読み出しのAPIがあれば、最悪の場合でも自分で取り出せます。ここが無い道具は、提供元の手続きに完全に依存します。
こうした条件は、料金表の隣には書かれていないことが多く、利用規約や価格表の注記に紛れています。契約の前に一度探しておくと、次の乗り換えのときの自分が助かります。
移行の作業を、4週間で割る
規模にもよりますが、5人から数十人のチームで動いている案件が数本という前提なら、4週間の枠で組むと現実的な計画になります。
1週目は、数える週です。前の節に挙げた4つの数字を数え、移すものと移さないものを線引きします。ここで「移さない」と決めたものは、CSVとPDFで書き出して保管に回します。移行先の候補を2つか3つに絞るのもこの週です。
2週目は、試す週です。移行先の候補に、実際のデータを一部だけ入れてみます。10枚から20枚のチケットで足ります。ここで、列の対応が付かない項目、文字が化ける項目、日付の形式が合わない項目が見つかります。全件を入れてから見つけると、やり直しの手間が桁違いになります。
3週目は、設定を作る週です。移行先でワークフロー、権限、カスタムフィールドを組み立てます。前の環境の設定をそのまま写すのではなく、実際に使っていたものだけを作ります。この週に、進行を預かる人以外のメンバーにも触ってもらってください。使う側が触らないまま本番に入ると、初週で質問が集中します。
4週目は、移して切り替える週です。データを入れ、両方の環境を並行して動かす日を数日設けたうえで、切り替えの日を決めます。並行して動かす期間は短いほどよく、長くすると両方に書き込まれて、どちらが正か分からなくなります。3営業日を超えないようにしてください。
この4週間の中で、提供元からのバックアップデータの受け取りをどこに置くかが計画の要になります。解約の手続きと連動するため、日程は早めに相談しておくほうが安全です。とくに2026年9月時点は問い合わせの経路が通常と違う状態なので、往復に時間がかかることを見込んでください。
移行の前に、何をどれだけ持っているか数える
計画を立てる前に、いま入っている情報の量を数えてください。数えるのは4つです。
・チケットの総枚数と、直近1年に更新されたチケットの枚数 ・添付ファイルの総数と、合計の容量 ・アクティブなプロジェクトの数と、終了済みのプロジェクトの数 ・カスタムフィールドの数と、実際に値が入っている割合
この4つを数えると、移行の規模がだいたい見えます。よくあるのは、総枚数が5,000枚あっても、直近1年に更新されたものは800枚だけ、というケースです。この場合、全部を移す必要はありません。動いている800枚を移して、残りは書き出したCSVとPDFで保管する。この判断ができるかどうかで、作業量が数倍変わります。
カスタムフィールドについても同じです。定義は20個あるのに、実際に値が入っているのは6個だけ、ということはよくあります。移行先で作り直すのは、その6個だけで足ります。
数え方の実務的なコツも書いておきます。チケットの枚数は、ステータスが完了のものと未完了のものを分けて数えてください。移す対象になるのは基本的に未完了のものと、直近1年に更新された完了済みのものです。この2つを足した枚数が、実際の移行対象になります。添付ファイルは、総容量よりファイル数のほうが作業量に効きます。1個500MBのファイルが4個なら容量は2GBですが、突き合わせの手間はほとんどありません。逆に1個10KBのファイルが3,000個あると、容量は30MBでも突き合わせに時間がかかります。
容量については、フリープランが2GB、スタンダードが200GB、プレミアムとビジネスが1TBという区切りが価格表に載っています。移行先を選ぶときは、この数字と自分たちの実際の使用量を比べてください。多くのチームでは、上限のうちごく一部しか使っていません。
内部の比較データから見た、移し替えの現実
比較の記録を並べていくと、移し替えで詰まる場所は道具の組み合わせによらずほぼ同じであることが分かります。データそのものより、設定と習慣のほうが移らない。この事実は、移行先を選ぶ基準にも影響します。設定が細かい道具から設定が細かい道具へ移ると、作り直す量がそのまま残ります。
カード型の道具との行き来がどうなるかはTrelloとの比較に書いています。案件横断のタスク一覧を主にする形との違いはAsanaとの比較、ドキュメントと台帳を同じ場所に置く形との違いはNotionとの比較、表形式で状態を管理する形との違いはmonday.comとの比較にあります。国内の開発現場から移る場合はBacklogとの比較とJootoとの比較が近い読み比べになります。全体を見渡すなら比較の一覧からどうぞ。
こちら側の制約もはっきり書いておきます。自動で取り込めるのは現時点でTrelloだけで、それ以外の道具からはCSVを整えて入れる形になります。ソースコードの置き場は持たず、外部サービスとの連携の広さを売りにする作りにもしていません。画面に出る言葉は日本語だけです。バージョン管理まで1つに寄せたいチームや、EVMのような指標が要るチームには、素直に別の道具が合います。扱える範囲はできることにまとめ、どこで線を引いて売っているかは料金に書いています。
もうひとつ、比較の記録から繰り返し出てくることがあります。移行の成否を分けるのは、データの量でも道具の相性でもなく、切り替えの日を1日に固定できたかどうかです。両方の環境を長く並行させたチームは、ほぼ例外なく古いほうに情報が残り続け、半年後も2か所を見る運用になっています。切り替えの日を決めて、その日以降は古い環境を読み取り専用にする。この1つを守れるかどうかが、いちばん効きます。
取り込みの手順はTrelloからの移行に、預かった情報をどう扱うかの考え方は安全性の考え方にまとめています。細かい疑問はよくある質問に集めてあるので、問い合わせる前に一度目を通してみてください。
最後にひとつ。移行の計画は、移す作業からではなく「移さないものを決める作業」から始めてください。終わった案件、値の入っていない項目、使っていない設定。これを先に落としておけば、移す量は多くの場合で半分以下になります。全部を持っていこうとすると、費用も期間も倍になり、途中で止まります。
Q1. 解約するとき、データは無料で受け取れますか？
公開されている価格表では、バックアップデータの提供は解約時の1回のみ無料とされています。それ以外のタイミングで希望する場合は75,000円から（1回あたり、税別）です。無料の1回で必要なものが揃うよう、解約を申し出る前に何が要るかを洗い出しておいてください。
Q2. 受け取れるデータには何が含まれますか？
価格表には3つが挙げられています。Redmineのデータ（データベースのダンプデータ）、チケットやWikiなどへの添付ファイル（インストールディレクトリのfiles以下をtar.gz形式で圧縮したもの）、そしてSubversionのデータ（ダンプデータ）です。そのまま他の道具に入る形式ではないため、読み解く作業が別に要ります。
Q3. 特定のプロジェクトだけを移すことはできますか？
提供元の移行サービスの注意事項には、一部のデータや特定のプロジェクト、ユーザーのデータのみを取り出しての移行はできない旨が明記されています。データベースまるごとの移し替えが前提です。部分的に移したい場合は、チケットの一覧をCSVで書き出すか、有料プランで使えるREST APIから必要な範囲を取り出す形になります。
Q4. 移した後、そのまま同じように使えますか？
テキストで表現される情報（タイトル、説明、担当者、期日、コメントなど）は移りやすい一方、ワークフロー、ロールと権限、カスタムフィールドの設定、工程表の依存関係、通知の設定は手で作り直すことになります。移行の見積もりでは、この作り直しの時間を必ず別に見ておいてください。