JP2017162152A

JP2017162152A - データ移行システム、及び、データ移行システムの制御方法

Info

Publication number: JP2017162152A
Application number: JP2016045484A
Authority: JP
Inventors: 哲也松本; Tetsuya Matsumoto
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2016-03-09
Filing date: 2016-03-09
Publication date: 2017-09-14
Anticipated expiration: 2036-03-09
Also published as: JP6755680B2

Abstract

【課題】バッチ処理を実行するシステムのデータを並行稼働しながら段階的に移行する場合でも、データを正常に移行でき、移行後のデータチェックも正常にできること。【解決手段】データ移行システム１０５は、移行先システム１０４のＤＢ性能を上げ（Ｓ７０１）、移行元システム１０３のデータの移行状態を移行中に変更し（Ｓ７０２）、移行元システム１０３で実行中のバッチ処理の完了を監視し（Ｓ７０３）、移行元システム１０３のデータを移行先システム１０４に移行し（Ｓ７０４）、移行に成功したデータの移行元システム１０３における移行状態を移行完了に変更し、移行に失敗したデータの移行状態を移行前に変更し（Ｓ７０５）、移行先システム１０４のＤＢ性能を下げる（Ｓ７０６）。移行元システム１０３及び移行先システム１０４は、移行状態が移行中のデータに対してはバッチ処理を実行しない。【選択図】図７

Description

本発明は、移行元システムのデータを移行先システムに移行するデータ移行システム、及び、その制御方法に関する。

クラウドサービス基盤を利用して構築され、顧客にサービスを提供しているシステムがある。クラウドシステムにおいて、現在稼働している既存システム（移行元システム）を、新規システム（移行先システム）へ移行する場合がある。

特許文献１には、移行元システムのデータを移行先システムへ移行するための技術が開示されている。特許文献１によれば、移行によるサービス停止時間を短くするとともに、各ユーザに割り当てるＩＰアドレスの変更が発生しないように移行ができる。

クラウドシステムの移行では、移行元システムとは別のクラウドサービス基盤を利用して構築された移行先システムへ移行する場合がある。このような場合、移行元システムと移行先システムとで、データを管理しているデータベースの種類が異なる、データ構造が変更になる、などの理由で、データベースの同期機能などを使用したデータの移行が困難な場合が多い。

また、クラウドシステムでは、システムを利用する顧客のデータを、顧客ごとの専用領域であるテナントの単位で管理する。テナント単位でデータを管理しているシステムでは、テナントごとに段階的に移行を実施する場合がある。つまり、管理する全てのテナントの移行が完了するまでは、移行元システムと移行先システムを並行稼働しておく必要がある。さらに、移行完了後に移行先システムで障害が発生し、その障害が修正されるまでの期間、移行元システムを使用するようなことも考えられる。そのような場合においても、移行元システムを使用できるように並行稼働しておく必要がある。

また、クラウドシステムでは、複数の顧客のデータを管理するためデータ量が多い。そのため、データの集計処理などの長い時間を要する処理は、バッチ処理によって定期的に一括で処理をすることが多い。

特開２０１３−１８６７４１号公報

上述のように、移行元システムと移行先システムを並行稼働しながら、テナント単位で段階的に移行を実施する場合がある。しかし、移行元システムと移行先システムとを並行稼動をしているため、移行中に、移行元システムのバッチ処理が実行され、移行対象テナントの移行元システムのデータが更新されてしまう場合がある。移行中に、移行対象テナントの移行元システムのデータが更新されると、中途半端な状態（例えば更新途中の不完全な状態）でデータが移行されてしまうという課題があった。中途半端な状態でデータが移行されてしまうと、移行先システムが正常に動作しないことも考えられる。

一方、データの移行が正常に行われたかを確認する目的で、移行元システムと移行先システムのデータの比較するチェックを行うことが考えられる。移行中に、移行対象テナントの移行元システムのデータが更新されると、上記チェックにおいて、データに差異があると判定されてしまい、正しい結果が得られないという課題もあった。

本発明は、上記の問題点を解決するためになされたものである。本発明の目的は、バッチ処理を実行するシステムのデータを並行稼働しながら段階的に移行する場合であっても、データを正常に移行でき、移行後のデータチェックも正常に行うことができる仕組みを提供することである。

本発明は、第１のシステムのデータベースで管理されるデータの、該第１のシステムから第２のシステムへのデータ移行を制御するデータ移行システムであって、前記第１のシステムのデータベースで管理される移行対象のデータの移行状態を、移行中を示す状態に変更させる変更手段と、前記第１のシステムで実行中のバッチ処理の完了を監視する監視手段と、前記第１のシステムのデータベースで管理される移行対象のデータを取得し、該取得したデータを前記第２のシステムのデータベースに登録することで、データ移行を実行する移行手段と、を有し、前記変更手段は、前記第１のシステムのデータベースで管理される移行対象の各データのうち、前記移行手段によるデータ移行に成功したデータの移行状態を、移行完了を示す状態に変更させ、前記変更手段は、前記第１のシステムのデータベースで管理される移行対象の各データのうち、前記移行手段によるデータ移行に失敗したデータの移行状態を、移行前を示す状態に変更させ、前記第１のシステム及び前記第２のシステムでは、移行状態が移行中を示すデータに対してはバッチ処理が実行されないことを特徴とする。

本発明によれば、バッチ処理を実行するシステムのデータを並行稼働しながら段階的に移行する場合であっても、データを正常に移行でき、移行後のデータチェックも正常に行うことができる。

本実施例を示すシステムの全体構成を例示する図移行元システム、移行先システム、データ移行システムを構成する情報処理装置のハードウェア構成図移行元システムおよび移行先システムの機能構成図データ移行システムの機能構成図テナント情報テーブルを例示する図バッチ処理管理テーブルを例示する図実施例１の移行処理を例示するフローチャート移行開始時の移行状態の変更処理の詳細を例示するフローチャートバッチ処理の完了待機処理の詳細を例示するフローチャートデータの移行処理の詳細を例示するフローチャート移行完了時の移行状態の変更処理の詳細を例示するフローチャートバッチ処理を示すフローチャート実施例２の移行処理を例示するフローチャート実施例２の移行先システムの課金データ作成処理を例示するフローチャート実施例２の移行元システムの課金データ作成処理を例示するフローチャート実施例３の移行処理を例示するフローチャート実施例４の移行処理を例示するフローチャート

以下、本発明を実施するための形態について図面を用いて説明する。

＜システム構成＞
図１は、本発明の一実施例を示すシステムの全体構成を例示する模式図である。
図１において、１０１はＰＣ（Personal Computer）などの情報端末で、ユーザが使用する端末である。移行前は、ユーザは移行元システム１０３が提供するＷｅｂページを使用して、移行元システム１０３が提供するサービスを利用する。移行後は、ユーザは移行先システム１０４が提供するＷｅｂページを使用して、移行先システム１０４が提供するサービスを利用する。

１０２はプリンタや複写機等のネットワーク機器である。移行前は、ネットワーク機器１０２は、自身が管理する各種データ（カウンター、ジョブログ、障害情報など）を移行元システム１０３に送信する。移行後は、ネットワーク機器１０２は、自身が管理する各種データを移行先システム１０４に送信する。なお、ネットワーク機器１０２は、プリンタや複写機等の画像形成装置に限定されるものではなく、ネットワーク機器であればどのような種類のネットワーク機器であってもよい。例えば、ネットワークカメラ、医療機器、ナビゲーションシステム、パーソナルコンピュータ、テレビジョンやエアーコンディショナー、冷蔵庫等の各種ネットワーク家電なども、ネットワーク機器１０２となり得る。

移行元システム１０３は、ネットワーク機器１０２から受信したデータを管理する。また、移行元システム１０３は、ユーザがサービスを利用するためのＷｅｂページを提供する。移行元システム１０３は、ネットワーク機器１０２から受信したデータや、ユーザがＷｅｂページを利用して入力したデータを保持する。なお、移行中のテナントについては、移行中のテナントに所属するユーザがＷｅｂページを利用できないように制御する。

移行先システム１０４は、移行元システム１０３と同等の機能を提供する。
１０５はデータ移行システムで、移行元システム１０３が保持するデータを、移行先システム１０４へ移行する機能を提供する。

