Google Workspaceから別のメールホスティングへ慎重に移行する場合、開始から完了までは約一週間、実作業は3-4時間ほどです。ポイントは、新旧環境で並行してメールを受信できる状態を作ることです。Workspaceで受信を続けながら新しいホストを設定し、IMAP移行ツールで過去のメールをバックグラウンドコピーします。その後、DNSのTTLを短くした状態でMXレコードを切り替えれば、移行にかかる時間を数時間ではなく数分に抑えられます。
「Google Workspaceからの移行」を扱うガイドの多くは、DNSの反映中にメールが届かなくなる一斉切り替えを紹介しています。この方法では、受信量に応じて通常10-50通のメールを失います。以下の六ステップなら、損失はゼロです。設定に余分にかかるのは30分ほどで、移行後に「あのお客様からのメールはどこへ行ったのか」と慌てずに済みます。
このガイドでは、具体的なDNSレコードの例を交えながら、六段階の移行手順を説明します。全体像については、Google Workspaceからメールを移行する方法もご覧ください。
Google Workspaceからの移行は見た目ほど難しくない
Google Workspaceからの移行が難しそうに見えるのは、メール、カレンダー、Drive、Meetがひとつのアカウントにまとめられているためです。複雑に感じる主な理由は、この一体化にあります。メールだけを見れば、必要なのはIMAPとDNSレコードだけです。IMAPに対応するホストであれば、問題なく移行できます。
実際の移行作業は、はっきり分けられます。メールは、以下の六ステップで1-2日分の作業です。カレンダーはWorkspaceから書き出し、新しいカレンダーサービスに読み込みます。移行先にはFastmail Calendar、Apple Calendar、自社運用のCalDAVなどがあります。Driveはrsyncのような方法で新しいファイルストレージへコピーします。Meetは契約時にZoomなどへ置き換えます。それぞれを個別に移行できるため、「Google Workspaceからの移行」という言葉から受ける印象ほど、プロジェクト全体は大がかりではありません。
六段階の移行手順
次の六ステップに従えば、切り替え中に届くメールを失わずにGoogle Workspaceから移行できます。順番は重要です。各ステップの結果が次の作業に必要になるため、どれかを飛ばすと後工程に不備が生じ、DNSの反映中に配送されているメールを失うおそれがあります。
- 48時間前にDNSのTTLを短くする。 切り替え時にMXレコードが反映されるまでの時間を、数時間から数分に短縮します。
- 新しいホストを準備する。 新しいメールホストにドメインを追加し、既存と同じメールボックスを作成します。
- IMAP移行をバックグラウンドで実行する。 Workspaceで受信を続けながら、過去のメールを新しいホストへコピーします。
- MXレコードを切り替える。 DNSの参照先を新しいメールホストへ変更します。反映中は新旧の環境で並行して受信します。
- 検証と往復テストを行う。 三つの受信サービスで認証に合格することを確認します。
- Workspaceを停止する。 MXレコードの切り替え後48-72時間待ってから、Workspaceのメールボックスを無効にします。
全工程の所要期間は約一週間です。実作業は、その期間に分散して3-4時間ほどです。六ステップを順守することで、場当たり的なGoogle Workspace移行で起こりがちなメール消失を防げます。
ステップ1: 48時間前にDNSのTTLを短くする
Google Workspaceから移行する最初の作業は、予定している切り替えの48時間前に、MXレコードのDNS TTLを短くすることです。WorkspaceのMXレコードでは通常、既定のTTLが3600、つまり一時間に設定されています。これを300、つまり五分に変更すると、ステップ4でMXレコードをすばやく切り替えられます。
; before - default TTL
yourcompany.com. 3600 IN MX 1 aspmx.l.google.com.
; after - low TTL for cutover window
yourcompany.com. 300 IN MX 1 aspmx.l.google.com.
DNSホストの管理画面で、各MXレコードのTTLを編集します。キャッシュの期限が切れるにつれて、変更は1-2時間ほどで反映されます。短いTTLが世界中に確実に行き渡るまで48時間待ってください。ステップ6で移行が完了したら、通常運用のためTTLを3600に戻します。
ステップ2: 新しいホストを準備する
Google Workspaceから移行する二番目の作業は、新しいメールホストの準備です。TrekMail、または選択した移行先に申し込みます。管理画面でドメインを追加し、確認用TXTレコードを使って所有権を証明します。Workspaceと同じ名前のメールボックスを作成してください。たとえば、sarah.smith@やmike.davis@などです。SPF、DKIM、DMARCの値を生成しますが、まだ公開しないでください。公開するのはステップ4です。
この時点で、新しいホストのメールボックスは利用できる状態ですが、MXレコードはまだWorkspaceを参照しています。そのため、実際のメールは新しいメールボックスには届きません。この準備によって、ステップ4で新旧環境の並行受信を使った切り替えをスムーズに進められます。移行先サービスの選び方については、Google Workspaceの代替サービスをご覧ください。
ステップ3: IMAP移行をバックグラウンドで実行する
Google Workspaceから移行する三番目の作業は、IMAP移行をバックグラウンドで実行することです。TrekMailでは、サーバー側のIMAP移行ツールを利用できます。メールボックスごとにWorkspaceのIMAP認証情報を入力すると、Workspaceで新しいメールを受信し続けながら、数時間かけてフォルダ単位でコピーされます。
一般的な容量のメールボックスなら、ほとんどの移行は24時間以内に完了します。一ユーザーあたり1-10GBが目安です。50GBを超える大容量のメールボックスには、さらに時間がかかります。ステップ4の前に過去のメールがすべて新しいホストへ届くよう、切り替えより前に移行を実行してください。進捗は管理画面で確認できます。個別のメールボックスで対応が必要なIMAPエラーが起きた場合も、ツール上でメールボックスごとに表示されます。
ステップ4: MXレコードを切り替える
Google Workspaceから移行する四番目の作業は、MXレコードの参照先を新しいホストへ変更することです。ステップ2で用意した新しいMX値と、SPF、DKIM、DMARCレコードを公開します。DNSの反映には約5分しかかかりません。これはステップ1でTTLを短くしているためです。
; new MX pointing at TrekMail
yourcompany.com. 300 IN MX 10 mx1.trekmail.net.
yourcompany.com. 300 IN MX 20 mx2.trekmail.net.
; authentication records
yourcompany.com. 300 IN TXT "v=spf1 include:_spf.trekmail.net ~all"
trekmail._domainkey.yourcompany.com. 300 IN TXT "v=DKIM1; k=rsa; p=..."
_dmarc.yourcompany.com. 300 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourcompany.com"
DNSの反映中は、一部の送信元が引き続きWorkspaceへ配送し、ほかは新しいホストを使います。両方の環境が並行して受信するため、メールがエラーで戻ることはありません。DNSキャッシュが長い送信元から配送中のメールを確実に受け取るため、MXレコードの切り替え後もWorkspaceのメールボックスを少なくとも48-72時間は有効なままにし、アクセスできるようにしてください。
ステップ5: 検証と往復テストを行う
Google Workspaceから移行する五番目の作業では、新しいホストから送信したメールの認証結果を確認します。各メールボックスからGmail、Outlook.com、Yahooのアカウントへテストメールを送ります。三つすべての受信先で、ヘッダーにSPF=PASS、DKIM=PASS、DMARC=PASSと表示されることを確認してください。ひとつでもFAILがあれば、本番運用を始める前に、ステップ4で公開したレコードを修正する必要があります。
受信についても確認します。外部のメールアドレスから、新しいメールボックスのひとつへテストメールを送ってください。数分以内に新しいホストへ届くことを確認します。Workspace側へ届いた場合は、DNSの反映がまだ完了していません。さらに10-15分待って、もう一度テストします。検証は省略できません。省略すると、配信到達性の問題が切り替え時ではなく、本格運用後に表面化します。
ステップ6: Workspaceを停止する
Google Workspaceから移行する六番目の作業は、MXレコードの切り替えから48-72時間後にWorkspaceのメールボックスを停止することです。この時点でDNSの変更は世界中に反映されています。管理コンソールからメールボックスを無効にし、現在の請求期間の終了時に契約を解約します。DNSのTTLは3600に戻してください。
あとで過去のデータが必要になった場合に備えて、最終的に解約する前にWorkspaceのデータをエクスポートしてください。対象はメール、カレンダー、Driveです。GoogleのTakeoutを使って書き出し、契約が終了する前にローカルストレージへダウンロードします。このデータがあれば、新しいホストとは別に、Workspaceの過去の状態をバックアップとして残せます。手順をチェックリストで確認したい場合は、メール移行チェックリストをご利用ください。
次のステップ
六ステップに沿ってGoogle Workspaceのメールを移行すると、開始から完了まで約一週間、実作業は3-4時間ほどです。新旧環境での並行受信を正しく設定すれば、メールをまったく失わずに移行できます。DNSの反映中は新しいホストが配送中のメールを受け取り、古いMXレコードへ届く一部のメールはWorkspaceが引き続き処理します。
trekmail.net/pricingでTrekMail Nanoを無料でお試しください。カードの登録は不要です。月額$4のStarterには、Google Workspaceから移行するステップ3で必要なサーバー側IMAP移行ツールが含まれます。定額制の年額$42なら、大半のユーザーがDocsやSheetsを毎日使わないメール中心のチームでは、Workspaceの料金を通常90%以上削減できます。IMAP移行の全体像については、IMAP移行ガイドをご覧ください。
具体例を見てみましょう。ヘルシンキの24人規模のSaaS企業が、長年利用したGoogle Workspaceから移行したケースです。移行前はWorkspace Business Starterに年額$1,728を支払っていました。短いTTLの反映待ちと新旧環境での並行受信を含め、完了まで5日かかりました。その間に180GBの過去メールを24個のメールボックスからIMAPで移行しています。移行後、同じ用途で使うTrekMail Proの料金は年額$96です。年間$1,632を節約でき、チームのNotion契約費をまかなっても、移行後の年度予算に余裕が残ります。
もうひとつの例は、テルアビブの40人規模の中堅企業がGoogle Workspace Business Standardから移行したケースです。移行前の料金は年額$5,520でした。利用状況を調べると、DocsやSheetsを使っていたのは、経営陣と経理担当を含む8人だけでした。そこで、40個のメールボックスにはTrekMail Proを年額$96で利用し、文書作業が多いユーザー向けにWorkspace Business Starterを8席だけ残して年額$576を支払う計画にしました。移行後の合計は年額$672です。年間$4,848を節約できます。
両方の例から分かるとおり、Google Workspaceからの移行は、すべてを残すか、すべてを移すかの二者択一ではありません。生産性向上ツールを実際に使っているユーザーを調べれば、環境を分けられます。大半のユーザーは定額制のメール専用ホストへ移し、文書作業が多いユーザーだけWorkspaceに残します。この方法なら、本当に必要なユーザーには生産性向上ツールを維持しながら、Workspaceの料金を通常70-90%削減できます。
