Jootoからデータを移す｜持ち出せるものと、手で作り直す部分
Jootoからの移行を調べ始めた人が最初に知りたいのは、たいてい「何がそのまま持ち出せて、何を手で作り直すことになるか」です。移行先を決める前にここを把握しておかないと、選んだあとで想定外の作業が積み上がります。この記事では、公式が告知している出し口の改修予定と、現時点で使える手段の上限、そして実際に手作業が発生する部分を、期限から逆算する形で整理します。
期限から逆算すると、動ける時間はどれくらいあるか
移行の計画は、締切から引き算して立てるものです。公開されている日付は3つあります。
・一般提供の終了日は2027年7月31日です。この日までは、契約条件に従ってサービス品質とセキュリティが維持され、利用サポートも継続すると案内されています ・2027年8月1日以降、登録されていたデータは順次すべて削除される予定です ・契約更新とライセンス追加は、終了に向けて段階的に受付を停止すると告知されています
2026年9月10日を起点にすると、終了日まで約23か月です。ずいぶん先に見えますが、この数字をそのまま作業期間だと思わないほうがよい理由が2つあります。
1つは、契約更新の受付停止が終了日より前に来ることです。次回の更新日が終了日より後になる場合について、公式のFAQには「2027年7月31日まで契約期間に関わらずご利用いただけますが、8月1日以降はご利用いただけません」と書かれています。つまり、契約期間が残っていても8月以降は使えません。更新のタイミングと終了日の関係は、契約ごとに違います。自社の次回更新日を先に確かめておく必要があります。
もう1つは、移行そのものが一気に終わる作業ではないことです。進行中の案件を抱えたまま道具を替えることになるので、実務では並行運用の期間が発生します。過去の記録は旧環境に置いたまま、新しい案件から新環境で立ち上げていく形が現実的で、この並行期間だけで3か月から6か月かかります。逆算すると、遅くとも2027年の年明けには移行先を確定させておきたい、という計算になります。
判断を先送りするコストも見ておく必要があります。時間が経つほど、旧環境に積み上がる記録が増えます。移すデータが増えれば、それだけ持ち出しと整理の手間が増えます。動くのが早いほど、移す量は少なくて済みます。
提供側が告知している3つの出し口の改修
公式サイトには、サービス移行についてのページが用意されており、データ移行に向けた機能改修が3つ挙げられています。いずれも予定として書かれているもので、提供時期や内容は開発状況により変更となる場合がある、と注記されています。
1つ目は、他サービスへデータを移すためのAPI利用制限の緩和です。2026年9月中旬予定とされ、スタータープランでAPIを利用する際に設けている、一定時間あたりおよび1か月あたりの利用上限を緩和するという内容です。移行ツールなどを使ってデータを他サービスへ移しやすくする目的が明記されています。
2つ目は、CSVで一度に取り出せるデータ量の上限緩和です。同じく2026年9月中旬予定で、プロジェクト単位のCSV出力について、現在1,000行（見出しを除く）までとなっている上限を緩和し、より多くのタスク情報を一度にダウンロードできるようにする、とされています。
3つ目が、移行を検討している側にとってもっとも大きい変更です。
組織管理者が、組織内のユーザー情報と全プロジェクトのタスク・コメント・メンバー情報・変更（アクティビティ）履歴、添付ファイルをまとめてダウンロードできるようにします。データはSQLite形式で提供し、内容をブラウザで確認できるHTMLビューアーもご用意する予定です。 出典: www.jooto.com
提供時期は2026年9月下旬から10月中旬に段階的、とされています。添付ファイルは、SQLiteのデータとは別のファイルとしてまとめてダウンロードできる、と補足されています。
この3つ目が入ると、移行の性質が変わります。プロジェクトを1つずつ開いてCSVを落とす作業が、組織単位の一括操作に置き換わるからです。板の数が20を超える組織では、この差は作業日数にして数日分になります。移行の作業を始める時期を決めるなら、この一括ダウンロードが使えるようになってから、というのが順当な判断になります。
いま出せるものと、これから出せるようになるもの
現時点の出し口を整理すると、料金プランによって使える手段が違います。料金ページの機能一覧では、外部連携の項目として、無料プランに「旧エクスポート」、スタータープランに「エクスポート」と書かれており、インポートの行については無料プランとスタータープランの列に横線が引かれています。API機能の行も同様で、スタータープランには「制限あり」の記載があります。
つまり、出す手段はプランによって違い、入れる手段は上位プランにしか用意されていない、という構造です。移行の文脈では、出す側の性能だけが問題になります。
出せるものとして公式に名前が挙がっているのは、タスク、コメント、メンバー情報、変更履歴、添付ファイル、そして組織内のユーザー情報です。一括ダウンロードの説明にこれらが並んでいることから、少なくとも技術的には全部が手元に来ることになります。
ただし、手元に来ることと、移行先にそのまま入ることは別の話です。SQLite形式のファイルは、そのまま他社のサービスに読み込ませられる形ではありません。ブラウザで確認できるHTMLビューアーが用意されると告知されていますが、これは中身を見るための道具で、移行先に流し込むためのものではありません。実際の移行では、SQLiteから必要な列を抜き出してCSVに整形し、移行先の受け入れ形式に合わせる作業が入ります。
この作業は、社内に表計算ソフトを扱える人がいれば十分こなせる範囲です。ただ、板が多い組織では単純作業の量が増えます。移行先を決めるとき、その受け入れ形式が公開されているかどうかは、確認しておく価値があります。取り込み手順が具体的に書かれているかどうかは製品によって差があり、たとえばTrelloからの移行のように、どの項目がどう入るかまで説明されているものもあれば、問い合わせ扱いになっているものもあります。
APIで出す場合に効いてくる上限の実数
移行ツールを自作したり、外部の移行サービスを使ったりする場合、API経由でデータを取り出すことになります。公式のAPIリファレンスには、リクエスト制限が具体的な数字で公開されています。2026年9月10日時点の記載は次のとおりです。
・組織全体で発行できるAPIトークン数は、ビジネスプランで10個、スタータープランで1個 ・OAuthアプリ数は、ビジネスプランで10アプリ、スタータープランで1アプリ ・トークンごとの1分あたりの読み込み（GET）は、ビジネスプランで最大600リクエスト、スタータープランで最大60リクエスト ・トークンごとの1分あたりの更新（POST / PATCH / PUT / DELETE）は、ビジネスプランで最大150リクエスト、スタータープランで最大15リクエスト ・組織単位の1か月あたりのアクセス回数は、ビジネスプランが無制限、スタータープランは最大100回。カウントは毎月1日0時にリセットされます
上限を超えた場合、APIは429 Too Many Requestsを返します。現在のレート制限の状態は、レート制限情報取得APIから取得できるほか、すべてのレスポンスにX-RateLimit-Limit、X-RateLimit-Remaining、X-RateLimit-Resetの各ヘッダが含まれると記載されています。
ここで注目すべきは、スタータープランの1か月100回という数字です。この回数では、板1つ分のタスクを取り切ることも難しく、移行の道具としては機能しません。公式が移行に向けた改修の1つ目としてAPI利用制限の緩和を挙げているのは、この点が実際に壁になっていたからだと読めます。緩和後の具体的な数字は、2026年9月10日時点の公開資料では確認できませんでした。API経由での移行を検討している場合は、緩和の告知が出てから作業計画を立てるほうが確実です。
なお、移行の目的で外部のサービスに接続する場合、そのサービスにデータの読み取り権限を渡すことになります。どこまでの権限を渡すのか、作業が終わったあとにトークンを失効させる手順があるのかは、始める前に決めておく必要があります。データを預ける先の考え方については安全性の考え方のような形で、保管と削除の方針が書かれているかどうかを確かめておくと判断しやすくなります。
移行先として公式に並んでいるサービス
サービス移行のページには、移行先候補として複数のサービスが掲載されています。掲載サービスは移行先の一例であり、最新情報は各サービス提供会社へ確認するように、と注記されています。2026年9月10日時点で並んでいるのは次のとおりです。
・Backlog: 国産のプロジェクト管理ツール。ボード、課題、ガントチャート、ドキュメントなどを一つのスペースで管理できると紹介され、専用の移行ツールとガイドの提供、スペース単位の料金体系、AIアシスタント搭載が特長として挙がっています ・Asana: 日本唯一のサービスパートナーが移行から定着まで伴走すると紹介され、複数のAIとの連携、1タスクを複数プロジェクトで共有できる点が挙がっています ・CrewWorks: タスクごとの専用チャットで関連するやりとりをまとめられる点と、手厚い移行サポートが挙がっています ・Suit UP: 表計算ソフトのような入力画面と、LINEやTeamsやChatworkとの連携による期限通知が挙がっています ・LycheeRedmine: カンバンはそのままに、ガントチャートによる進捗管理や工数の見える化まで対応する国産ツールとして紹介され、専用の移行ツールと移行サポートが挙がっています ・Notion: Kanbanビューとガントビュー、チームの作業環境と一体化したAIが挙がっています ・Trello: かんばん形式でカードを移動しながら直感的に管理できる点、Power-Upsによる機能拡張が挙がっています ・Microsoft Planner: Microsoft 365を利用している組織で、Teamsなどの既存環境と組み合わせて導入できる点が挙がっています
このうち、Backlog、Asana、CrewWorks、Suit UP、LycheeRedmineの5つには「Jooto移行支援あり」の表示が付いています。移行支援ありと書かれているものは、専用ツールやサポートが用意されている分、作業量が減る可能性があります。
同じページには、既存のサービスへの移行では現在の業務フローや必要な機能を再現できない場合がある、として、自社専用システムの企画・設計・開発を支援する案内も掲載されています。担当するのは株式会社グルコースで、Jootoの開発・運用で培った知見を活用するとされています。また、販売代理店経由で契約している場合の問い合わせ先として、SB C＆Sの窓口も案内されています。
移行先を選ぶときは、この一覧をそのまま候補リストにするのではなく、自社の使い方に合う軸で絞り込むほうが早く進みます。人数で課金するのか板の数で区切るのか、社外の相手を何人入れるのか、日本語のサポートが必要かといった軸を先に決めてから、比較の一覧のように同じ項目で並べた表を見ると、候補は自然に3つ以下に減ります。
手で作り直すことになる部分
データが出せることと、移行が終わることは違います。実務では、出せないものと、出せても意味を保てないものが必ず残ります。順に挙げます。
まず、板の設計そのものです。列の名前と並び順、ラベルの色分け、カードのテンプレート。これらは製品ごとに構造が違うため、そのまま移りません。移行先の画面を見ながら作り直す作業になります。ここは手間ですが、同時に見直しの機会でもあります。使われていない列や、誰も付けていないラベルを削るだけで、新しい環境の見通しがよくなります。
次に、権限とメンバーの設定です。誰がどの板を見られるか、誰が編集できるかは、製品ごとに考え方が違います。人単位で設定する製品もあれば、グループ単位の製品もあります。ここを移行前と同じにしようとすると、かえって複雑になります。移行のタイミングで、権限の設計を簡単な形に置き換えるチームが多いです。
3つ目に、外部との連携です。Webhookで別のシステムに通知を飛ばしていた場合、その設定は移行先で作り直しになります。ブラウザ拡張機能や時間計測の道具を併用していた場合も、移行先で同じものが使えるとは限りません。連携している先を一覧にして、それぞれ代わりの手段があるかを確かめる作業が発生します。
4つ目が、見落とされやすい部分です。他の場所に貼ったURLです。議事録、社内のドキュメント、チャットのやりとり、取引先へのメール。これらに埋め込まれたカードのリンクは、移行後に開けなくなります。すべてを直すのは現実的ではないので、対応としては、旧環境の記録を検索できる形で手元に残しておき、古いリンクに当たったら手元の記録から探す、という運用にするのが一般的です。一括ダウンロードでHTMLビューアーが提供されると告知されているのは、この用途で効きます。
5つ目は、コメントの文脈です。コメントそのものはデータとして出せますが、誰への返信なのか、どのファイルについての話なのかは、移行先の構造次第で失われます。過去の議論を証跡として残す必要がある案件では、そのまま移すより、書き出したファイルを保管しておくほうが確実です。
移す順番を決める
移行を1回の作業だと思うと、必ず途中で止まります。段階に分けて、それぞれの終わりを決めるほうが進みます。実務でよく機能している順番は次のとおりです。
第1段階は、棚卸しです。いくつの板があり、そのうち今も動いているものはいくつか、を数えます。多くの組織で、実際に動いている板は全体の3割から4割です。残りは完了した案件や、途中でやめた試みです。動いていない板は、移行の対象から外して、書き出したファイルだけを保管します。この判断だけで作業量が半分以下になります。
第2段階は、受け皿を決めることです。移行先を選び、板の設計を先に作ります。データを入れる前に、空の状態で1週間ほど自分たちだけで触ってみると、設計の粗が見つかります。ここを飛ばして本番データを入れると、あとから列の並びを変えることになり、全員が混乱します。
第3段階は、新しい案件から新環境で始めることです。既存の案件を動かしながら移すのは負担が大きいので、まず新規のものだけを新環境で立ち上げます。この期間、2つの環境を見ることになりますが、期間を区切っておけば混乱は限定的です。
第4段階が、既存案件の移動です。案件ごとに、区切りのよいタイミングで移します。全部を同じ日に移す必要はありません。むしろ、同じ日にやると問い合わせが集中して対応しきれなくなります。
第5段階は、旧環境の保管です。書き出したファイルを、誰がどこに置くかを決めます。個人のパソコンに置くと、その人が異動した時点で行方不明になります。共有の場所に置き、フォルダの名前に日付と対象を入れておくと、数年後に探せます。
この5段階を、終了日から逆算してカレンダーに置きます。第4段階に3か月、第3段階に3か月を見込むと、第2段階の完了は終了日の半年以上前になります。
契約と返金の扱いを先に確かめる
移行の作業計画とは別に、契約側の確認が必要です。公式のFAQには、契約の途中解約と返金についての項目が用意されており、返金額の算出方法や、申請してから返金されるまでの流れについての質問が並んでいます。問い合わせ先として、メールアドレスと電話番号、問い合わせフォームのURLが案内されています。
また、2026年8月31日付の追記として、サービス提供終了までのスケジュール、契約と料金の取り扱い、データの出力と移行、今後予定している対応をまとめた案内資料が公開されたことが告知されています。自社の契約形態がどうなるかは、この資料と実際の契約書を突き合わせて確かめるのが確実です。
確かめておくべき点は、おおむね3つです。次回の契約更新日はいつか。途中解約した場合の返金がどう計算されるか。販売代理店を経由している場合、窓口はどちらになるか。3つ目は見落とされやすく、代理店経由の契約では問い合わせ先が変わるため、直接連絡しても回答が得られないことがあります。
料金の観点では、移行先の費用も同時に見ることになります。年間契約の残りがある状態で移行先の契約が始まると、一時的に二重の支払いが発生します。この重なりを短くしたいなら、更新のタイミングに移行の完了を合わせる形になり、逆算の起点が変わります。移行先の料金体系が人数で決まるのか、板の数で決まるのかによって、二重期間の負担額も変わります。候補の料金を並べて、重なる期間の合計額まで出しておくと、稟議を通すときの説明が楽になります。
移行の作業を誰がやるかを決める
移行の計画で抜けやすいのが、手を動かす人の確保です。段取りは進行をとりまとめる人が作れますが、実際の書き出しと整形と流し込みには、まとまった時間が要ります。この時間を誰の予定から出すのかを決めていないと、計画だけが立派なまま日程が過ぎていきます。
現場でよく見るのは、いちばん道具に詳しい人が「ついでに」やる形です。この形は、最初の板が終わるまでは動きます。問題は、その人が本来の仕事も抱えていることです。繁忙期が来た時点で移行が止まり、半分移った状態で数か月放置されます。半分移った状態は、両方の環境を見なければならないので、移行前より悪い状態です。
避け方は単純で、作業の総量を先に見積もることです。板1つあたりの作業時間を計ってから、板の数を掛けます。動いている板が15個で、1つあたり2時間かかるなら、30時間です。30時間は、週に3時間ずつなら10週間かかります。この数字が出れば、誰の予定から出すのかという話が具体的になります。
作業を分担する場合は、板の担当者に自分の板を移してもらう形が効きます。中身を知っている人が移すほうが、要る列と要らない列の判断が速いからです。ただしこの形にするなら、手順書を1枚作って配る必要があります。人によって列の作り方が違うと、移行後にばらばらの板が並びます。手順書には、書き出す範囲、移行先での列の名前、日付の形式、担当者の割り当て方を書いておけば足ります。
もう1つ、移行の作業には、社外の手を借りる選択肢もあります。公式のサービス移行ページには、移行支援ありと表示されているサービスがあり、専用の移行ツールやガイドが用意されていると紹介されています。自社の人手が確保できない場合は、支援のある移行先を優先する、という選び方も成立します。
移行の途中で起きやすい詰まりと、その避け方
実際に移行を始めると、計画の段階では見えなかった詰まりが出ます。よく聞くものを3つ挙げます。
1つ目は、添付ファイルです。タスクの本文やコメントは文字なので扱いやすいのですが、添付ファイルは容量があり、数も多く、名前が重複します。公式の告知でも、添付ファイルはSQLiteのデータとは別のファイルとしてまとめてダウンロードできる、と別扱いで説明されています。移行先に入れ直すとき、どのタスクにどのファイルが付いていたかの対応を保つ作業が発生します。ファイル数が多い組織では、ここだけで数日かかります。
避け方としては、全部を入れ直そうとしないことです。進行中の案件に付いているファイルだけを移し、完了した案件のファイルは共有のフォルダに日付付きで保管する。この割り切りで、作業量が大きく減ります。
2つ目は、日付の形式です。書き出したファイルの日付が、移行先の期待する形式と違うことがあります。年月日の区切り、時刻の有無、期限のない項目の扱い。ここを合わせずに流し込むと、期限のないタスクに変な日付が入ったり、取り込みそのものが弾かれたりします。本番の板に流す前に、5件だけのファイルを作って試すと、この手の食い違いは事前に見つかります。
3つ目は、人の対応です。担当者の欄には、旧環境のアカウント名やメールアドレスが入っています。移行先に同じ人が同じメールアドレスで登録されていないと、担当者が空欄になります。退職した人の名前が残っている場合も同じです。移行の前にメンバーの一覧を作り、移行先での対応表を決めておくと、この空欄を防げます。
この3つに共通するのは、どれも小さい問題だという点です。1件ずつ見れば直せます。ただ、件数が多いと時間になります。だからこそ、移す対象を絞る第1段階の棚卸しが効きます。
移行を1度で終わらせるために、何を決めておくか
ここまでの内容を、進行をとりまとめる立場から整理します。移行で失敗するパターンは、道具の性能ではなく、決め事の不足から生まれます。
決めておくべきことは4つです。
・過去の記録を、どこまで新環境に持ち込むか。全部持ち込む前提にすると、作業が終わりません。「進行中の案件だけ」と決めれば、範囲が確定します ・並行運用の期間を、何か月にするか。期限を切らないと、いつまでも2つの環境が残ります ・旧環境の書き出しファイルを、誰が保管するか。担当者の名前まで決めておきます ・移行先で、どの機能を使わないと決めるか。全部使おうとすると定着しません
4つ目は特に大事です。移行のときは、前の道具でできなかったことを全部やろうとしがちですが、増えた機能はそのまま覚える負担になります。最初の3か月は、前と同じことができれば十分だと決めておくほうが、チームの定着は速くなります。
そして、移行先を選ぶときの軸として、今回の件から学べることが1つあります。それは、その道具が自社の運用より長く続く見込みがあるか、という軸です。料金と機能だけで比べていると、この軸は表に出てきません。運営会社の事業方針、その製品が主力なのかどうか、料金体系が最近変わっていないか。こうした点は公式サイトのお知らせを1年分さかのぼれば分かります。Backlogとの比較やAsanaとの比較、Notionとの比較のような比較のページを見るときも、機能の行だけでなく、運営の継続性に関わる記述があるかを合わせて見ておくと、次の移行を減らせます。すでに使っている道具との違いを整理したい場合はJootoとの比較のような1対1の表が、判断の材料をそろえるのに向いています。細かい疑問はよくある質問のような形でまとめて確認しておくと、社内説明の準備が短く済みます。
Q1. Jootoのデータはいつまでに移せばよいですか？
一般提供の終了日は2027年7月31日で、2027年8月1日以降は登録されていたデータを順次すべて削除する予定と公式に案内されています。契約期間が残っていても8月以降は利用できないと明記されているため、並行運用の期間を3か月から6か月見込むと、遅くとも2027年の年明けまでに移行先を確定させる計算になります。
Q2. CSVで一度に何件まで書き出せますか？
公式のサービス移行ページによれば、プロジェクト単位のCSV出力は現在1,000行（見出しを除く）までが上限です。2026年9月中旬にこの上限を緩和する予定と告知されています。あわせて、組織管理者が全プロジェクトをまとめてSQLite形式でダウンロードできる機能も、2026年9月下旬から10月中旬に段階的に提供される予定とされています。
Q3. 移行先として公式に案内されているサービスはどれですか？
サービス移行のページには、Backlog、Asana、CrewWorks、Suit UP、LycheeRedmine、Notion、Trello、Microsoft Plannerが掲載されています。このうち前の5つには移行支援ありの表示が付いています。掲載は一例であり最新情報は各社に確認するように、と注記されています。
Q4. データを書き出しても、そのまま移行先に入りますか？
そのままとはいきません。一括ダウンロードで提供される予定のSQLite形式は中身を確認するための形で、他社サービスに直接読み込ませる形式ではありません。列の設計、ラベル、権限、外部連携、他の場所に貼ったリンクは手で作り直すことになります。移行先の受け入れ形式が公開されているかどうかを先に確かめておくと、作業量を見積もれます。