本実施例のシステムでは、情報端末１０１、ネットワーク機器１０２、移行元システム１０３、移行先システム１０４、データ移行システム１０５は、インターネット１０６などの既知の技術により相互に通信可能に接続されている。図１の例では、データ移行システム１０５は、移行元システム１０３、移行先システム１０４とは別のシステムとして記載されている。しかし、データ移行システム１０５の提供する機能を、移行元システム１０３または移行先システム１０４に含める構成にしてもよい。例えばデータ移行システム１０５が、移行先システム１０４内に構築される構成でもよい。

＜情報処理装置の内部構成＞
図２は、移行元システム１０３、移行先システム１０４、データ移行システム１０５を構成する情報処理装置のハードウェア構成の一例を示すブロック図である。
移行元システム１０３、移行先システム１０４、データ移行システム１０５は、ＲＯＭ２０２あるいは記憶装置であるハードディスクドライブ（ＨＤＤ）２１１に記憶されたソフトウェアを実行するＣＰＵ２０１を備える。ＣＰＵ２０１は、システムバス２０５に接続される各ハードウェアを総括的に制御する。

２０３はＲＡＭで、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。２０４はネットワークインターフェースカード（ＮＩＣ）で、ネットワークを介して、他のノードと双方向にデータをやりとりする。

２０６はキーボードコントローラーで、情報処理装置に備えられたキーボード２０７からの指示入力を制御する。２０８はディスプレイコントローラーで、例えば液晶ディスプレイなどで構成される表示モジュール２０９の表示を制御する。２１０はディスクコントローラーであり、大容量記憶装置であるハードディスクドライブ（ＨＤＤ）２１１を制御する。なお、ＨＤＤの代わりに又は併用して、ＳＳＤ（Solid State Drive）等の他の記憶装置を備えていてもよい。

なお、移行元システム１０３、移行先システム１０４、データ移行システム１０５は、それぞれ図２で例示した構成に限定されるものではなく、例えば複数のコンピュータから構成されるものであってもよい。

＜移行元／移行先システムの機能構成＞
図３は、移行元システム１０３および移行先システム１０４の機能構成の一例を示すブロック図である。なお、図３に示す機能構成は、移行元システム１０３や移行先システム１０４のＣＰＵ２０１がＨＤＤ２１１等に格納されるプログラムを読み出して実行することにより実現されるものである。

３０１は通信部であり、ネットワークを介して、情報端末１０１やネットワーク機器１０２やデータ移行システム１０５と通信する機能を実現する。
３０２はテナント情報処理部であり、システムが管理するテナントのデータに対する処理（生成、読み取り、更新、削除など）を実行する機能を実現する。テナントとは、システムを利用する顧客ごとに用意されるものであり、移行元システム１０３および移行先システム１０４は、システムを利用する顧客のデータを、顧客ごとに用意されたテナントで管理する。テナント情報処理部３０２が処理対象とするテナントのデータは、データベース３０４に格納されている。
３０４はデータベース（ＤＢ）であり、システムが管理する各種データを格納する。

３０３はバッチ処理部であり、システムの管理する各種データ（ネットワーク機器情報、カウンター、ジョブログ、ステータス情報など）に対するバッチ処理（データの変換、移動、集計など）を実行する機能を実現する。なお、バッチ処理とは、一定期間（もしくは一定量）データを集め、所定の手順で、まとめて一括処理を行う処理方式である。処理対象のデータによって、それぞれ処理手順が定義される。また、移行元システム１０３、移行先システム１０４では、複数のバッチ処理を登録することができる（例えば、後述する図６に示すようなバッチ処理）。各バッチ処理のそれぞれの実行タイミングは、予めスケジュールなどで設定可能であり、各バッチ処理を自動で実行することができる。

例えば、バッチ処理部３０３は、ネットワーク機器情報をもとに、各テナントで管理するネットワーク機器台数をカウントする集計処理を、バッチ処理として、毎日０時に実行する。また、バッチ処理部３０３は、例えば、カウンターやジョブログをもとに、単位時間あたりの印刷実績を計算する集計処理を、バッチ処理として８時間間隔で実行する。バッチ処理部３０３が処理対象とする各種データは、データベース３０４に格納されている。また、バッチ処理部３０３は、バッチ処理部３０３が処理した結果として生成されたデータを、データベース３０４に格納する。バッチ処理の詳細については後述する。

＜データ移行システムの機能構成＞
図４は、データ移行システム１０５の機能構成の一例を示すブロック図である。なお、図４に示す機能構成は、データ移行システム１０５のＣＰＵ２０１がＨＤＤ２１１等に格納されるプログラムを読み出して実行することにより実現されるものである。

４０１は通信部であり、ネットワークを介して移行元システム１０３や移行先システム１０４と通信する機能を実現する。４０２は移行処理部であり、移行元システム１０３が保持するデータを、移行先システム１０４へ移行する移行処理を実行する機能を実現する。移行処理の詳細については後述する。

＜テナント情報テーブル＞
図５は、図３に示したデータベース３０４が保持し、テナント情報処理部３０２の処理によって更新されるテナント情報の構成の一例を示すテナント情報テーブルを例示する図である。テナント情報テーブルでは、テナント情報として、移行の状態についても管理する。なお、図５（ａ）は、移行元システム１０３におけるテナント情報テーブルの一例に対応する。また、図５（ｂ）は、移行先システム１０４におけるテナント情報テーブルの一例に対応する。

図５（ａ），図５（ｂ）において、５０１の列はテナントＩＤであり、テナントをシステム内で一意に識別するＩＤを示す。５０２の列はテナント名であり、テナントの名称を示す。５０３の列は移行状態であり、移行処理を行っている場合は「移行中」、移行処理が完了した場合は「移行完了」を設定する。

図５（ａ）の移行元システム１０３において、移行状態５０３が未設定の状態（空白）については、移行処理が行われる前の状態であることを示す。図５（ｂ）の移行先システム１０４において、移行状態５０３が未設定の状態（空白）については、移行先システム１０４側で新規に登録されたテナントを示す。移行状態５０３の値は、データ移行システム１０５で実行する移行処理によって更新される。移行処理の詳細については後述する図７に示す。

＜バッチ処理管理テーブル＞
図６は、図３に示したデータベース３０４が保持し、バッチ処理部３０３の処理によって更新されるバッチ処理管理情報の構成の一例を示すバッチ処理管理テーブルを例示する図である。バッチ処理管理テーブルでは、バッチ処理管理情報として、移行元システム１０３／移行先システム１０４で実行する各種バッチ処理の実行状態、実行日時、実行結果などを管理する。

図６において、６０１の列はテナントＩＤであり、該当行のバッチ管理情報がどのテナントのバッチ処理管理情報かを示す。６０２の列はバッチ処理種別であり、移行元システム１０３／移行先システム１０４で実行する各種バッチ処理の種別を示す。６０３の列は実行状態であり、バッチ処理を実行している場合は「実行中」、バッチ処理を実行していない場合は「未実行」を設定する。６０４の列は最終実行日時であり、バッチ処理を最後に実行した日時を示す。６０５の列は実行結果であり、バッチ処理が成功した場合は成功を、バッチ処理がエラーなどにより失敗した場合は失敗を設定する。

＜移行処理＞
図７は、実施例１においてデータ移行システム１０５の移行処理部４０２が実行する移行処理の手順を例示するフローチャートである。すなわち、図７及び後述する図８〜図１１に示す処理は、データ移行システム１０５のＣＰＵ２０１がＨＤＤ２１１等に格納されるプログラムを読み出して実行することにより実現されるものである。本処理は、システムの管理者などによって、移行元システム１０３が保持するデータを、移行先システム１０４へ移行するための移行指示がなされた際に、データ移行システム１０５の移行処理部４０２が実行する処理である。なお、本処理を開始する際には、システムの管理者などは、移行対象のテナントのリストをデータ移行システム１０５に入力する。

移行処理を開始すると、Ｓ７０１において、移行処理部４０２は、移行先システム１０４のデータベース３０４の性能を上げさせる（ＤＢ性能制御）。例えば、移行処理部４０２は、移行先システム１０４のデータベース３０４の書き込み処理の速度を上げることを、移行先システム１０４に要求する。この要求に応じて、移行先システム１０４は、データベース３０４の書き込み処理の速度を上げる。本ステップの目的は、移行先システム１０４のデータベース３０４の性能を上げることで、移行対象データをより短い時間で移行先システム１０４のデータベース３０４へ登録し、移行にかかる時間を短くすることである。

