Microsoft 365 への移行の順番｜ID・メール・ファイル・チャットを何から移し、並行期間をどこに置くか

Google Workspace のメール、社内のファイルサーバー、Slack のチャット、社内のサーバーで管理しているアカウント。Microsoft 365 にまとめると決めたあと、最初に手を付けるのはどれで、古いほうはいつ止めてよいのか。移行を任された情報システム・総務の担当の方にとって、移行元ごとの手順はあっても、全体の順番と、新旧が同時に動く期間（並行期間）をどこに置くかは、決めにくいところです。移行元が2つ以上あると、手順を1つずつ読んでも「どれから手を付けるか」までは分かりません。

この記事では、移すものを ID・メール・ファイル・チャットの4つに分け、ID → メール → ファイル → チャットの順に進める理由と、それぞれで並行期間をどこに置くかを書きます。移行元ごとの手順や設定値、移らないものの細目は、Google Workspace・社内の Exchange・ファイルサーバー・Slack・レンタルサーバーと移行元ごとに分けた当社の各記事に任せ、この記事はその入口として、順番と切り替える日の決め方に絞ります。1,000人を超える規模の手順や、Notes・Access のような業務アプリの作り替えは扱いません。会社の統合・分割で、Microsoft 365 から別の Microsoft 365 へ移す場合は、Microsoft 365 のテナント間移行の記事に分けています。

当社（Aurant Technologies）は Microsoft 365 と Google Workspace の導入・移行を支援しており、この記事の内容は Microsoft の公式の説明（Microsoft Learn）で確かめています。

何から移すか。移すものを4つに分けると、順番が決まる

移行の計画が進まないのは、「メールの移行」「ファイルの移行」と道具ごとに考えて、互いの前後関係が見えないからです。移すものを ID（サインインするアカウント）・メール・ファイル・チャット（予定表・連絡先を含む）の4つに分けると、前後関係は次のように決まります。この順番は Microsoft の1つの文書が決めたものではないので、理由と一緒に書きます。

ID が最初なのは、Microsoft 365 のアカウント（Microsoft Entra ID というアカウントの台帳に入るユーザー）が無いと、移す先のメールボックスも OneDrive も用意できないからです。IMAP 移行の手順も、最初の手順が「ユーザーを作成し、ライセンスを割り当てる」で、メールボックスが Microsoft 365 に無いと移行できません。Google Workspace からの移行バッチも、先に Microsoft 365 側にメール ユーザーが要ります。例外は社内の Exchange からの一括移行（カットオーバー移行）で、こちらは移行サービスがメールボックスを作ります。

メールが2番目なのは、受け口を切り替える日が要るからです。会社のドメインあてのメールをどこに届けるかは、DNS の MX レコード（メールの届け先を決める記録）で決まり、MX レコードが向く先は1つです。そのため、メールには MX を切り替える日が1日あり、その日までに全員のメールボックスがそろっている必要があります。

ファイルは3番目で、順番の縛りがいちばん緩いものです。移行マネージャーはファイルをコピーし、元のファイルは消しません。だから旧と新が同時に存在でき、初回のコピーの後に差分を取れます。チャットは最後で、Microsoft の道具が運ばないものが多く、「残す」「作り直す」を決める作業が中心になります。

説明には架空の会社を1つ使います。社員40人、メールは Google Workspace、ファイルは社内のファイルサーバー、チャットは Slack、サインインのアカウントは社内のサーバーで管理している Active Directory、という会社です（以下、例の会社）。この会社なら、Active Directory のアカウントを Microsoft 365 に同期するかクラウドだけにするかを決めてユーザーとライセンスを作り、Google Workspace のメールを移行バッチで移して MX を切り替え、ファイルサーバーを移行マネージャーで SharePoint にコピーし、Slack のチャンネルを Teams のチームとチャネルとして作り直す、という順になります。

この記事に関連するサービス

M365・Google Workspace の移行と設定の相談移行と設定を、1件から相談できます。詳しく見る →Microsoft 365 導入支援Exchange・SharePoint・Teamsの移行から権限設計・Copilot活用まで詳しく見る →Google Workspace 導入・移行支援Gmail移行から権限設計・Gemini活用まで詳しく見る →AIセキュリティ診断・規約・ルール整備AIを使う前に、出す前に。安全の確認と、規約・ルールの整備を詳しく見る →Notion 導入支援議事録・ナレッジ・タスクを一箇所にまとめる詳しく見る →

