カスタマイズ対応力が決め手に
黒澤氏は，システムを再構築するに当たり，NECを含むベンダー3社から提案を募った。各ベンダーの提案内容は，同学部が事前に指定した主な要件は満たしていたが，ハード/ソフトの構成は大きく異なった（図3[拡大表示]）。
各社の提案を精査した黒澤氏と松島氏は，システムの可用性を重視する観点からハード機器の総数に着目した。「経験上，障害の発生率はハード機器の総数に比例する傾向がある。従来よりもハード機器の台数が増える構成は避けたい」（黒澤氏）と考えていたためである。そんな黒澤氏の目に留まったのが，メール・サーバー2台，NAS装置1台というシンプルな構成の提案だった。
冗長構成についても，NECだけがアクティブ-アクティブ方式を提案した。システム構成を決めたNECの天内剛史氏（第一官庁システム事業部 主任）は，「アクティブ・サーバーからスタンバイ・サーバーへの切り替え失敗といったサービス停止のリスクを最小限にしたかったため」と説明する。
決め手の一つになったのは，メール・サーバー・ソフトのカスタマイズ対応力だった。同学部は，ユーザー認証の用途にNIS（Network Information Services）サーバーを運用しており，メール・サーバーに新規ユーザーを登録する際には，NISサーバー上でもユーザーを登録する二重の作業が発生していた。DEEPMailの製品説明に訪れたディープソフトの担当者と打ち合わせた際，黒澤氏は二重の登録処理を解消したいと相談を持ちかけた。すると，「（DEEPMailを）カスタマイズすれば対応できる」と開発工数の目安をその場で即答したという。「“いったん持ち帰って検討します”と答えるベンダー担当者が多い中，即断できる技術力とフットワークの軽さに魅力を感じ，DEEPMailを採用したい気持ちが強くなった」と黒澤氏は打ち明ける。
三つの手順でノンストップ移行を実現
もう一つ決め手となったのは，NECが提案した，メールの送受信を止めることなくシステムを移行する案だった。段階的にいくつかの手順を踏むことにより，無停止での移行を実現している（図4[拡大表示]）。
まず，DNSサーバーの設定を変更して，送受信の処理を新メール・サーバー（DEEPMail）に切り替えた（手順1）。「作業自体は瞬時に終わるため，メーラー上にデータを保存しているユーザーは，新規メールを送受信しても切り替わったことにすら気がつかない」（天内氏）。
旧メール・サーバー内に保存されているメール・データの移行が工夫のしどころだった。新規メールの送受信を開始したDEEPMailサーバーに，旧メール・サーバーのデータを移行すると，データを上書きしてしまい不整合が生じる可能性があるためだ。
この問題を回避するため，メーラーの機能を応用して旧メール・サーバーからIMAP形式でメールを取得するツールを自作し，旧メール・サーバー内のデータをDEEPMailサーバーに取り込んだ（手順3）。
ただし，旧メール・サーバーのデータを取得する際には，事前にNISサーバーでユーザー認証を実行する必要があるが，「パスワードは設定したユーザー自身しか分からない」（天内氏）。そこで，全ユーザー・アカウントに仮のパスワードを付与した移行用のNISサーバーを別途用意しておき，認証処理を代行した（手順2）。ユーザー・アカウントの数だけ，データを取得する処理を繰り返し，約3時間でデータの移行が完了した。