次に、Ｓ７０２において、移行処理部４０２は、移行対象テナントについて移行元システム１０３の移行状態５０３（図５（ａ））を「移行中」に変更させる。移行開始時の移行状態の変更処理の詳細については後述する図８に示す。

次に、Ｓ７０３において、移行処理部４０２は、移行対象テナントについて移行元システム１０３におけるバッチ処理が実行中の場合に、該実行中のバッチ処理の完了を監視し、該実行中のバッチ処理が完了するまで待機する（移行元システムのバッチ処理の完了待機処理）。移行元システムのバッチ処理の完了待機処理の詳細については後述する図９に示す。

次に、Ｓ７０４において、移行処理部４０２は、移行元システム１０３が保持するデータを、移行先システム１０４へ移行する（データの移行処理）。データの移行処理の詳細については後述する図１０に示す。
次に、Ｓ７０５において、移行処理部４０２は、移行が成功した移行対象テナントについて移行先システム１０４の移行状態５０３を「移行完了」に変更させる（移行完了時の移行状態の変更処理）。移行完了時の移行状態の変更処理の詳細については後述する図１１に示す。

次に、Ｓ７０６において、移行処理部４０２は、上記Ｓ７０１で設定した移行先システム１０４のデータベース３０４の性能を元に戻させる（すなわち性能を下げさせる）。例えば、移行処理部４０２は、移行先システム１０４のデータベース３０４の書き込み処理の速度を元に戻す（上記Ｓ７０1の設定前の状態に下げる）ことを、移行先システム１０４に要求する。この要求に応じて、移行先システム１０４は、データベース３０４の書き込み処理の速度を元に戻す。上記Ｓ７０６の後、移行処理部４０２は、本フローチャートの処理を終了する。

なお、Ｓ７０１の処理を、Ｓ７０２とＳ７０４の間で行うようにしてもよい。また、Ｓ７０６の処理を、Ｓ７０４とＳ７０５の間で行うようにしてもよい。

＜移行開始時の移行状態の変更処理＞
図８は、図７のＳ７０２で実行する移行開始時の移行状態の変更処理の詳細手順を例示するフローチャートである。本処理は、各移行対象テナントについて、移行元システム１０３の移行状態５０３を「移行中」に変更する処理である。

移行開始時の移行状態の変更処理を開始すると、移行処理部４０２は、Ｓ８０１，Ｓ８０６において、Ｓ８０２〜Ｓ８０５に示す処理を、すべての移行対象テナントについて、１テナントずつ実行するように制御する。
Ｓ８０１において、移行処理部４０２は、移行対象テナントのうち、１の未処理のテナントを処理中のテナントとして選択し、Ｓ８０２に処理を進める。
Ｓ８０２において、移行処理部４０２は、移行元システム１０３のテナント情報処理部３０２を通じて、処理中のテナントの移行状態５０３を取得する。例えば、移行処理部４０２は、移行元システム１０３に処理中のテナントの移行状態５０３の取得を要求する。この要求に応じて、移行元システム１０３のテナント情報処理部３０２は、要求されたテナントの移行状態５０３をデータ移行システム１０５に送信する。

次に、Ｓ８０３において、移行処理部４０２は、上記Ｓ８０２で取得した移行状態５０３が「移行前」（＝未設定）であるか否かを判定する。ここで、移行処理部４０２が、移行状態５０３が「移行前」であると判定した場合（Ｓ８０３でＹｅｓの場合）、Ｓ８０４に処理を進める。Ｓ８０４において、移行処理部４０２は、移行元システム１０３のテナント情報処理部３０２を通じて、処理中のテナントの移行状態５０３を「移行中」に変更させる。例えば、移行処理部４０２は、移行元システム１０３に処理中のテナントの移行状態５０３を「移行中」に変更することを要求する。この要求に応じて、移行元システム１０３のテナント情報処理部３０２は、要求されたテナントの移行状態５０３を「移行中」に変更する。

一方、上記Ｓ８０３において、移行処理部４０２が、移行状態５０３が「移行前」でない（つまり「移行中」または「移行完了」）と判定した場合（Ｓ８０３でＮｏの場合）、Ｓ８０５に処理を進める。この判定は、移行対象テナントの入力が間違っていて、既に「移行中」または「移行完了」しているテナントが移行対象になっていた場合、そのテナントを移行対象から除外するために行うものである。
Ｓ８０５において、移行処理部４０２は、処理中のテナントを移行失敗と判定し、移行対象テナントから除外するように制御する。

上記Ｓ８０４又はＳ８０５の処理の後、Ｓ８０６において、移行処理部４０２は、まだ上記Ｓ８０２〜Ｓ８０５の処理を行っていない移行対象テナントがあるか否かを判定する。ここで、上記Ｓ８０２〜Ｓ８０５の処理を行っていない移行対象テナントがあると判定した場合、移行処理部４０２は、上記Ｓ８０１に処理を戻し、次の未処理のテナントに処理を移す。

一方、上記Ｓ８０２〜Ｓ８０５の処理を行っていない移行対象テナントがない（全ての移行対象テナントについてＳ８０２〜Ｓ８０５の処理を行った）と判定した場合、移行処理部４０２は、本フローチャートの処理を終了する。

＜移行元システムのバッチ処理の完了待機処理＞
図９は、図７のＳ７０３で実行する移行元システムのバッチ処理の完了待機処理の詳細手順例を示すフローチャートである。本処理は、移行対象テナントについて移行元システム１０３におけるバッチ処理が実行中の場合に、該実行中のバッチ処理の完了を監視し、該実行中のバッチ処理が完了するまで待機する処理である。なお、移行元システム１０３や移行先システム１０４のバッチ処理部３０３は、後述するバッチ処理に示すように、移行状態５０３が「移行中」のテナントについてはバッチ処理を実行しないように制御する。しかし、移行状態５０３が「移行中」になる前に開始されたバッチ処理については、実行中の可能性がある。そのため、移行元システム１０３のバッチ処理が実行中の場合に完了するまで待機する処理が必要となる。

移行元システムのバッチ処理の完了待機処理を開始すると、Ｓ９０１において、移行処理部４０２は、移行元システム１０３のバッチ処理部３０３を通じて、すべての移行対象テナントのすべてのバッチ処理の実行状態６０３を取得する。例えば、移行処理部４０２は、移行元システム１０３にすべてのテナントのすべてのバッチ処理の実行状態６０３の取得を要求する。この要求に応じて、移行元システム１０３のバッチ処理部３０３は、すべてのテナントのすべてのバッチ処理の実行状態６０３をデータ移行システム１０５に送信する。そして、すべての移行対象テナントのすべてのバッチ処理の実行状態６０３が「未実行」であるか否かを判定する。

ここで、すべての移行対象テナントのすべてのバッチ処理の実行状態６０３が「未実行」であると判定した場合（Ｓ９０１でＹｅｓの場合）、移行処理部４０２は、本フローチャートの処理を終了する。

一方、いずれかの移行対象テナントのいずれかのバッチ処理に実行状態６０３が「未実行」のものがあると判定した場合（Ｓ９０１でＮｏの場合）、移行処理部４０２は、Ｓ９０２に処理を進める。

Ｓ９０２において、移行処理部４０２は、本フローチャートの処理（移行元システムのバッチ処理の完了待機処理）が開始してから（すなわち図７のＳ７０２で移行元システム１０３の移行状態が移行中を示す状態に変更されてから）予め設定された最大待機時間を超えているか否かを判定する。ここで、まだ最大待機時間を超えていないと判定した場合（Ｓ９０２でＮｏの場合）、移行処理部４０２は、Ｓ９０１に処理を戻す。

一方、最大待機時間を超えていると判定した場合（Ｓ９０２で）、移行処理部４０２は、Ｓ９０３に処理を進める。