道具が運ぶのはどこまでか。運ばないものが、人が決めることになる

順番が決まったら、移行元ごとに「Microsoft の道具が何を運ぶか」を押さえます。メールは Exchange 管理センターの移行バッチ（Google Workspace の移行、IMAP 移行、一括移行（カットオーバー移行）、ハイブリッド）、ファイルは移行マネージャー（ファイル共有・Google ドライブ・Box・Dropbox・Egnyte）と SharePoint 移行ツール（SPMT）（SharePoint Server 2010・2013・2016・2019、SharePoint Foundation 2010・2013、ファイル共有）、ID は Microsoft Entra Connect か Microsoft Entra Cloud Sync、手元の PST ファイルはインポート サービスです。以前あった Mover は廃止され、Google ドライブ・Box・Dropbox・Egnyte からの移行は移行マネージャーに統合されています。

表の「運ぶもの」に無いものが、人が決めることです。ファイル単位の権限と社外共有の作り直し、会社のアドレスでメールを送っている複合機や業務システムの設定、共有の予定表、古いサービスの解約日。道具を動かす前にこれらを決めておくと、切り替える日に困りません。

アカウント（ID）は、クラウドだけにするか、Active Directory と同期するかを決める

最初の判断は、Microsoft 365 のアカウントをどこで管理するかです。管理のしかたは2つのモデルに分かれます。アカウントを Microsoft Entra ID だけに置く「クラウド専用 ID」と、社内の Active Directory で作ったアカウントのコピーを同期する「ハイブリッド ID」です。クラウド専用は追加のサーバーや同期の道具が要らず、ハイブリッドは社内のサーバーと Microsoft 365 で同じ ID とパスワードを使えます。

分かれ目は、移行後も Active Directory を使う場面が残るかどうかです。ファイルサーバーを SharePoint に移し、業務システムも Active Directory で認証していないなら、移行後に Active Directory を使う場面が無くなるので、クラウド専用にして、アカウントは Microsoft 365 管理センターで作ります。残すなら同期です。同期の道具には Microsoft Entra Connect と、社内に置く軽量のエージェント（Microsoft Entra プロビジョニング エージェント）で同期する Microsoft Entra Cloud Sync があり、Microsoft 365 のセットアップ ガイドは両方を並べています。

同期を選ぶときに知っておくことが2つあります。同期したアカウントは、Microsoft 365 管理センターからは変えられず、元の Active Directory で直します。また、同期しただけではライセンスは付かず、使用場所を設定してから、個別かグループで割り当てます。例の会社は、ファイルサーバーを SharePoint に移した後も会計システムの認証に Active Directory を使い続けるので、同期を選びます。

ID と一緒に決まるのが、プランと、会社のパソコンを Microsoft 365 の管理に入れるかどうかです。どのプランで何を守るかは、当社のプランの選び方の記事に任せます。会社のドメインを Microsoft 365 に追加する作業もこの段階で、メールの届け先を変えるのはまだ先です。

メールは、MX を切り替える日の前に並行期間を置く

メールの並行期間は、「MX を切り替える日」の前に置きます。移行バッチも IMAP 移行も、MX を切り替える前から旧のメールボックスの中身を Microsoft 365 に写しておけます。メールは旧に届き続け、同期で Microsoft 365 にも写っていく。全員の同期がそろった日（Google Workspace の移行では、すべてのバッチを完了した後）に MX を切り替え、以後は Microsoft 365 に届く。これが並行期間の形です。

切り替える日の前にやることが1つあります。MX レコードの TTL（DNS の記録を覚えておく時間）を短くしておくことです。Learn の一括移行（カットオーバー移行）の手順は、移行を始める前に 3,600 秒（1時間）に下げるよう勧めています（Learn）。Microsoft 365 の MX レコードも TTL 3600 で、Exchange Online は 6 時間未満の TTL だけをサポートします。切り替えたあと、旧の MX レコードは消すか、Microsoft 365 より低い優先度にします（Learn「DNS レコードを作成する」）。

