(57)【要約】【課題】移行元のシステムのデータを移行先のシステムに移行する際に、サービス停止時間を短くするとともに、各ユーザに割り当てるカスタマーＩＰアドレスの変更が発生しないようにする。【解決手段】Ｗｅｂサーバ単位にデータ移行を行うデータ移行方法であって、データ移行システム３は、移行元のＷｅｂサーバ１２のコンテンツデータを、移行先のＷｅｂサーバ２２に直接移行させる第１の移行ステップと、契約内容の変更を停止した状態で、移行元のサーバ設定情報ＤＢ１２のサーバ設定情報データを、移行先のサーバ設定情報ＤＢ２１に移行する第２の移行ステップと、移行元のＷｅｂサーバ１２のサービスを停止した状態で、第１の移行ステップ後に移行元のＷｅｂサーバ１２で更新された増分のコンテンツデータを移行先のＷｅｂサーバに直接移行させる第３の移行ステップとを行う。【選択図】図１
2013186741.tif 000002
【特許請求の範囲】
【請求項１】
データ移行システムが行う、Ｗｅｂサーバ単位にデータ移行を行うデータ移行方法であって、
前記データ移行システムは、
移行元のＷｅｂサーバのコンテンツデータを、移行先のＷｅｂサーバに直接移行させる第１の移行ステップと、
契約内容の変更を停止した状態で、移行元のサーバ設定情報ＤＢのサーバ設定情報データを、移行先のサーバ設定情報ＤＢに移行する第２の移行ステップと、
移行元のＷｅｂサーバのサービスを停止した状態で、前記第１の移行ステップ後に移行元のＷｅｂサーバで更新された増分のコンテンツデータを移行先のＷｅｂサーバに直接移行させる第３の移行ステップと、を行うこと
を特徴とするデータ移行方法。
【請求項２】
請求項１記載のデータ移行方法であって、
前記第３の移行ステップは、前記第１の移行移行ステップで移行されたコンテンツデータに、前記増分のコンテンツデータを合体し、合体したコンテンツデータを前記移行先のＷｅｂサーバにより、所定の形式にデータ変換させること
を特徴とするデータ移行方法。
【請求項３】
請求項１または請求項２記載のデータ移行方法であって、
前記第２の移行ステップは、前記移行先のサーバ設定情報ＤＢに基づいて、ＬＤＡＰ情報を生成すること
を特徴とするデータ移行方法。
【請求項４】
請求項１から請求項３のいずれか一項に記載のデータ移行方法であって、
前記Ｗｅｂサーバには、複数のユーザが収容され、かつ、前記ユーザ毎に異なるＩＰアドレスが設定され、
前記データ移行システムは、
データ移行前の前記ＩＰアドレスと同一のＩＰアドレスを、データ移行後にも使用可能にするステップを行うこと
を特徴とするデータ移行方法。  
【請求項５】
Ｗｅｂサーバ単位にデータ移行を行うデータ移行システムであって、
移行元のＷｅｂサーバの第１のコンテンツデータを、移行先のＷｅｂサーバに直接移行させるコンテンツ処理手段と、
契約内容の変更を停止した状態で、移行元のサーバ設定情報ＤＢのサーバ設定情報データを、移行先のサーバ設定情報ＤＢに移行するＤＢ処理手段と、を有し、
前記コンテンツ処理手段は、移行元のＷｅｂサーバのサービスを停止した状態で、前記第１のコンテンツデータを移行した後に移行元のＷｅｂサーバで更新された増分の第２のコンテンツデータを移行先のＷｅｂサーバに直接移行させること
を特徴とするデータ移行システム。
【請求項６】
請求項５記載のデータ移行システムであって、
前記コンテンツ処理手段は、前記移行された第１のコンテンツデータと、前記増分の第２のコンテンツデータとを合体した第３のコンテンツデータを、前記移行先のＷｅｂサーバにより、所定の形式のデータに変換させること
を特徴とするデータ移行システム。
【請求項７】
請求項５または請求項６記載のデータ移行システムであって、
前記コンテンツ処理手段は、前記移行先のサーバ設定情報ＤＢに基づいて、ＬＤＡＰ情報を生成すること
を特徴とするデータ移行システム。
【請求項８】
請求項５から請求項７のいずれか一項に記載のデータ移行システムであって、
前記Ｗｅｂサーバには、複数のユーザが収容され、かつ、前記ユーザ毎に異なるＩＰアドレスが設定され、
前記コンテンツ処理手段は、データ移行前の前記ＩＰアドレスと同一のＩＰアドレスを、データ移行後にも使用可能にすること
を特徴とするデータ移行システム。
【請求項９】
コンピュータシステムが実行する、Ｗｅｂサーバ単位にデータ移行を行うデータ移行プログラムであって、
前記コンピュータシステムに、
移行元のＷｅｂサーバのコンテンツデータを、移行先のＷｅｂサーバに直接移行させる第１の移行ステップ、
契約内容の変更を停止した状態で、移行元のサーバ設定情報ＤＢのサーバ設定情報データを、移行先のサーバ設定情報ＤＢに移行する第２の移行ステップ、および、
移行元のＷｅｂサーバのサービスを停止した状態で、前記第１の移行ステップ後に移行元のＷｅｂサーバで更新された増分のコンテンツデータを移行先のＷｅｂサーバに直接移行させる第３の移行ステップ、
を実行させるためのデータ移行プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、移行元のシステムのデータを移行先のシステムに移行するデータ移行方法、データ移行システム、およびデータ移行プログラムに関する。
【背景技術】
【０００２】
データ量や処理の増加によるコンピュータシステムの拡張や増強、またはコンピュータシステムの老朽化などにより、現在稼動しているシステムのデータを新たな移行先のシステムに移行する場合がある。このようなデータ移行の技術としては、例えば特許文献１に、更新されるデータベースのデータを移行先データベースに自動的に移行するデータ移行装置が記載されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００１−２３６２５０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ユーザにサービスを提供するシステムにおいてデータ移行を行う場合、ユーザへの影響を極力少なくするために、サービス停止時間を短くするとともに、サービス停止回数も少なくする必要がある。しかしながら、サービス停止回数を減らすために一回のサービス停止でデータ移行を行おうとした場合、サービス停止時間が長くなってしまうという問題がある。
【０００５】
また、ユーザ毎にデータ移行を行う場合、各ユーザのサービス停止時間は短くなるものの、データ移行作業をユーザ単位で分割して行うため処理が複雑化するとともに、全ユーザのデータ移行時間の総量は増加し、データ移行期間が長期化するという問題がある。また、各ユーザに固有のカスタマーＩＰアドレスを割り当てるサービスを提供しているときに、ユーザ毎にデータ移行を行う場合、移行先のシステムでも移行前と同じカスタマーＩＰアドレスを割り当てるのは困難である。
【０００６】
本発明は上記事情に鑑みてなされたものであり、本発明の目的は、移行元のシステムのデータを移行先のシステムに移行する際に、サービス停止時間を短くするとともに、各ユーザに割り当てるカスタマーＩＰアドレスの変更が発生しないデータ移行方法、データ移行システム、およびデータ移行プログラムを提供することにある。
【課題を解決するための手段】
【０００７】
上記目的を達成するため、本発明は、データ移行システムが行う、Ｗｅｂサーバ単位にデータ移行を行うデータ移行方法であって、前記データ移行システムは、移行元のＷｅｂサーバのコンテンツデータを、移行先のＷｅｂサーバに直接移行させる第１の移行ステップと、契約内容の変更を停止した状態で、移行元のサーバ設定情報ＤＢのサーバ設定情報データを、移行先のサーバ設定情報ＤＢに移行する第２の移行ステップと、移行元のＷｅｂサーバのサービスを停止した状態で、前記第１の移行ステップ後に移行元のＷｅｂサーバで更新された増分のコンテンツデータを移行先のＷｅｂサーバに直接移行させる第３の移行ステップと、を行う。
【０００８】
本発明は、Ｗｅｂサーバ単位にデータ移行を行うデータ移行システムであって、移行元のＷｅｂサーバの第１のコンテンツデータを、移行先のＷｅｂサーバに直接移行させるコンテンツ処理手段と、契約内容の変更を停止した状態で、移行元のサーバ設定情報ＤＢのサーバ設定情報データを、移行先のサーバ設定情報ＤＢに移行するＤＢ処理手段と、を有し、前記コンテンツ処理手段は、移行元のＷｅｂサーバのサービスを停止した状態で、前記第１のコンテンツデータを移行した後に移行元のＷｅｂサーバで更新された増分の第２のコンテンツデータを移行先のＷｅｂサーバに直接移行させる。
【０００９】
本発明は、コンピュータシステムが実行する、Ｗｅｂサーバ単位にデータ移行を行うデータ移行プログラムであって、前記コンピュータシステムに、移行元のＷｅｂサーバのコンテンツデータを、移行先のＷｅｂサーバに直接移行させる第１の移行ステップ、契約内容の変更を停止した状態で、移行元のサーバ設定情報ＤＢのサーバ設定情報データを、移行先のサーバ設定情報ＤＢに移行する第２の移行ステップ、および、移行元のＷｅｂサーバのサービスを停止した状態で、前記第１の移行ステップ後に移行元のＷｅｂサーバで更新された増分のコンテンツデータを移行先のＷｅｂサーバに直接移行させる第３の移行ステップ、を実行させる。
【発明の効果】
【００１０】
本発明によれば、移行元のシステムのデータを移行先のシステムに移行する際に、サービス停止時間を短くするとともに、各ユーザに割り当てるカスタマーＩＰアドレスの変更が発生しないデータ移行方法、データ移行システム、およびデータ移行プログラムを提供することができる。
【図面の簡単な説明】
【００１１】
【図１】本発明の実施形態に係るシステムの全体構成図である。
【図２】データ移行処理の概要を示す図である。
【図３】データ移行処理をより詳細に説明するための説明図である。
【発明を実施するための形態】
【００１２】
以下、本発明の実施形態について説明する。
【００１３】
図１は、本発明の実施形態に係るシステムの全体構成図である。
【００１４】
本実施形態では、移行元システム１と、移行先システム２と、データ移行システム３とを備える。移行元システム１および移行先システム２は、ルータ４１、４２を介してインターネットなどのネットワーク５に接続可能に構成されている。また、各システム１、２、３は、専用線などによりそれぞれ接続されている。
【００１５】
移行元システム１は、ネットワーク５に接続されたＰＣなどの端末（不図示）を用いる複数の利用者に、所定のサービスを提供するシステムである。図示する移行元システム１は、複数の利用者の契約情報データを格納する契約ＤＢ１１（ＤＢサーバ）と、利用者にサービスを提供するとともに、各種のコンテンツデータ（Ｗｅｂページ、メールボックスの送受信データ、商品購入履歴など）を格納するＷｅｂサーバ１２と、メール認証やＦＴＰ認証を行うためのＬＤＡＰ情報１３と、メールの送受信を行うメールサーバ１４とを備える。
【００１６】
契約ＤＢ１１（サーバ設定情報ＤＢ）に格納される契約情報データ（サーバ設定情報データ）には、例えば、利用者毎のプラン名、オプション有無、ユーザＩＤ、契約期間、契約者情報（住所、支払い方法、名前、連絡先）、プラン設定情報（サーバ名、IPアドレス、DNS情報）、管理者アカウント設定情報（コントロールパネルパスワード、MySQLパスワード、FTPパスワード等）、メールアカウント設定情報（アカウント名、メールアドレス、パスワード、転送設定等）等が含まれる。これらの情報を基にして、Ｗｅｂサーバ１２、ＬＤＡＰ情報１３、メールサーバ１４、および関連する各種サーバ（DNSサーバ等。図示せず）の設定が行われる。
【００１７】
なお、メールサーバ１４は、通常時において、ネットワーク５を介して受信した受信メールをＷｅｂサーバ１２に出力するとともに、Ｗｅｂサーバ１２から受け付けた送信メールをネットワーク５を介して送信する。
【００１８】
移行先システム２は、移行元システム１の移行先の新規システムであって、移行処理後には、移行元システム１と同様の契約ＤＢ２１（ＤＢサーバ）と、Ｗｅｂサーバ２２と、ＬＤＡＰ情報２３と、メールサーバ２４とを備える。
【００１９】
なお、移行先のＷｅｂサーバ２２は、移行後のコンテンツデータを移行先システム２のデータ形式に適合させるために、コンテンツデータのデータ変換を行うコンテンツ変換部２１１を備える。データ変換処理が必要となる場合としては、例えば、メールの保存形式やＤＢＭＳが変更した場合、ＯＳやミドルウェアのバージョンが変更した場合などが考えられる。移行先システム２のデータ形式が移行元システム１のデータ形式と同じ場合は、コンテンツデータのデータ変換処理を行う必要がない。
【００２０】
なお、本実施形態の移行元システム１および移行先システム２には、共有ホスティングサーバを用いたシステムを例として説明するが、本発明はこれに限定されるものではない。
【００２１】
データ移行システム３は、移行元システム１のデータを移行先システム２に移行させるための制御を行うシステムである。図示するデータ移行システム３は、ＤＢ処理部３１と、少なくと１つのコンテンツ処理部３２とを備える。
【００２２】
ＤＢ処理部３１は、契約ＤＢ１１およびＬＤＡＰ情報１３への変更を停止した状態（オーダー停止状態）で、移行元の契約ＤＢ１１の契約情報データを、移行先の契約ＤＢ２１に移行する。なお、契約情報データの移行については、移行元の契約ＤＢ１１の契約情報データを、移行先の契約ＤＢ２１に直接移行させる場合（ＤＢ処理部３１は制御のみを行う場合）と、ＤＢ処理部３１が移行元の契約ＤＢ１１から契約情報データを取得し、データ変換を行ってから変換後の契約情報データを移行先の契約ＤＢ２１に移行する場合などがある。
【００２３】
コンテンツ処理部３２は、移行元のＷｅｂサーバ１２のコンテンツデータを、移行先のＷｅｂサーバ２２に直接移行させる。また、コンテンツ処理部３２は、移行元のＷｅｂサーバ１２のサービスを停止した状態で、コンテンツデータを移行した後に移行元のＷｅｂサーバ１２で更新された増分のコンテンツデータを移行先のＷｅｂサーバ２２に直接移行させる。なお、コンテンツ処理部３２が複数存在することで、コンテンツデータの移行処理を並行して行い、移行時間を短縮することができる。また、コンテンツ処理部３２は、移行先の契約ＤＢ２１に基づいて、ＬＤＡＰ情報２４を生成する。
【００２４】
このように、本実施形態では、コンテンツデータの移行は、移行元のＷｅｂサーバ１２と移行先のＷｅｂサーバ２２とで直接行い、コンテンツデータのデータ変換も移行先のＷｅｂサーバ２２で行い、データ移行システム３はその制御だけを行う。
【００２５】
なお、図示する例では、ＤＢ処理部３１はＤＢ処理サーバ上で、コンテンツ処理部３２は移行サーバ上で動作するものとするが、これに限定されるものではない。
【００２６】
本実施形態では、利用者の利便性を確保するために、Ｗｅｂサーバが各利用者に割り当てるカスタマーＩＰアドレスを移行元システム１と移行先システム２とで不変にする。そのため、本実施形態では、各利用者単位にデータを移行するのではなく、Ｗｅｂサーバ１２単位での移行を行う。すなわち、１つの物理Ｗｅｂサーバ１２に収容された全利用者を、一括して移行先のＷｅｂサーバ２２に移行し、収容された各利用者に割り振られたカスタマーＩＰアドレスの範囲を移行先のＷｅｂサーバ２２にルーティングするようにルータ４１、４２の設定を行う。最終移行日（移行工事日）の深夜のメンテナンス時間帯に、移行元のＷｅｂサーバ１２へのルーティングを遮断し、移行が完了した後、移行先のＷｅｂサーバ２２へルーティングを切り替えることで、移行前と移行後で各利用者のカスタマーＩＰアドレスをそのまま維持し、サービスを継続して提供することができる。
【００２７】
なお、利用者単位で移行する場合において、カスタマーＩＰアドレスを不変にするには、移行対象の利用者のカスタマーＩＰアドレス宛のルーティングを移行先のＷｅｂサーバ２２にする設定を、ルータ４１、４２に対して行う必要があり、サブネットマスク単位（利用者単位）でルータ４１、４２の設定を行わなければならないため、大規模な移行では運用上現実的ではない。
【００２８】
上記説明した移行元システム１、移行先システム２およびデータ移行システム３は、例えば、少なくともＣＰＵと、メモリと、ＨＤＤなどの記憶装置とを備えたコンピュータシステムを用いることができる。このコンピュータシステムにおいて、ＣＰＵがメモリ上にロードされた所定のプログラムを実行することにより、各システムの各機能が実現される。例えば、データ移行システム３用のプログラムの場合はデータ移行システム３のＣＰＵが実行することにより実現される。また、データ移行システム３用のプログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ−ＲＯＭなどのコンピュータ読取り可能な記録媒体に記憶することも、ネットワークを介して配信することもできる。
【００２９】
次に、本実施形態の処理について説明する。
【００３０】
図２は、本実施形態のデータ移行処理の概要を示す図である。
【００３１】
利用者のカスタマーＩＰアドレスを変更することなく、データを移行するにはサーバ単位での移行を行う必要があることから、サービス停止はサーバ単位に及ぶため、ユーザ単位での移行よりもサービス停止時間の低減が必要となる。そこで、本実施形態では、データ間に不整合が生じない形でサービスを停止せずに行える処理を事前に行うこととする。
【００３２】
具体的には、図２に示すように、データ移行作業を、コンテンツ移行ステップ、ＤＢ移行ステップおよび最終移行ステップの３つの段階に分けて行うものとする。
【００３３】
コンテンツ移行ステップでは、最終移行日（移行工事日）の１週間程前から数日間に渡って行う処理であって、移行元のＷｅｂサーバ１２のコンテンツデータを移行先のＷｅｂサーバ２２に移行する。これにより、サービス停止となる最終移行ステップでは、増分のコンテンツデータのみの移行を行うだけでよいため、最終移行日の移行データ量を大幅に低減することができる。なお、コンテンツ移行ステップでは、サービス停止およびオーダー停止を行わないため、利用者への影響はない。
【００３４】
ＤＢ移行ステップでは、最終移行日の昼間の一定時間（６〜１２時間程度）、オーダー停止をして、その間に移行元の契約ＤＢ１１のデータを移行先の契約ＤＢ２１に移行するとともに、移行後の契約ＤＢ２１を用いて移行先のＬＤＡＰ情報２３を生成し、登録する。
【００３５】
なお、オーダー停止は、契約ＤＢ１１（契約情報データ）およびＬＤＡＰ情報１３（メール認証情報等）の更新を停止する処理である。契約ＤＢ１１およびＬＤＡＰ情報１３は、利用者がＷｅｂサーバ１２にアクセスして、契約内容の変更、ＰＯＰパスワードの変更などを行うことにより更新されるが、これらの変更はそれほど頻繁には行われない。すなわち、オーダー停止は、サービス停止に比べて、利用者への影響が少ない。そこで、ＤＢ移行ステップでは、サービス停止ではなく、オーダー停止とすることで、利用者への影響を極力低減する。なお、オーダー停止の状態であっても、利用者はＷｅｂサーバ１２にアクセスでき、契約ＤＢ１１およびＬＤＡＰ１３への更新を伴わない、Ｗｅｂページの閲覧、メールなどのサービスを利用することができる。
【００３６】
最終移行ステップでは、最終移行日の夜間の一定時間（数時間）、サービス停止をする。サービス停止は、移行元のＷｅｂサーバ１２へのルーティングを遮断し、利用者がＷｅｂサーバ１２にアクセスができないようにして、利用者へのＷｅｂサービスを停止する。なお、サービス停止の状態において、メールサーバ１４はネットワーク５に接続されているため、メールの受信は行われる。
【００３７】
サービス停止の間に、コンテンツ処理部３２は、移行元のＷｅｂサーバ１２の増分のコンテンツデータを移行先のＷｅｂサーバ２２に移行し、移行先のＷｅｂサーバ２２でコンテンツデータのデータ形式を変換する。また、ＤＢ処理部３１は、移行先の契約ＤＢ２１およびＬＤＡＰ情報２３と移行元の契約ＤＢ１１およびＬＤＡＰ情報１３に不整合がないこと等の妥当性チェックを行う。そして、移行処理が終了すると、コンテンツ処理部３２は、ルータの接続を移行先のＷｅｂサーバ２２およびメールサーバ２４に切り替え、これにより、移行先システム２でサービスが再開される。このように、移行が完了した後、移行先のＷｅｂサーバ２２へルーティングを切り替えることで、移行前と移行後で各利用者のカスタマーＩＰアドレスをそのまま維持することができる。
【００３８】
図３は、図２のデータ移行処理をより詳細に説明するための説明図である。
【００３９】
（Ｓ１）コンテンツ移行ステップに相当する最終移行日（移行工事日）の１週間程度前に、データ移行システム３のコンテンツ処理部３２が制御することにより、Rsync等を用いて、移行元のＷｅｂサーバ１２から、移行先のＷｅｂサーバ２２にコンテンツデータを直接移行（データ転送）する。このとき、移行作業で帯域が枯渇し、利用者に不便が生じないようにするため、帯域制御をかけて移行する。なお、コンテンツの更新が頻繁な場合は、増分移行も何度か行うこととしてもよい。
【００４０】
（Ｓ２）そして、ＤＢ移行ステップに相当する最終移行日の昼間に、移行元のＷｅｂサーバ１２で利用者からのオーダー停止を数時間〜１２時間程度行う。そして、この間にデータ移行システム３のＤＢ処理部３１が、移行元の契約ＤＢ１１から移行先の契約ＤＢ２１に契約情報データを移行する。
【００４１】
なお、オーダー停止については、利用者が、Ｗｅｂサーバ１２の契約変更を行うための所定の画面（例えば、契約変更オーダー画面、設定変更コントロールパネルなど）にアクセスできないように遮断する。
【００４２】
（Ｓ３）次に、データ移行システム３のコンテンツ処理部３２は、移行先の契約ＤＢ２１に移行された契約情報データ（アカウント情報）を用いて、POP3/IMAPなどのメール認証に用いられるＬＤＡＰ情報２３を生成する。
【００４３】
（Ｓ４）そして、最終移行ステップに相当する最終移行日の深夜に、移行元のＷｅｂサーバ１２へのルーティングを遮断し、利用者へのＷｅｂサービスを停止する。ルーティングの遮断は、ルータ４１、４２の移行元のＷｅｂサーバ１２への回線を切り離す。
【００４４】
（Ｓ５）そして、ＤＢ処理部３１は、移行元の契約ＤＢ１１と、移行先の契約ＤＢ２１の移行対象利用者の全てに移行中フラグをたてるとともに、移行元のメールサーバ１４に全ての移行対象利用者のドメイン情報を通知する。移行中フラグは、移行中であるためＤＢ更新を不活性にするフラグである。移行元のメールサーバ１４は、移行中利用者のドメイン宛のメールが転送されてきた際には、Ｗｅｂサーバ１２に転送せず、キューイングする。これは、サービス停止中に、メールが消失することを防ぐためである。
【００４５】
（Ｓ６）コンテンツ処理部３２が制御することにより、Rsync等を用いて、移行元のＷｅｂサーバ１２上の増分のコンテンツデータを、移行先のＷｅｂサーバ２２に直接移行する。増分のコンテンツデータは、Ｓ１でコンテンツ移行後に変更・追加された増分のコンテンツデータである。ここでは、増分のコンテンツデータの移行であるため、数時間で移行が完了する。
【００４６】
（Ｓ７）コンテンツの増分移行が完了すると、コンテンツ処理部３２は、移行先のＷｅｂサーバ２２が備えるコンテンツ変換部２２１を起動し、移行先のＷｅｂサーバ２２上でコンテンツの変換処理を行う。変換の例として、メール形式のmboxからmaildirへの変換、ＷｅｂコンテンツのPath変換などがある。
【００４７】
（Ｓ８）コンテンツ変換が完了後、ＤＢ処理部３１は、終了処理として、移行先の契約ＤＢ２１およびＬＤＡＰ情報２３と移行元の契約ＤＢ１１およびＬＤＡＰ情報１３に不整合がないこと等の妥当性チェックを行う。その後ＤＢ処理部３１は、移行元の契約ＤＢ１１および移行先の契約ＤＢ２１の移行中フラグを各々移行済み（またはサービス提供中）に変更するとともに、移行元のメールサーバ１４に移行完了を通知する。通知を受けた移行元のメールサーバ１４は、Ｓ５以降でキューイングしていたメールを、移行先のメールサーバ２４に転送する。そして、移行先のメールサーバ２４は、移行先のＷｅｂサーバ２２にメールを出力する。
【００４８】
（Ｓ９）そして、コンテンツ処理部３２は、ルータ４１、４２を移行先システム２に切り替え、カスタマーＩＰアドレス宛のルーティングを移行先のＷｅｂサーバ２２に設定する。これにより、移行前と移行後で各利用者のカスタマーＩＰアドレスをそのまま維持することができる。
【００４９】
なお、移行中に、何らかの問題が生じた場合は、以降を中止しロールバックする必要がある。Ｓ４からＳ９の移行中は、移行元のＷｅｂサーバ１２のコンテンツデータおよび契約ＤＢ１１には変更が生じないため、ロールバック時はＳ１の直後までロールバックすることで、移行元のＷｅｂサーバ１２で再びサービスを提供することができる。ただし、Ｓ８で移行元の契約ＤＢ１１および移行先の契約ＤＢ２１でフラグを変更した後は、キューイングされたメールが移行先のメールサーバ２４に転送されるため、その後でロールバックした場合は、メールデータの消失が起こり得る可能性に留意する必要がある。
【００５０】
また、本実施形態では、１台のＷｅｂサーバの移行を例としてこれまで説明してきたが、多数のコンテンツ処理部３２を同時に並行して稼動させることで、複数台のＷｅｂサーバの移行を一度に行うことができる。
【００５１】
以上説明した本実施形態では、図２に示す３段階でデータを移行することにより、利用者がＷｅｂサーバの利用ができないサービス停止時間を極力低減し、これにより、深夜の利用頻度が少ない時間帯にサーバの移行（サーバ更改）を完了し、利用者のサービス停止に伴う不便を低減することができる。
【００５２】
また、本実施形態では、コンテンツデータの移行は、移行元のＷｅｂサーバ１２と、移行先のＷｅｂサーバ２２とで直接行い、データ変換も移行先のＷｅｂサーバ２２で行い、データ移行システム３はその制御だけを行う。これは、移行先のＷｅｂサーバ２２は、収容数が少なく、サーバリソースが豊富であるため、それを有効利用するためである。これにより、データ移行システム３の負荷を低減し、データ移行システム３用のサーバの数をより少なくすることができるため、サーバの設置コスト、最終移日に移行処理を制御するオペレータのオペレータ稼動コストを低減することができる。なお、契約情報データの移行についても、移行元の契約ＤＢ１１と移行先の契約ＤＢ２１とで直接行う場合は、データ移行システム３のＤＢ処理部３１の負荷を低減することができる。
【００５３】
また、本実施形態では、３段階でデータを移行することにより、並列処理が困難な契約ＤＢの移行やＬＤＡＰ情報の構築を、最終移行ステップではなく、事前のＤＢ移行ステップで行うことができるため、最終移行ステップでは多数のコンテンツ処理部３１（移行サーバ）を用いることにより、複数台のＷｅｂサーバを並列処理し、複数台のＷｅｂサーバを同時に移行することができる。
【００５４】
また、本実施形態では、Ｗｅｂサーバ単位で移行を行うことにより、利用者のカスタマーＩＰアドレスを移行元と移行先とで不変にすることができる。これにより、カスタマーＩＰアドレスが変更した場合に発生する利用者の設定変更等の手間を削減することができ、利用者の利便性を向上することができる。
【００５５】
なお、本発明は上記実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。例えば、上記実施形態のデータ移行システム３のコンテンツ処理部３２を、複数のＶＭ（Virtual Machine：仮想サーバ）で動作させることとしてもよい。これにより、複数台のＷｅｂサーバを効率よく移行することができる。すなわち、ＶＰＳ（Virtual Private Server：仮想専用サーバ）で動作するＶＭを用いて移行対象の各Ｗｅｂサーバの移行ジョブ制御を行う。これにより、一晩で（一回の最終移行ステップで）、複数のＷｅｂサーバを移行する際は、ＶＭを移行元サーバの台数分起動することで、より容易に複数のＷｅｂサーバを移行することができる。
【００５６】
なお、移行元のＷｅｂサーバから移行先のＷｅｂサーバへデータ移行する際に問題となるのは、データ移行システム３のコンテンツ処理部３２にとって想定外のデータがあり、移行が途中で停止する場合等が考えられるが、ＶＰＳで仮想的に別サーバの処理とすることで、それらの影響を受けずに他の移行元のＷｅｂサーバからの移行処理を行うことができる。
【００５７】
また、ホスティングサービス事業者は、共有ホスティングとＶＰＳとを同時提供していることが多く、共有ホスティングと同様に夜間に利用頻度が少ないＶＰＳをデータ移行システムとして利用することで、新しい設備を準備する必要がないという利点がある。また、ＶＰＳは、仮想化により同筐体の他利用者への影響は極めて少ないため、ＶＰＳでコンテンツ処理部３２を動作させることによる問題はない。
【符号の説明】
【００５８】
１  ：移行元システム
１１：契約ＤＢ
１２：Ｗｅｂサーバ
１３：ＬＤＡＰ情報
１４：メールサーバ
２  ：移行先システム
２１：契約ＤＢ
２２：Ｗｅｂサーバ
２２１：コンテンツ変換部
２３：ＬＤＡＰ情報
２４：メールサーバ
３０:データ移行システム
３１：ＤＢ処理部
３２：コンテンツ処理部
４１、４２：ルータ
５：ネットワーク
【図１】
2013186741.tif 000003
【図２】
2013186741.tif 000004
【図３】
2013186741.tif 000005