Ｓ９０３において、移行処理部４０２は、移行元システム１０３のバッチ処理部３０３を通じて、実行状態６０３が実行中のバッチ処理を強制的に停止させ、実行状態を「未実行」に、実行結果を「失敗」に変更させる。例えば、移行処理部４０２は、移行元システム１０３に実行状態６０３が実行中のバッチ処理を強制的に停止させることを要求する。この要求に応じて、移行元システム１０３のバッチ処理部３０３は、実行状態６０３が実行中のバッチ処理を強制的に停止させる。さらに、移行処理部４０２は、移行元システム１０３に上記強制的に停止させたバッチ処理の実行結果６０５を「失敗」に変更することを要求する。この要求に応じて、移行元システム１０３のバッチ処理部３０３は、要求されたバッチ処理の実行結果６０５を「失敗」に変更する。
上記Ｓ９０３の処理の後、移行処理部４０２は、本フローチャートの処理を終了する。

なお、本フローチャートに示す処理の目的は、移行元システム１０３のバッチ処理の完了を待機し続けることで、移行にかかる時間が長くなることを防ぐことである。

＜データの移行処理＞
図１０は、図７のＳ７０４で実行するデータの移行処理の詳細手順例を示すフローチャートである。本処理は、移行元システム１０３が保持するデータを移行先システム１０４へ移行する処理である。

データの移行処理を開始すると、移行処理部４０２は、Ｓ１００１，Ｓ１０１１において、Ｓ１００２〜Ｓ１０１０に示す処理を、すべての移行対象テナントについて、１テナントずつ実行するように制御する。なお、図８のＳ８０５の処理によって、移行対象テナントから除外したテナントについては、Ｓ１００２〜Ｓ１０１０に示す処理を行わないものとする。

まず、Ｓ１００１において、移行処理部４０２は、移行対象テナントのうち、１の未処理のテナントを処理中のテナントとして選択し、Ｓ１００２に処理を進める。
Ｓ１００２において、移行処理部４０２は、移行元システム１０３のデータベース３０４が保持する処理中のテナントのデータを取得する。例えば、移行処理部４０２は、移行元システム１０３に処理中のテナントのデータの取得を要求する。この要求に応じて、移行元システム１０３のテナント情報処理部３０２は、要求されたテナントのデータをデータ移行システム１０５に送信する。

次に、Ｓ１００３において、移行処理部４０２は、移行先システム１０４のデータベース３０４が保持する処理中のテナントのデータを削除させる。移行先システム１０４のデータベース３０４へデータを登録する処理以降でエラーになった場合、移行先システム１０４のデータベース３０４には間違ったデータや中途半端なデータ（例えば更新中の不完全なデータ）が登録されている可能性がある。そのため、移行先システム１０４のデータベース３０４にデータを登録する前に、データの削除を行う。例えば、移行処理部４０２は、移行先システム１０４に処理中のテナントのデータの削除を要求する。この要求に応じて、移行先システム１０４のテナント情報処理部３０２は、要求されたテナントのデータを削除する。

次に、Ｓ１００４において、移行処理部４０２は、上記Ｓ１００２で取得したデータを移行先システム１０４のデータベース３０４へ登録する。なお、移行元システム１０３と移行先システム１０４とで、データを管理しているデータベースの種類が異なる場合や、データ構造が変更になっている場合は、移行処理部４０２は、上記Ｓ１００２で取得したデータを、移行先システム１０４のデータベースに対応するように変換してから登録する。なお、データの変換処理は、上記Ｓ１００２のデータ取得時などに行ってもよい。例えば、移行処理部４０２は、移行先システム１０４に処理中のテナントのデータを送信して登録することを要求する。この要求に応じて、移行先システム１０４のテナント情報処理部３０２は、要求されたテナントのデータをデータベース３０４に登録する。

次に、Ｓ１００５において、移行処理部４０２は、移行元システム１０３と移行先システム１０４の双方のデータベース３０４からデータを取得し、データ比較を行い、正常にデータが移行できたかを確認する。例えば、移行処理部４０２は、移行元システム１０３及び移行先システム１０４に処理中のテナントのデータの取得を要求する。この要求に応じて、移行元システム１０３及び移行先システム１０４のテナント情報処理部３０２は、要求されたテナントのデータをデータ移行システム１０５に送信する。そして、移行処理部４０２は、移行元システム１０３及び移行先システム１０４の双方から取得したデータ比較を行い、正常にデータが移行できたかを確認する。

次に、Ｓ１００６において、移行処理部４０２は、上記Ｓ１００２〜Ｓ１００５の処理がすべて正常終了したかを否かを判定する。ここで、上記Ｓ１００２〜Ｓ１００５の処理がすべて正常終了したと判定した場合（Ｓ１００６でＹｅｓの場合）、移行処理部４０２は、Ｓ１００７に処理を進める。Ｓ１００７において、移行処理部４０２は、処理中の移行対象テナントは移行が成功したと判定し、該判定結果をＲＡＭ２０３等に記憶しておく。

一方、上記Ｓ１００２〜Ｓ１００５の処理のうち正常終了していない処理があると判定した場合（Ｓ１００６でＮｏの場合）、移行処理部４０２は、Ｓ１００８に処理を進める。Ｓ１００８において、移行処理部４０２は、処理中のテナント（データの移行処理が失敗した移行対象テナント）について、データの移行処理のリトライが可能か否かを判定する。リトライが可能か否かの判定を、例えば、以下のように行う。まず、移行処理部４０２は、データの移行処理が失敗した移行対象テナントの移行データサイズを基に移行予想時間を算出し、該移行予想時間を現在時刻に追加し、予め設定された移行完了予定時刻よりも前に完了するか否かの判定を行う。そして、移行処理部４０２は、移行完了予定時刻よりも前に完了すると判定した場合はリトライが可能と判定し、移行完了予定時刻以後に完了すると判定した場合はリトライが不可能と判定する。

上記Ｓ１００８において、データの移行処理のリトライが可能でない（不可能）と判定した場合（Ｓ１００８でＮｏの場合）、移行処理部４０２は、Ｓ１０１０に処理を進める。Ｓ１０１０において、移行処理部４０２は、処理中のテナントは移行が失敗したと判定し、該判定結果をＲＡＭ２０３等に記憶しておく。

一方、上記Ｓ１００８において、データの移行処理のリトライが可能であると判定した場合（Ｓ１００８でＹｅｓの場合）、移行処理部４０２は、Ｓ１００９に処理を進める。
Ｓ１００９において、移行処理部４０２は、処理中のテナントについてデータの移行処理をリトライするか否かを判定する。リトライするかの判定を、例えば、以下のように行う。まず、システムの管理者がデータの移行処理がエラーになった際の情報を確認し、リトライするかを判定する。そして、システムの管理者が判定結果を移行処理部４０２に入力する。移行処理部４０２は、その入力に従ってリトライをするか否かを判定する。

上記Ｓ１００９において、データの移行処理をリトライすると判定した場合（Ｓ１００９でＹｅｓの場合）、移行処理部４０２は、Ｓ１００２に処理を戻し、処理中のテナントについて処理を繰り返す。
一方、データの移行処理をリトライしないと判定した場合（Ｓ１００９でＮｏの場合）、移行処理部４０２は、Ｓ１０１０に処理を進め、処理中のテナントは移行が失敗したと判定する。

上記Ｓ１００７又はＳ１０１０の処理の後、Ｓ１０１１において、移行処理部４０２は、まだ上記Ｓ１００２〜Ｓ１０１０の処理を行っていない移行対象テナントがあるか否かを判定する。ここで、まだ上記Ｓ１００２〜Ｓ１０１０の処理を行っていない移行対象テナントがあると判定した場合、移行処理部４０２は、上記Ｓ１００１に処理を戻し、次の未処理のテナントに処理を移す。

一方、上記Ｓ１００２〜Ｓ１０１０の処理を行っていない移行対象テナントがない（全ての移行対象テナントについてＳ１００２〜Ｓ１０１０の処理を行った）と判定した場合、移行処理部４０２は、本フローチャートの処理を終了する。

＜移行完了時の移行状態の変更処理＞
図１１は、図７のＳ７０５で実行する移行完了時の移行状態の変更処理の詳細手順を例示するフローチャートである。本処理は、移行が成功した移行対象テナントについて移行先システム１０４の移行状態５０３を移行完了に変更するものである。

移行完了時の移行状態の変更処理を開始すると、移行処理部４０２は、Ｓ１１０１，Ｓ１１０６において、Ｓ１１０２〜Ｓ１１０５に示す処理を、すべての移行対象テナントについて、１テナントずつ実行するように制御する。