気をつけるのは、切り替えの前後で旧に届く分です。ここは移行元によって順番が違います。Google Workspace の移行は、始める前に「Microsoft 365 へのメール ルーティング用」と「Google Workspace ドメインへのメール ルーティング用」のサブドメインを1つずつ作り、メール ルーティングを準備したうえでバッチを完了してユーザーを Microsoft 365 に切り替え、すべてのバッチが完了してから MX を切り替えて、Microsoft 365 に届くことを確かめる順です。IMAP 移行は逆で、MX を切り替えて届け先が変わったことを確認してから同期を止めます。Learn に「メールを移行した後に、移行元のメールに送信されたメールは移行されません」とあるためです。

社内の Exchange からの移行は、並行期間の形が違います。Exchange 2013 以降ではハイブリッドで、社内と Exchange Online の両方にメールボックスがある状態を保ちながら少しずつ移します。この期間の設計は当社の Exchange Online への移行の記事に書いています。レンタルサーバーからの IMAP 移行は、メールだけを運び、連絡先・予定表は運ばないので、本人が Outlook で移す段取りを切り替える日の前に入れます（レンタルサーバーのメールの記事）。

例の会社では、メール ルーティング用のサブドメインを用意してから、40人分の移行バッチを2週に分けて同期し、すべてのバッチを完了した週末に MX を切り替え、翌週に Microsoft 365 に届いていることを確かめます。

ファイルは、書き込み先を変える日を決め、その前に初回コピー、その後に差分を取る

ファイルはコピーなので、並行期間を長く取れます。その代わり、「どちらが正か」を決めないと、同じファイルを旧と新で別々に直す事故が起きます。だから、ファイルで決めるのは「書き込み先を変える日」です。

流れは、初回のコピー → 利用者には旧を使い続けてもらう → 書き込み先を変える日に旧を読み取り専用にする → 差分の同期 → 旧を止める、です。移行マネージャーの差分同期は、既定では、宛先に同じパスのファイルがあって宛先の最終更新のほうが新しければ飛ばし、旧と新の両方で更新されたファイルは移しません。書き込み先を変える日より前に新で編集を始めると、その後の差分で旧の変更が移らないことがあるので、新での編集は切り替える日からにします。最初の移行の後は移行先を変えられないので、サイトとフォルダーの構成は初回コピーの前に決めます。

道具が運ばないものも、この日より前に決めます。移行マネージャーはフォルダーの権限は運びますが、ファイル単位の権限は既定で運びません。社外に共有したリンクも作り直しです。ファイル単位の権限が既定では移らない以上、権限は「移ったものを直す」より、移行先のサイトとフォルダーの構成に合わせて付け直す前提で計画しておくほうが、書き込み先を変える日に慌てずに済みます。移す前の権限の棚卸しと移さないものの決め方は当社のファイルサーバーの記事に、Google ドライブからの移行で「完了」と出ても移っていないものの見つけ方はGoogle ドライブの記事に書いています。

利用者のパソコンの中のファイルは、移行マネージャーの対象ではありません。デスクトップ・ドキュメント・画像のフォルダーは、OneDrive の既知のフォルダーの移動で OneDrive に寄せられます。

例の会社では、ファイルサーバーの部署ごとの共有を SharePoint のサイトへ、個人フォルダーを各人の OneDrive へコピーし、MX を切り替えた翌週を書き込み先を変える日にして、その日に旧を読み取り専用にしてから差分を取ります。

チャット・予定表・連絡先は、運ぶ・残す・作り直すを決める

Slack のチャットは、Microsoft の道具が運びません。既定では、パブリック チャンネルのメッセージとファイルを Slack からエクスポートでき、ダイレクト メッセージをエクスポートできるかは Slack のプランと申請で決まります。そのうえで、Teams の取り込みはダイレクト メッセージに対応しておらず、移すならパートナーの製品を相談するよう案内されています。取り込みは GitHub の無料ツールかパートナー企業の製品で、チームとチャネルの作り方は移行ではなく設計の作業です。出典は 2019年10月の日付の Microsoft Learn の「Slack から Microsoft Teams に移行する」です。Slack 側の仕様は変わりうるので、エクスポートできる範囲は Slack の案内で確かめます。

