--- title: "グループウェア移行の手順｜データ移行・権限・並行稼働と移行で失うもの" url: "https://www.issoh.co.jp/column/details/19800/" published: 2026-11-15 updated: 2026-11-15 categories: ["DX"] publisher: "株式会社一創" --- # グループウェア移行の手順｜データ移行・権限・並行稼働と移行で失うもの グループウェアの移行で最初につまずくのは、製品選びより「どのデータが新しい製品に入るのか」です。予定や連絡先は移せても、過去の申請の承認履歴や掲示板の書き込みは、移行先に取り込めないことがあります。この記事では、グループウェア移行の手順を、移すデータの仕分け、アカウントと権限の作り直し、並行稼働と切替日の決め方の順に整理します。Garoonの入出力仕様と、Microsoft 365・Google Workspaceの公式移行ツールの制限をもとに、移行で失うものを事前に洗い出す方法も示しました。仕様は2026年11月時点の各社公式ドキュメントに基づきます。 ## まとめ：グループウェア移行で先に決める移すデータと捨てるデータ、切替日 グループウェア移行は、データを「移す」「参照用に残す」「捨てる」の3つに仕分けるところから始めます。予定・ユーザー・ファイルはCSVや移行ツールで移せる場合が多い一方、ワークフローの申請データは書き出せても移行先で読み込めない形式が一般的です。承認履歴は移すものではなく、書き出して保管するものと考えた方が計画が崩れません。 Microsoft 365やGoogle Workspaceへ移る場合でも、公式ツールが運ぶのはメール・予定表・連絡先・ファイルが中心です。会議室の予約や共有予定表は移らないと公式に明記されています。 切替は機能ごとに日をずらし、並行稼働は4週間程度で区切ります。旧環境は切替後すぐに解約せず、読み取り専用にして参照期限まで残すのが安全です。承認履歴や独自アプリ、他システムとの連携を抱えているなら、移行の設計から外部の支援を入れる方が手戻りを抑えられます。 ## グループウェア移行を決める前に整理する移行理由と移行先候補の絞り方 グループウェアそのものの定義や機能は[グループウェアとは？機能・料金とクラウド型オンプレ型の違い、選び方を解説](https://www.issoh.co.jp/column/details/13295/)で扱っています。ここでは、移行を決める段階で整理する項目だけを取り上げます。 ### 保守終了・人数上限・費用・使い勝手の4つの移行理由と移行先への影響 移行の理由は、ほぼ次の4つに分かれます。理由によって、移行先に求める条件と急ぐ度合いが変わります。 | 移行理由 | 移行先に求める条件 | 期限の決まり方 | | ------------ | ------------- | ----------- | | 保守終了・サーバー老朽化 | クラウド型・同等機能 | サポート終了日から逆算 | | 契約人数の上限 | 上位製品・上限の無いプラン | 採用計画から逆算 | | 費用の見直し | 既存契約との重複解消 | 現契約の更新日 | | 使い勝手・スマホ対応 | 現場の操作性 | 社内で決める | 上の2つは期限が外から決まるため、移行計画を後ろから組む必要があります。費用が理由の場合は、月額の差額より移行作業と並行稼働の費用が上回ることもあります。乗り換えにかかる費用の内訳は[グループウェアの中小企業向け選び方｜従業員規模別の年額と乗り換えコスト](https://www.issoh.co.jp/column/details/19117/)で整理しました。使い勝手だけが理由なら、設定の見直しで済まないかを先に確かめてください。 ### 国産製品とMicrosoft 365・Google Workspaceの移行比較 移行先は大きく2つに分かれます。サイボウズのGaroonやdesknet’s NEOのような国産グループウェアへ移る場合は、スケジュール・ワークフロー・掲示板という機能の構成が近く、画面の考え方も引き継げます。 Microsoft 365やGoogle Workspaceへ移る場合は、構成そのものが変わります。予定はOutlookやGoogleカレンダー、ファイルはSharePointやGoogleドライブ、連絡はTeamsやGoogle Chatへ分かれ、日本式の稟議や回覧に当たる機能は標準では持ちません。メールと予定の基盤を一本化できる反面、ワークフローの置き場所を別に考える必要があります。製品ごとの料金と最低ユーザー数は[グループウェア比較｜料金と最低ユーザー数、Microsoft 365との棲み分けで決める選定基準](https://www.issoh.co.jp/column/details/17482/)で比べています。 ## グループウェア移行で移せるデータと移せないデータを機能別に仕分ける棚卸し 移行計画の中心は、データの棚卸しです。製品のカタログではなく、管理者向けマニュアルの入出力仕様を見て判断します。 ### 予定・設備予約・掲示板・ワークフロー・メッセージの書き出し可否の一覧 例として、クラウド版Garoonのヘルプにある[ファイルの入出力一覧](https://jp.cybozu.help/g/ja/admin/spec/io.html)を機能別に整理すると、次のようになります（2026年11月時点）。 | 機能 | 管理者が扱えるデータ | 読み込み | 書き出し | | ---------- | ---------------- | ---- | ---- | | スケジュール | 予定・施設情報（CSV） | 可 | 可 | | ワークフロー | 申請データ（CSV） | 不可 | 可 | | ワークフロー | 申請フォーム・経路（XML） | 可 | 可 | | 掲示板・ファイル管理 | カテゴリー・アクセス権（CSV） | 可 | 可 | | タイムカード | タイムカードデータ（CSV） | 不可 | 可 | | メッセージ | 管理者向けの一覧に掲載なし | － | － | 読み取れるのは、予定は移しやすく、申請データとタイムカードは「出せるが入れられない」データだという点です。掲示板とファイル管理で管理者が一括で扱えるのはカテゴリーやアクセス権の設定で、掲示の本文は一覧に載っていません。メッセージはユーザーごとのテキスト出力に限られます。申請フォームと経路のXMLはGaroon同士で使う形式なので、他社製品へはそのまま持ち込めないと考えてください。移行元が別の製品でも、同じ観点でマニュアルの入出力一覧を確かめれば、仕分けの表はすぐに作れます。 ### 申請データは書き出せても読み込めない｜承認履歴を参照用に残す方法 ワークフローの申請データは、移行で最も扱いに困るデータです。CSVで書き出しても、移行先のワークフローにその承認履歴を「承認済みの申請」として取り込む機能は、多くの製品にありません。 現実的なのは、移すのを諦めて参照用に残す方法です。申請データをCSVで、添付ファイルを含めて書き出し、検索できる場所に保管します。経費や契約に関わる申請は税務や監査で過去分を求められるため、保管期間は経理部門と決めてください。文書としての保管をどこまでグループウェアに任せてよいかは[グループウェアの文書管理はどこまで足りるか｜専用システムへ移す判断基準](https://www.issoh.co.jp/column/details/17756/)で線を引いています。 移行のタイミングで、承認途中の申請をどうするかも決めます。切替日の2週間前から旧環境での新規申請を止め、残りは旧環境で決裁を終えるのが安全です。 ### 移さないと決めた申請・予定などのデータの保管先と閲覧期限を決める判断基準 移さないデータは、保管先と閲覧期限をセットで決めます。決めないまま旧環境を解約すると、半年後に「去年の申請を見たい」と言われても誰も出せません。 - 法令や社内規程で保存義務がある申請・稟議：CSVと添付を書き出し、文書管理の仕組みで保存年限まで保管 - 過去の掲示・お知らせ：必要なものだけPDFにして新環境の掲示板やポータルへ置き、残りは捨てる - 過去の予定：直近1年分だけ移し、それ以前は書き出したCSVで保管 - 個人のメッセージ：本人に書き出しを依頼し、会社としては移さない 過去の予定を何年分移すかで迷ったら、1年分で十分です。前年の同じ時期の行事を確かめる用途がほとんどで、3年前の予定を新しいカレンダーで開く場面はまずありません。 ## Microsoft 365・Google Workspaceの公式移行ツールと制限 Microsoft 365とGoogle Workspaceは、それぞれ公式の移行ツールを用意しています。ただし運べるデータは限られます。 ### Google WorkspaceからMicrosoft 365へのデータ移行制限 Microsoftの公式ドキュメント[Google Workspace の Microsoft 365 への移行を実行する](https://learn.microsoft.com/ja-jp/exchange/mailbox-migration/perform-g-suite-migration)によると、移行できるのはメールとルール、予定表、連絡先です。ユーザーをバッチに分けて段階的に移す方式で、移行するユーザーは事前にMicrosoft 365側で作成しておく必要があります。 移らない項目も明記されています。会議室の予約、共有の予定表とイベントの色は移行されません。連絡先は1件あたり3つまでのメールアドレスしか移らず、Gmailのラベルの一部やカスタムタグも対象外です。1通あたりのメールサイズの上限は既定で35MBです。Gmailのフィルターから変換されたルールは、移行後に既定でオフになります。 会議室の予約が移らないということは、切替日以降の会議室の予約を新しい環境で取り直す作業が発生するということです。設備予約は切替日の直前に一括で入れ直すと決め、担当者を割り当てておきます。Microsoft 365の構成そのものは[Microsoft 365とは｜Office単体との違い・含まれるサービスと導入で詰まる点](https://www.issoh.co.jp/column/details/18013/)で解説しています。 ### Exchange OnlineからGoogle Workspaceへの移行条件 逆方向では、Google Workspaceの[データ インポート ツール](https://knowledge.workspace.google.com/admin/migrate/import-email-with-the-data-import-tool?hl=ja)を使います。Exchange Onlineからは、メール、カレンダーの予定、連絡先、ToDoリストを移せます。ユーザーが20人を超えるときは、移行元と移行先のユーザーを対応付ける表をCSVで作成する方式です。1回に指定できるユーザー数は1,000人までです。 インポート時に確認する注意点は、リソースカレンダーの対応付け、停止後のデータの扱い、IMAPから移す場合の対象範囲の3つです。Exchange Onlineの会議室などのリソースカレンダーは、CSVでGoogleカレンダーのリソースに対応付ける必要があります。インポートを途中で止めても取り消されず、止める前に入ったデータは残ります。IMAPのメールサービスから移す場合は、メールしか運べません。 ### 共有ファイルをSharePointへ移すMigration Managerの範囲 ファイルの移行には、メールや予定表とは別のツールが必要です。Microsoftの[Migration Manager](https://learn.microsoft.com/ja-jp/sharepointmigration/mm-get-started)は、社内のファイル共有をSharePoint・OneDrive・Teamsへ移すツールで、Google Workspace、Box、Dropboxなど他のクラウドからの移行にも対応します。1ファイルあたり250GBまで扱え、移行元のファイルサーバーはSMB 2.0以降に対応している必要があります。 移行先のSharePointの構成は、移行の前に決めます。旧グループウェアのフォルダ階層をそのまま写すと、権限が細かく分かれすぎて管理しきれなくなるためです。SharePointの役割は[SharePointとは？できること・OneDriveやTeamsとの違いと導入判断の基準](https://www.issoh.co.jp/column/details/18021/)、移行ツールの実行手順は[SharePoint Migration Tool（SPMT）の手順とPowerShell実行例](https://www.issoh.co.jp/tech/details/19265/)にまとめています。 ## アカウントと権限・承認経路を移行先で作り直す設計と組織マスタの整備 データより手間がかかるのが、ユーザーと権限の作り直しです。ここは移行ツールが運んでくれません。 ### 組織マスタとユーザーCSVを先に整え、権限は部署単位のグループで付け直す 最初に、旧環境の組織とユーザーをCSVで書き出し、退職者と重複アカウントを消します。長く使ったグループウェアほど、退職者のアカウントや使われていない組織が残っています。そのまま移すと、移行先の契約人数が膨らむだけです。 権限は、個人ごとの設定を移そうとせず、部署やプロジェクト単位のグループに付け直します。旧環境で個人ごとに例外の権限を付けていた箇所は、移行を機に例外ごと見直す方が後の運用が楽になります。Microsoft 365へ移る場合の管理者ロールの分け方は[Microsoft 365 管理センターの初期設定｜導入直後に情シスがやる順番と権限設計](https://www.issoh.co.jp/column/details/18017/)を参照してください。 ### 申請フォームと承認経路を移行先に合わせて作り直すときの棚卸し項目 申請フォームと承認経路は、移すのではなく作り直します。作り直す前に、旧環境のフォームを次の観点で棚卸しします。 1. 直近1年で1件も使われていないフォームを洗い出し、廃止する 2. 残すフォームごとに、承認者の分岐条件（金額・部署・取引先）を書き出す 3. 承認後に他のシステムへデータを渡しているフォームに印を付ける 4. 移行先のワークフローで再現できるか、フォームごとに判定する 3番目に当たるフォームは、移行先の標準機能では再現できないことがあります。グループウェアのワークフローで足りる範囲は[グループウェアのワークフローはどこまで足りるか｜専用システムへ移す4つの条件](https://www.issoh.co.jp/column/details/19254/)で判断基準を示しました。Microsoft 365やGoogle Workspaceへ移る場合は、ワークフローを別の仕組みで持つ前提で計画します。 ## 並行稼働と切替日を決めて業務を止めないグループウェア移行の進め方 データと権限の方針が決まったら、移行の日程に落とし込みます。 ### 移行計画から旧環境の解約まで8段階の移行スケジュールと期間の目安 1. 移行理由と期限を確定し、移行先を決める 2. 機能ごとにデータを「移す・残す・捨てる」に仕分ける 3. 組織マスタとユーザーを整理し、移行先にアカウントを作る 4. 1部署分のデータで移行の試験を行い、欠けたデータを確認する 5. 申請フォームと承認経路を作り直し、新規申請の受付を止める日を告知する 6. 機能ごとに切替日を決めて本番の移行を行う 7. 並行稼働を4週間程度続け、旧環境を読み取り専用にする 8. 参照期限が来たら書き出しを確認し、旧環境を解約する 社員50人前後でメール・予定・ファイルが中心なら、1から7までで2〜3か月が一つの目安です。ワークフローの作り直しが10本を超える場合は、5の工程だけで1か月以上かかります。4の試験を省くと、本番で欠けたデータに気づいても戻せません。システム移行一般の方式の選び方は[システム移行とは？移行方式の種類と進め方・失敗を防ぐ判断基準](https://www.issoh.co.jp/column/details/15261/)で解説しています。 ### 予定は切替日に一括、ファイルは差分で2回移す機能別の切替の順番 すべての機能を同じ日に切り替える必要はありません。機能ごとに向いた移し方が違います。 | 機能 | 移し方 | 切替の注意 | | ------- | ------------ | -------------- | | 予定・設備予約 | 切替日に一括 | 移行後の二重登録を防ぐ | | ファイル | 事前に全量、切替日に差分 | 旧側の更新を止める日を決める | | メール | バッチに分けて段階的に | 配送先の切替日を告知 | | ワークフロー | 新規受付の停止後に切替 | 承認途中の申請は旧側で完結 | 予定は旧と新の両方に入力できる期間があると、どちらが正しいか分からなくなります。切替日の前日に旧環境の予定入力を止め、当日に一括で移すのが確実です。ファイルは量が多いため、数週間前に全量を移しておき、切替日に更新分だけを移すと停止時間を短くできます。 ### 並行稼働を4週間以内に区切り、旧環境を読み取り専用にする運用ルール 並行稼働は短く区切ります。旧環境でも新環境でも書き込める状態が続くと、急ぐ人は慣れた旧環境を使い続け、データが2か所に分かれます。 切替日以降、旧環境は読み取り専用にし、書き込みが必要な問い合わせは新環境の窓口で受けます。4週間あれば月次の締めを1回含められるので、毎月の業務が新環境で回るかを確かめられます。旧環境の契約は、参照期限まで最小限のユーザー数で残せるかを契約前に確認してください。 ## グループウェア移行を自社で進める場合と移行支援を頼む場合の分かれ目 最後に、移行を自社だけで進めるか、外部の支援を入れるかの判断です。 ### 自社で移行できる条件｜50人未満でメール・予定・ファイルが中心の構成 社員が50人未満で、使っている機能がメール・予定・ファイル共有だけなら、自社で移行して構いません。公式の移行ツールとCSVの読み込みで大半が運べ、移らないのは会議室の予約や共有予定表など、手で入れ直せる範囲に収まります。 この規模で外部に移行作業を丸ごと頼むと、作業費が並行稼働の費用を上回ることもあります。管理者が1人でも、試験移行を1部署で回してから本番に進めば、大きな事故は防げます。 ### 外部の移行支援を入れるべき条件｜承認履歴・独自アプリ・連携システム 次のどれかに当たるなら、移行の設計段階から外部の支援を入れる方が手戻りを抑えられます。保存義務のある承認履歴を大量に抱えている。グループウェア上に独自の業務アプリを作り込んでいる。承認後に会計や販売管理など他のシステムへデータを渡している。どれも移行ツールでは運べず、移行先での作り直しと検証が必要になる領域です。 Notesのように業務アプリを多く載せたグループウェアからの移行は、データの移行というよりアプリの作り直しになります。この場合は、アプリごとに移行先の標準機能で置き換えるか、業務システムとして作り直すかを先に決めます。 Microsoft 365への移行で、データの仕分けからアカウントと権限の設計、移行後の定着までを相談したい場合は、一創の[Microsoft 365・Copilot導入支援](https://www.issoh.co.jp/service/erp%5Fcrm/microsoft365/)で受け付けています。移行理由と現在の機能の一覧があれば、移せるものと作り直すものの切り分けから始められます。 ## よくある質問 グループウェアの移行を検討する段階でよく出る質問に答えます。 ### グループウェアの移行にはどれくらいの期間がかかりますか？ 社員50人前後でメール・予定・ファイルが中心なら、移行先の決定から並行稼働の終了まで2〜3か月が一つの目安です。ワークフローの作り直しが10本を超える場合や、承認後に他のシステムへデータを渡している場合は、その作り直しと検証で1か月以上延びます。保守終了日など外から期限が決まっているなら、その日から逆算して試験移行の時期を先に確保してください。 ### 過去のワークフローの申請データは新しいグループウェアに移せますか？ 多くの場合、承認済みの申請として取り込むことはできません。たとえばクラウド版Garoonでは、申請データはCSVで書き出せますが、読み込みには対応していません。申請データと添付ファイルを書き出して検索できる場所に保管し、保存期間を経理部門と決める方法が現実的です。承認途中の申請は、旧環境で決裁を終えてから切り替えます。 ### Microsoft 365やGoogle Workspaceへ移行すると何が移せませんか？ Google WorkspaceからMicrosoft 365への公式移行では、会議室の予約、共有の予定表、イベントの色が移行されません。連絡先は1件あたり3つまでのメールアドレスしか移りません。また、どちらの環境も日本式の稟議や回覧に当たるワークフロー機能を標準では持たないため、国産グループウェアから移る場合は申請の仕組みを別に用意する必要があります。 ### 並行稼働の期間はどれくらいに設定すればよいですか？ 4週間程度が目安です。月次の締めを1回含められるため、毎月の業務が新環境で回るかを確かめられます。それより長くすると、旧環境に書き込む人が残り、データが2か所に分かれます。切替日以降は旧環境を読み取り専用にし、参照期限まで残してから解約してください。 ### グループウェアの移行を自社だけで進めても大丈夫ですか？ 社員50人未満で、使っている機能がメール・予定・ファイル共有だけなら、自社で進めて問題ありません。保存義務のある承認履歴を大量に抱えている、独自の業務アプリを作り込んでいる、他のシステムと連携している、のどれかに当たる場合は、移行ツールで運べない作り直しが発生するため、設計段階から外部の支援を検討してください。 ## 関連記事 - [グループウェアの中小企業向け選び方｜従業員規模別の年額と乗り換えコスト](https://www.issoh.co.jp/column/details/19117/)：乗り換えにかかる費用の内訳と、乗り換えを前提にした初期設計 - [グループウェア比較｜料金と最低ユーザー数、Microsoft 365との棲み分けで決める選定基準](https://www.issoh.co.jp/column/details/17482/)：移行先の製品を料金と機能で比べるときに - [グループウェアとは？機能・料金とクラウド型オンプレ型の違い、選び方を解説](https://www.issoh.co.jp/column/details/13295/)：クラウド型とオンプレミス型の違いから見直す - [システム移行とは？移行方式の種類と進め方・失敗を防ぐ判断基準](https://www.issoh.co.jp/column/details/15261/)：一括移行と段階移行の方式の違い --- 出典: [グループウェア移行の手順｜データ移行・権限・並行稼働と移行で失うもの]()（株式会社一創）