まず、Ｓ１１０１において、移行処理部４０２は、移行対象テナントのうち、１の未処理のテナントを処理中のテナントとして選択し、Ｓ１１０２に処理を進める。
Ｓ１１０２において、移行処理部４０２は、図８のＳ８０５、図１０のＳ１００７、Ｓ１０１０の処理結果から、処理中のテナントの移行が成功したか否かを判定する。ここで、移行が成功したと判定した場合（Ｓ１１０２でＹｅｓの場合）、移行処理部４０２は、Ｓ１１０３に処理を進める。

Ｓ１１０３において、移行処理部４０２は、移行元システム１０３のテナント情報処理部３０２を通じて、処理中のテナントの移行状態５０３を「移行完了」に変更させる。例えば、移行処理部４０２は、移行元システム１０３に処理中のテナントの移行状態５０３を「移行完了」に変更することを要求する。この要求に応じて、移行元システム１０３のテナント情報処理部３０２は、要求されたテナントの移行状態５０３を「移行完了」に変更する。

さらに、Ｓ１１０４において、移行処理部４０２は、移行先システム１０４のテナント情報処理部３０２を通じて、処理中のテナントの移行状態５０３を「移行完了」に変更させる。例えば、移行処理部４０２は、移行先システム１０４に処理中のテナントの移行状態５０３を「移行完了」に変更することを要求する。この要求に応じて、移行先システム１０４のテナント情報処理部３０２は、要求されたテナントの移行状態５０３を「移行完了」に変更する。

一方、上記Ｓ１１０２において、移行が成功していない（すなわち移行が失敗した）と判定した場合（Ｓ１１０２でＮｏの場合）、移行処理部４０２は、Ｓ１１０５に処理を進める。
Ｓ１１０５において、移行処理部４０２は、移行元システム１０３のテナント情報処理部３０２を通じて、処理中の移行対象テナントの移行状態５０３を移行前（＝未設定）に変更させる。例えば、移行処理部４０２は、移行元システム１０３に処理中のテナントの移行状態５０３を移行前（＝未設定）に変更することを要求する。この要求に応じて、移行元システム１０３のテナント情報処理部３０２は、要求されたテナントの移行状態５０３を移行前（＝未設定）に変更する。

上記Ｓ１１０４又はＳ１１０５の処理の後、移行処理部４０２は、Ｓ１１０６において、まだ上記Ｓ１１０２〜Ｓ１１０５の処理を行っていない移行対象テナントがあるか否かを判定する。ここで、まだ上記Ｓ１１０２〜Ｓ１１０５の処理を行っていない移行対象テナントがあると判定した場合、移行処理部４０２は、上記Ｓ１１０１に処理を戻し、次の未処理のテナントに処理を移す。

一方、上記Ｓ１１０２〜Ｓ１１０５の処理を行っていない移行対象テナントがない（全ての移行対象テナントについてＳ１１０２〜Ｓ１１０５の処理を行った）と判定した場合、移行処理部４０２は、本フローチャートの処理を終了する。

＜バッチ処理＞
図１２は、移行元システム１０３と移行先システム１０４のバッチ処理部３０３が実行するバッチ処理の手順例を示すフローチャートである。すなわち、図１２に示す処理は、移行元システム１０３と移行先システム１０４のＣＰＵ２０１がＨＤＤ２１１等に格納されるプログラムを読み出して実行することにより実現されるものである。本処理は、移行元システム１０３と移行先システム１０４において、移行中のテナントに対するバッチ処理は実行しないように制御する処理である。本処理の目的は、移行中に、移行対象テナントのデータがバッチ処理によって変更されることを防ぐことである。これにより、中途半端な状態でデータが移行されることがなくなる。さらに、図１０のＳ１００５の移行元システムと移行先システムのデータの整合性チェックにおいて、正しいチェック結果が得られるようになる。

バッチ処理を開始すると、バッチ処理部３０３は、Ｓ１２０１，Ｓ１２０６において、Ｓ１２０２〜Ｓ１２０５に示す処理を、すべてのテナントについて、１テナントずつ実行するように制御する。なお、バッチ処理の処理対象のテナントが複数テナントではなく、１テナントの場合は、バッチ処理部３０３は、Ｓ１２０２〜Ｓ１２０５の処理を一度行う。

まず、Ｓ１２０１において、バッチ処理部３０３は、テナントのうち、１の未処理のテナントを処理中のテナントとして選択し、Ｓ１２０２に処理を進める。
Ｓ１２０２において、バッチ処理部３０３は、テナント情報処理部３０２を通じて、処理中のテナントの移行状態５０３を取得する。

次に、Ｓ１２０３で、バッチ処理部３０３は、上記Ｓ１２０２で取得した移行状態５０３を確認し、判定する。ここで、移行状態５０３が「未設定（移行前）」または「移行完了」であると判定した場合、バッチ処理部３０３は、Ｓ１２０４に処理を進める。

Ｓ１２０４において、バッチ処理部３０３は、処理中のテナントのバッチ処理を実行する。このとき、バッチ処理部３０３は、バッチ処理の開始前に実行状態６０３を「実行中」に変更する。さらに、バッチ処理部３０３は、バッチ処理の完了後に実行状態６０３を「未実行」にし、最終実行日時６０４、実行結果６０５を更新し、Ｓ１２０６に処理を進める。

一方、移行状態５０３が「未設定（移行前）」でも「移行完了」でもないと判定した場合（Ｓ１２０３で「移行中」の場合）、バッチ処理部３０３は、Ｓ１２０５に処理を進める。
Ｓ１２０５において、バッチ処理部３０３は、処理中のテナントのバッチ処理を実行せずに、Ｓ１２０６に処理を進める。

Ｓ１２０６において、バッチ処理部３０３は、Ｓ１２０２〜Ｓ１２０５の処理を行っていないテナントがあるか否かを判定する。ここで、Ｓ１２０２〜Ｓ１２０５の処理を行っていないテナントがあると判定した場合、バッチ処理部３０３は、Ｓ１２０１に処理を戻し、次の未処理のテナントに処理を移す。

一方、上記Ｓ１２０２〜Ｓ１２０５の処理を行っていないテナントがない（全てのテナントについてＳ１２０２〜Ｓ１２０５の処理を行った）と判定した場合、バッチ処理部３０３は、本フローチャートの処理を終了する。

以上示したように、本実施例では、データ移行システム１０５は、移行元システム１０３における、データ移行対象のテナントの移行状態について、移行開始時に移行中を示す状態に変更させる。また、データ移行システム１０５は、移行完了時に移行が成功したテナントについては、移行元システム１０３及び移行先システム１０４における移行状態について、移行完了を示す状態に変更させる。なお、移行元システム１０３は、テナントの移行状態が、移行前および移行完了を示す状態の場合は、バッチ処理を実行するように制御し、移行中を示す状態の場合は、バッチ処理を実行しないように制御する。また、移行先システム１０４は、テナントの移行状態が、移行完了を示す状態の場合は、バッチ処理を実行するように制御し、移行中を示す状態の場合は、バッチ処理を実行しないように制御する。以上の構成により、バッチ処理を実行するシステムのデータを、移行元及び移行先のシステムを並行稼働しながら段階的に移行する場合であっても、データを正常に移行でき、移行後のデータチェックも正常に行えるデータ移行システムを提供できる。

実施例２では、移行元システム１０３と移行先システム１０４のバッチ処理部３０３が、バッチ処理によって課金データを作成している場合の実施例について説明する。
実施例２では、バッチ処理によって１日１回課金データを作成している場合を例にして説明するが、本発明はこの例に限定されるものではない。以下では、課金データを作成するバッチ処理を、課金データ作成処理と呼ぶ。

クラウドサービスの利用料を顧客に課金する方法として、例えば以下の（１），（２）がある。
（１）回数課金方法；顧客が提供するサービスを利用した回数をカウントして課金する方法。
（２）管理数課金方法；顧客が提供するサービスに登録しているネットワーク機器数などをカウントして課金する方法。

移行元システム１０３と移行先システム１０４のクラウドサービスが並行稼動し、段階的に移行が実施される場合、システムの管理者が課金額の確認をするためには、移行元システム１０３と移行先システム１０４の両システムで確認する必要がある。