当社の分け方は3つです。「運ぶ」は、道具が運ぶメール・予定表・連絡先（Google Workspace からの移行バッチの範囲）と、取り込むと決めた Slack のチャンネル。「残す」は、Slack のエクスポートを読める形で保管するだけにして Teams に入れない履歴。「作り直す」は、Teams のチームとチャネル、予定表の共有、グループのメンバーです。履歴を全部 Teams に入れようとすると道具が無いぶん費用と時間が増えるので、残すに回す範囲を先に決めます。同じ「Slack から Microsoft Teams に移行する」のページも、チームへの追加と合わせた合意日に Slack のアクセスを削除することを検討するよう書いています。

予定表と連絡先は、移行元によって運ばれ方が違います。Google Workspace の移行バッチは予定表と連絡先を運びますが、IMAP 移行は運びません。IMAP で移した場合は、Microsoft 365 管理センターの「Gmail の連絡先と予定表アドバイザー」が本人のインポートの手順を案内します。並行期間の間、Google カレンダーと Outlook の予定表をどうつなぐかは当社のカレンダーの記事に、Slack から Teams へのチャネルの設計とアプリの対応はSlack の記事に任せます。

例の会社では、MX を切り替えた後に Teams のチームとチャネルを作ってメンバーを入れ、Teams に移る日を合意日にします。Slack は最後のエクスポートを取ってから止め、その履歴は Teams に入れずに読める形で残します。予定表と連絡先は、メールと一緒に移行バッチで運ばれます。

例の会社で、並行期間がどこに集まるかを確かめる

4つを1本の線に並べると、並行期間は2か所に集まります。メールの同期（第3〜4週）と、ファイルの初回コピーから差分まで（第4〜7週）です。ID はその前（第1〜2週）に済ませ、チャットの作り直しは MX を切り替えた後に置いても困りません。

二重に払う期間は、Google Workspace と Slack の解約日までです。解約は、Microsoft 365 にメールが届くことを確かめ、ファイルの差分が終わり、Slack の最後のエクスポートを取ってからにします。Google Workspace から切り替える Microsoft の手順も、解約を最後に置き、ドメインの登録は残すとしています。年契約の残期間の扱いや、Google で買ったドメインの扱いは当社の Google Workspace からの乗り換えの記事に書いています。

週の数は規模で変わります。この例は40人で、ファイルサーバーの中身が数百 GB の想定です。メールボックスの容量とファイルの量が増えれば、同期とコピーの週は伸びます。

頼むかどうかの前に、切り替える日に止まるものを数える

Microsoft 365 管理センターには［セットアップ］>［移行とインポート］に移行の入口があり、「Email セットアップ ガイド」は今のメール システムとメールボックスの数から移行方法を提案します。Microsoft の FastTrack は、対象のライセンスが 150 以上の会社に移行の案内とデータ移行のサービスを提供し、Business Premium も対象です（Learn「データ移行 – FastTrack」、「対象」）。150 未満の会社は、自分たちでやるか、販売代理店や導入支援の会社に頼むことになります。頼める会社の比較は別の記事に、頼む範囲ごとの費用は費用の記事にまとめています。

どちらにしても、最初の作業は数えることです。メールボックスの数と容量、ファイルの数と容量といちばん長いパス、社外と共有しているファイルの数、会社のアドレスでメールを送っている機械と仕組み。当社の公開事例「製造業C社」の Google Workspace 導入の事前調査では、会社のドメインで送っている仕組み（グループウェアの通知、Web サイトのフォーム、社外のサービス）を先に洗い出しました。向きは逆ですが、切り替える日に止まるものを先に見つける作業は同じです。Microsoft 365 から Google Workspace への逆方向は、別の記事に分けています。

移行の計画は、道具の操作から始めず、「MX を切り替える日」と「書き込み先を変える日」を先に決めるところから始めます。その2日が決まれば、ID をいつまでに用意し、同期とコピーをいつ始め、何を残すかが逆算できます。移行の設計の相談は、当社のグループウェア支援で受け付けています。

この記事の確かめ方

方法の名前・数字は、2026年10月26日に Microsoft Learn（Microsoft の公式ドキュメント）の日本語版と英語版で確かめたものです。ID → メール → ファイル → チャットという順番は Microsoft が1つの文書で決めたものではなく、Learn の各移行元の手順から当社が読み取ったものです。例の会社は説明のための架空の会社です。

Learn の各ページの更新日はページごとに違い、Slack からの移行のページは2019年10月の日付です。道具の仕様は変わることがあるため、変わったら見直します。