この手間を無くすために、移行元システム１０３から移行先システム１０４に課金データを送信し、移行先システム１０４で課金データを集計し、利用料を移行先システム１０４のみで確認できるようにすることが考えられる。このような仕組みにした場合、回数課金のデータは、移行元システム１０３と移行先システム１０４の利用回数を加算しても問題ない。例えば、顧客が移行元システム１０３でサービスを２回利用し、移行先システム１０４でサービスを３回利用したとする。その場合、移行元システム１０３は利用回数が２回という課金データを作成し、移行先システム１０４は利用回数が３回という課金データを作成する。顧客がサービスを利用した回数は合計５回なので、移行元システム１０３と移行先システム１０４の課金データを加算し５回とすれば正しい。

しかし、管理数課金のデータは、移行元システム１０３と移行先システム１０４の管理数を加算すると問題がある。例えば、顧客が移行元システム１０３でネットワーク機器１０２を１０台管理していたとする。データの移行によって、顧客の管理しているネットワーク機器１０２のデータは移行先システム１０４に移行される。その場合、移行元システム１０３は管理数が１０台という課金データを作成し、移行先システム１０４でも管理数が１０台という課金データを作成する。顧客がサービスで管理している台数は１０台なので、移行元システム１０３と移行先システム１０４の課金データを加算し２０台とすると正しくない。このように、移行元システム１０３から移行先システム１０４に課金データを送信すると、課金方法によっては正しい課金ができないという課題があった。

また、移行中に課金データ作成処理を実行していなかった場合、課金データ作成処理の実行時刻が移行中の時間帯と重なると、課金データが作成されない日が発生するという課題があった。

実施例２では、移行元システム１０３が課金データ作成処理によって作成したデータを移行先システム１０４へ送信している場合であっても、正しく課金するための仕組みについて説明する。また、課金データ作成処理の実行時刻が移行中の時間帯と重なった場合であっても、課金データの作成漏れが発生しないための仕組みについて説明する。
なお、以下では実施例１と同一の構成については説明を省略し差分についてのみ説明する。

＜移行処理＞
図１３は、実施例２においてデータ移行システム１０５の移行処理部４０２が実行する移行処理の手順を例示するフローチャートである。すなわち、図１３に示す処理は、データ移行システム１０５のＣＰＵ２０１がＨＤＤ２１１等に格納されるプログラムを読み出して実行することにより実現されるものである。本処理は、実施例１の図７で示した移行処理を拡張したものである。本処理では、移行完了後に課金データ作成処理を実行する。なお、図７と同一のステップには同一のステップ番号を付してある。

Ｓ７０１〜Ｓ７０６は、実施例１で示した通りである。
Ｓ７０６の後、Ｓ１３０１において、移行処理部４０２は、移行先システム１０４のバッチ処理部３０３を通じて、移行先システム１０４において課金データ作成処理を実行させる。例えば、移行処理部４０２は、移行先システム１０４に課金データ作成処理を実行することを要求する。この要求に応じて、移行先システム１０４のバッチ処理部３０３は、課金データ作成処理（詳細は図１４に示す）を実行する。
Ｓ１３０１の処理の後、移行処理部４０２は、本フローチャートの処理を終了する。

＜移行先システムの課金データ作成処理＞
図１４は、実施例２において移行先システム１０４のバッチ処理部３０３が実行する移行先システムの課金データ作成処理の手順を例示するフローチャートである。すなわち、図１４に示す処理は、移行先システム１０４のＣＰＵ２０１がＨＤＤ２１１等に格納されるプログラムを読み出して実行することにより実現されるものである。本処理は、実施例１の図１２で示したバッチ処理を拡張したものである。本処理では、管理数の課金データ作成処理の場合、最終実行日時をもとに、課金データの作成漏れがあるかを判定する、さらに、課金データの作成漏れがあると判定した場合に、課金データを作成する処理を追加し、課金データの作成漏れが発生しないようにする。なお、図１２と同一のステップには同一のステップ番号を付してある。

Ｓ１２０１〜Ｓ１２０６は、実施例１で示した通りである。
Ｓ１２０２の後、Ｓ１４０１において、バッチ処理部３０３は、Ｓ１２０２で取得した移行状態５０３を確認し、判定する。ここで、移行状態５０３が「移行中」であると判定した場合、バッチ処理部３０３は、Ｓ１２０５に処理を進め、パッチ処理を実行しないように制御する。

一方、上記Ｓ１４０１において、移行状態５０３が「未設定」または「移行完了」であると判定した場合、バッチ処理部３０３は、Ｓ１４０２に処理を進める。
Ｓ１４０２において、バッチ処理部３０３は、作成対象の課金データの種類を確認し、判定する。ここで、作成対象の課金データが「回数課金データ」であると判定した場合、バッチ処理部３０３は、Ｓ１２０４に処理を進め、バッチ処理を実行するように制御する。

一方、上記Ｓ１４０２において、作成対象の課金データが「管理数課金データ」であると判定した場合、バッチ処理部３０３は、Ｓ１４０３に処理を進める。
Ｓ１４０３において、バッチ処理部３０３は、最終実行日時６０４が本日か否かを判定する。ここで、最終実行日時６０４が本日であると判定した場合（Ｓ１４０３でＹｅｓの場合）、バッチ処理部３０３は、Ｓ１２０５に処理を進め、パッチ処理を実行しないように制御する。
一方、上記Ｓ１４０３において、最終実行日時６０４が本日ではないと判定した場合（Ｓ１４０３でＮｏの場合）、バッチ処理部３０３は、Ｓ１２０４に処理を進め、バッチ処理を実行するように制御する。

なお、上記Ｓ１４０３の判定では、１日１回課金データを作成している場合を例にしているため、最終実行日時が本日ではない場合（Ｓ１４０３でＮｏの場合）は、本日分の課金データの作成漏れがあると判定し、課金データを作成する（すなわちバッチ処理を実行する）ように制御している。例えば、１週間に１回の間隔で課金データを作成している場合には、最終実行日時が今週か否かを判定条件にする。また、１月に１回の間隔で課金データを作成している場合には、最終実行日時が今月か否かを判定条件にする。また、１年に１回の間隔で課金データを作成している場合には、最終実行日時が今年か否かを判定条件にする。

このように、実施例２の移行先システム１０４では、移行状態が移行完了を示すテナントのデータについてバッチ処理を実行するか否かを、該バッチ処理で作成されるデータの種類、及び、該バッチ処理が最後に実行されたタイミングに基づいて決定する。

＜移行元システムの課金データ作成処理＞
図１５は、実施例２における移行元システム１０３のバッチ処理部３０３が実行する移行元システムの課金データ作成処理の手順を例示するフローチャートである。すなわち、図１５に示す処理は、移行元システム１０３のＣＰＵ２０１がＨＤＤ２１１等に格納されるプログラムを読み出して実行することにより実現されるものである。本処理は、実施例１の図１２で示したバッチ処理を拡張したものである。本処理によって作成された課金データは、移行先システム１０４へ送信される。本処理では、作成対象の課金データが回数課金のデータの場合は課金データを作成するように制御し、管理数課金のデータの場合は課金データを作成しないように制御する。これにより、移行元システム１０３が課金データ作成処理によって作成したデータを移行先システム１０４へ送信している場合であっても、正しく課金できるようにする。なお、図１２と同一のステップには同一のステップ番号を付してある。

Ｓ１２０１〜Ｓ１２０６は、実施例１で示した通りである。
Ｓ１２０２の後、Ｓ１５０１において、バッチ処理部３０３は、Ｓ１２０２で取得した移行状態５０３を確認し、判定する。ここで、移行状態５０３が「移行前（＝未設定）」であると判定した場合、バッチ処理部３０３は、Ｓ１２０４に処理を進め、バッチ処理を実行するように制御する。

また、上記Ｓ１５０１において、移行状態５０３が「移行中」であると判定した場合、バッチ処理部３０３は、Ｓ１２０５に処理を進め、パッチ処理を実行しないように制御する。
また、上記Ｓ１５０１において、移行状態５０３が「移行完了」であると判定した場合、バッチ処理部３０３は、Ｓ１５０２に処理を進める。

Ｓ１５０２で、バッチ処理部３０３は、作成対象の課金データが何かを確認し、判定する。ここで、作成対象の課金データが「回数課金データ」であると判定した場合、バッチ処理部３０３は、Ｓ１２０４に処理を進め、バッチ処理を実行するように制御する。

一方、上記Ｓ１５０２において、作成対象の課金データが「管理数課金データ」であると判定した場合、バッチ処理部３０３は、Ｓ１２０５に処理を進め、パッチ処理を実行しないように制御する。
つまり、作成対象の課金データが回数課金のデータの場合は課金データを作成するように制御し、管理数課金のデータの場合は課金データを作成しないように制御する。

このように、実施例２の移行元システム１０３では、移行状態が移行完了を示すテナントのデータについてバッチ処理を実行するか否かを、該バッチ処理で作成されるデータの種類に基づいて決定する。

以上のように、実施例２によれば、移行元システム１０３が課金データ作成処理によって作成したデータを移行先システム１０４へ送信している場合であっても、正しく課金することができる。また、課金データ作成処理の実行時刻が移行中の時間帯と重なった場合であっても、課金データの作成漏れが発生しないようにすることができる。

なお、実施例２では課金データ作成処理を例に説明したが、課金データ作成処理に限定されるものではない。例えば、あるバッチ処理で作成されるデータが、システムで提供されるサービスを利用した回数に応じて算出される種類のデータである場合には、移行元システム１０３および移行先システム１０４では、移行状態が移行完了を示すデータについて、該バッチ処理を実行すると決定する。一方、そのバッチ処理で作成されるデータが、システムで提供されるサービスに登録されている機器の数に応じて算出される種類のデータである場合には、移行元システム１０３では、移行状態が移行完了を示すデータについて、該バッチ処理を実行しないと決定し、移行先システム１０４では、移行状態が移行完了を示すデータについて、そのバッチ処理が最後に実行されたタイミングに基づいて、そのバッチ処理を実行するか否かを決定するように構成してもよい。

実施例３では、移行先システム１０４における移行完了後の初回バッチ処理に要する時間が、通常よりも長くなる場合があり、これを解決する実施例について説明する。
前回の処理からの差分データのみを処理対象にするバッチ処理がある。このようなバッチ処理の処理対象データは、通常は前回の処理からの差分データのみである。しかし、移行完了後の初回バッチ処理では、通常の処理対象データよりも多くのデータを処理しなければならない場合がある。例えば、前回の処理からの差分データのみをデータベースに登録するようなバッチ処理がある。また、移行元システム１０３と移行先システム１０４とでデータベースの種類が異なる場合がある。このような場合、移行先システム１０４の移行完了後の初回バッチ処理では、すべてのデータを新しいデータベースに登録する必要がある。そのため、移行完了後の初回バッチ処理に要する時間は、通常よりも長くなる。

また、単純に、移行中にバッチ処理を実行していなかった場合、移行完了後の初回バッチ処理では、移行中に処理するはずだったデータをまとめて処理する。そのため、移行完了後の初回バッチ処理に要する時間は、通常よりも長くなる。
実施例３では、移行先システム１０４における移行完了後の初回バッチ処理に要する時間を、短くするための仕組みについて説明する。なお、以下、実施例１との差分について説明する。

＜移行処理＞
図１６は、実施例３においてデータ移行システム１０５の移行処理部４０２が実行する移行処理の手順を例示するフローチャートである。すなわち、図１６に示す処理は、データ移行システム１０５のＣＰＵ２０１がＨＤＤ２１１等に格納されるプログラムを読み出して実行することにより実現されるものである。本処理は、実施例１の図７で示した移行処理を拡張したものである。本処理では、移行完了後から初回バッチ処理が完了するまでの間、バッチ処理を実行するサーバの性能を上げる処理を追加し、移行完了後の初回バッチ処理に要する時間を短くする。なお、図７と同一のステップには同一のステップ番号を付してある。

Ｓ７０１〜Ｓ７０６は、実施例１で示した通りである。
Ｓ７０６の後、Ｓ１６０１において、移行処理部４０２は、移行先システム１０４のバッチ処理を実行するサーバの性能を上げさせる。例えば、移行処理部４０２は、移行先システム１０４のバッチ処理を実行するサーバのＣＰＵを高性能に性能アップする、また使用可能なＲＡＭ容量を大きくすることを、移行先システム１０４に要求する。この要求に応じて、移行先システム１０４は、バッチ処理を実行するサーバのＣＰＵを高性能に性能アップする、また使用可能なＲＡＭ容量を大きくする。すなわち、移行処理部４０２は、データ移行が完了した後の移行先システム１０４における初回のバッチ処理の実行前に、移行先システム１０４の性能を上げるように、移行先システム１０４の処理能力を制御する。本処理の目的は、移行先システム１０４のバッチ処理を実行するサーバの性能を上げることで、移行完了後の初回バッチ処理に要する時間を短くすることである。

次に、Ｓ１６０２において、移行処理部４０２は、移行先システム１０４の初回バッチ処理が完了するまで待機する。

次に、Ｓ１６０３において、移行処理部４０２は、上記Ｓ１６０１で設定した移行先システム１０４のバッチ処理を実行するサーバの性能を元に戻す（上記Ｓ１６０１の設定前の状態に下げる）。例えば、移行処理部４０２は、移行先システム１０４のバッチ処理を実行するサーバのＣＰＵの性能を元に戻す（下げる）、また使用可能なＲＡＭ容量を元に戻す（小さくする）ことを、移行先システム１０４に要求する。この要求に応じて、移行先システム１０４は、バッチ処理を実行するサーバのＣＰＵを性能ダウンする、また使用可能なＲＡＭ容量を小さくする。上記Ｓ１６０３の処理の後、移行処理部４０２は、本フローチャートの処理を終了する。

以上のように、実施例３によれば、移行先システム１０４における移行完了後の初回バッチ処理に要する時間を、短くすることができる。

実施例４では、移行先システム１０４における移行完了後の初回バッチ処理に要する時間を、短くするための、実施例３とは別の仕組みについて説明する。以下では実施例３との差分について説明する。

＜移行処理＞
図１７は、実施例４においてデータ移行システム１０５の移行処理部４０２が実行する移行処理の手順を例示するフローチャートである。すなわち、図１７に示す処理は、データ移行システム１０５のＣＰＵ２０１がＨＤＤ２１１等に格納されるプログラムを読み出して実行することにより実現されるものである。本処理は、実施例３の図１６で示した移行処理の一部を変更したものである。本処理では、移行完了後から初回バッチ処理が完了するまでの間、バッチ処理を実行するサーバの性能を上げる、または、サーバを増やす処理を追加し、移行完了後の初回バッチ処理に要する時間を短くする。なお、図１６と同一のステップには同一のステップ番号を付してある。

Ｓ７０１〜Ｓ７０６、Ｓ１６０２は、実施例３で示した通りである。

Ｓ７０６の後、Ｓ１７０１において、移行処理部４０２は、移行先システム１０４のバッチ処理に関するオートスケールの設定を、オートスケールアップまたはオートスケールアウトが発生しやすいように変更させる。オートスケールの設定とは、例えば、キュー内のメッセージ数が閾値を超えた場合にメッセージを取得して自動的にバッチ処理を実行するサーバの台数を増加するスケールアウトの発動をさせるための条件等の設定、また、バッチ処理を実行するサーバのＣＰＵ使用率やＲＡＭ使用率が高い状態が一定時間以上続いた場合に自動的にバッチ処理を実行するサーバを高性能なサーバに変更するスケールアップの発動をさせるための条件等の設定を示す。このようなバッチ処理に関するオートスケールの設定を、オートスケールアップまたはオートスケールアウトが発生しやすいように変更させる。例えば、移行処理部４０２は、移行先システム１０４のバッチ処理に関するオートスケールの設定を、オートスケールアップまたはオートスケールアウトが発生しやすい設定に変更することを、移行先システム１０４に要求する。この要求に応じて、移行先システム１０４は、バッチ処理に関するオートスケールの設定を、オートスケールアップまたはオートスケールアウトが発生しやすい設定に変更する。本処理の目的は、移行先システム１０４のバッチ処理を実行するサーバをスケールアップまたはスケールアウトさせることで、移行完了後の初回バッチ処理に要する時間を短くすることである。

また、Ｓ１６０２の後、Ｓ１７０２において、移行処理部４０２は、上記Ｓ１７０１で設定した移行先システム１０４のバッチ処理に関するオートスケールの設定を元（上記Ｓ１７０１の設定前の状態）に戻させる。例えば、移行処理部４０２は、移行先システム１０４のバッチ処理に関するオートスケールの設定を元の設定に戻すことを、移行先システム１０４に要求する。この要求に応じて、移行先システム１０４は、バッチ処理に関するオートスケールの設定を元に戻す。
上記Ｓ１７０２の後、移行処理部４０２は、本フローチャートの処理を終了する。

以上のように、実施例４によれば、移行先システム１０４における移行完了後の初回バッチ処理に要する時間を、短くすることができる。

以上のように、本発明の各実施例は、ネットワーク機器１０２の管理サービスが動作する移行元システム１０３を、移行先システム１０４に移行する際の機能に関するものである。各実施例において、システムの移行は、並行動作する移行元システム１０３と移行先システム１０４との間で、データベース３０４で管理されるデータなどを移行することで行わる。例えば、デバイス管理サービスが動作するクラウド環境を、新クラウド環境に移行する際に、各クラウド環境で並行動作する管理サービス間で、管理データなどを移行する。データ移行システム１０５は、移行元システム１０３におけるバッチ処理の進捗、データ移行の状態に基づいて、移行元システム１０３及び移行先システム１０４の移行に係るステータス（図５に示す移行状態５０３）を管理する。移行元システム１０３及び移行先システム１０４では、このステータス（移行状態５０３）に応じて、バッチ処理の実行の可否を制御する。

すなわち、データ移行システム１０５は、移行元システム１０３のデータベースで管理される移行対象のデータの移行状態を移行中に変更させる。さらに、データ移行システム１０５は、移行元システム１０３で実行中のバッチ処理の完了を待機する。さらに、データ移行システム１０５は、移行元システム１０３のデータベースで管理される移行対象のデータを取得して移行先システム１０４のデータベースに登録する。さらに、データ移行システム１０５は、移行元システム１０３のデータベースで管理される各データのうち、移行に成功したデータの移行状態を移行完了に変更させ、移行に失敗したデータの移行状態を移行前に変更させる。また、移行元システム１０３及び移行先システム１０４では、移行状態が移行中を示すデータに対してはバッチ処理が実行されないように制御する。なお、データ移行システム１０５は、データの移行前に、移行先システム１０４のデータベースの性能を上げておき、データの移行後に、移行先システム１０４のデータベースの性能を元に戻させるように制御する。このような構成により、バッチ処理を実行するシステムのデータを、移行元及び移行先のシステムを並行稼働しながら段階的に移行する場合であっても、データを高速かつ正常に移行でき、移行後のデータチェックも正常に行えるデータ移行システムを提供できる。

なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されていてもよい。
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能である。具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
また、上記各実施例を組み合わせた構成も全て本発明に含まれるものである。

（その他の実施例）
本発明は、上述の実施例の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。
本発明は上記実施例に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施例の有機的な組合せを含む）が可能であり、それらを本発明の範囲から除外するものではない。即ち、上述した各実施例及びその変形例を組み合わせた構成も全て本発明に含まれるものである。

Claims

第１のシステムのデータベースで管理されるデータの、該第１のシステムから第２のシステムへのデータ移行を制御するデータ移行システムであって、
前記第１のシステムのデータベースで管理される移行対象のデータの移行状態を、移行中を示す状態に変更させる変更手段と、
前記第１のシステムで実行中のバッチ処理の完了を監視する監視手段と、
前記第１のシステムのデータベースで管理される移行対象のデータを取得し、該取得したデータを前記第２のシステムのデータベースに登録することで、データ移行を実行する移行手段と、を有し、
前記変更手段は、前記第１のシステムのデータベースで管理される移行対象の各データのうち、前記移行手段によるデータ移行に成功したデータの移行状態を、移行完了を示す状態に変更させ、
前記変更手段は、前記第１のシステムのデータベースで管理される移行対象の各データのうち、前記移行手段によるデータ移行に失敗したデータの移行状態を、移行前を示す状態に変更させ、
前記第１のシステム及び前記第２のシステムでは、移行状態が移行中を示すデータに対してはバッチ処理が実行されないことを特徴とするデータ移行システム。
前記移行手段によるデータ移行の前に、前記第２のシステムのデータベースの性能を上げることを前記第２のシステムに要求する第１の制御手段を、有し、
前記第１の制御手段は、前記移行手段によるデータ移行の後に、前記第２のシステムのデータベースの性能を下げることを前記第２のシステムに要求することを特徴とする請求項１に記載のデータ移行システム。
前記第２のシステム及び前記第１のシステムでは、バッチ処理で作成されるデータがサービスを利用した回数に応じて算出される種類のデータである場合には、移行状態が移行完了を示すデータについて、該バッチ処理を実行すると決定されることを特徴とする請求項１又は２に記載のデータ移行システム。
前記第２のシステムでは、バッチ処理で作成されるデータがサービスに登録されている機器の数に応じて算出される種類のデータである場合には、移行状態が移行完了を示すデータについて、該バッチ処理が最後に実行されたタイミングに基づいて、該バッチ処理を実行するか否かが決定されることを特徴とする請求項１乃至３のいずれか１項に記載のデータ移行システム。
前記第１のシステムでは、バッチ処理で作成されるデータがサービスに登録されている機器の数に応じて算出される種類のデータである場合には、移行状態が移行完了を示すデータについて、該バッチ処理を実行しないと決定されることを特徴とする請求項１乃至４のいずれか１項に記載のデータ移行システム。
前記第１のシステム及び前記第２のシステムでは、顧客のデータが、顧客ごとに用意されたテナントで管理され、
前記移行手段は、前記テナントの単位でデータ移行を実行し、
前記第１のシステム及び前記第２のシステムでは、前記テナントの単位でバッチ処理の実行の可否が決定されることを特徴とする請求項１乃至５のいずれか１項に記載のデータ移行システム。
前記監視手段は、前記変更手段により移行状態が移行中を示す状態に変更されてからの待機時間が所定の時間を超えた場合には、前記第１のシステムで実行中のバッチ処理を停止させ、該停止させたバッチ処理の実行状態を、失敗を示す状態に変更させることを特徴とする請求項１乃至６のいずれか１項の記載のデータ移行システム。
前記データ移行が完了した後の前記第２のシステムにおける初回のバッチ処理の実行前に、前記第２のシステムの性能を上げることを前記第２のシステムに要求する第２の制御手段を、有し、
前記第２の制御手段は、前記初回のバッチ処理の完了後に、前記第２のシステムの性能を下げることを前記第２のシステムに要求することを特徴とする請求項１乃至７のいずれか１項に記載のデータ移行システム。
前記データ移行が完了した後の前記第２のシステムにおける初回のバッチ処理の実行前に、前記第２のシステムにおけるオートスケールの設定について、スケールアップまたはスケールアウトが発生しやすい設定への変更を前記第２のシステムに要求する第３の制御手段と、
前記第３の制御手段は、前記初回のバッチ処理の完了後に、前記第２のシステムにおけるオートスケールの設定を、該変更の前の状態に戻すことを前記第２のシステムに要求することを特徴とする請求項１乃至７のいずれか１項に記載のデータ移行システム。
前記データ移行システムは、前記第２のシステム内に構築されることを特徴とする請求項１乃至９のいずれか１項に記載のデータ移行システム。
第１のシステムのデータベースで管理されるデータの、該第１のシステムから第２のシステムへのデータ移行を制御するデータ移行システムの制御方法であって、
前記第１のシステムのデータベースで管理される移行対象のデータの移行状態を、移行中を示す状態に変更させる第１の変更ステップと、
前記第１のシステムで実行中のバッチ処理の完了を監視する監視ステップと、
前記第１のシステムのデータベースで管理される移行対象のデータを取得し、該取得したデータを前記第２のシステムのデータベースに登録することで、データ移行を実行する移行ステップと、
前記第１のシステムのデータベースで管理される移行対象の各データのうち、前記移行ステップでのデータ移行に成功したデータの移行状態を、移行完了を示す状態に変更させる第２の変更ステップと、
前記第１のシステムのデータベースで管理される移行対象の各データのうち、前記移行ステップでのデータ移行に失敗したデータの移行状態を、移行前を示す状態に変更させる第３の変更ステップと、を有し、
前記第１のシステム及び前記第２のシステムでは、移行状態が移行中を示すデータに対してはバッチ処理が実行されないことを特徴とするデータ移行システムの制御方法。