（1）一斉移行方式

一斉移行方式とは、現行システムから新システムへ一斉に移行する方式です。現行システムと新システムを並行運用する必要がないため、問題が発生しない場合には、コストや手間を抑えられる点がメリットです。
この方式の場合、万が一システム移行で問題が発生した際には、一旦全ての機能を現行システムへ切り戻します。
移行のために停止期間を設け、その間に全てのテストを終了しなければならないため、十分な移行作業とテストシミュレーションを行い、手順および連絡体制を確認しておく必要があります。
移行に失敗した際には、大きな影響が発生するリスクの大きい方式となるため、余裕がある計画を立て十分なシステム停止期間を設定する必要があります。

移行終了後の運用で新システムに不測の問題が発生することも考慮すると、万が一のために現行システムはしばらく切り戻しができるように停止の状態で残しておく必要があります。
その際の作業は、データ移行も含め非常に複雑になるため、手順などを確認しておきましょう。

（2）順次移行方式

順次移行方式は、業務単位や機能単位などに区切って段階的に移行する方式です。段階的に移行するため、まとまった移行期間を取れなくても移行を行える点などがメリットです。また、移行後にトラブルが生じた場合でも、業務影響を局所化できます。
複数の業務や機能が共有するデータやプログラムが多数存在する場合は、データの不整合が発生しないように、段階の切り分けは慎重に行う必要があります。

デメリットとしては、複数回にわたってシステム移行を行うため、移行の手間やコストがかかる点です。

（3）並行運用移行方式

並行運用移行方式は、現行システムと新システムをしばらく並行運用しながら検証を行い、新システムに問題がないことがわかった時点で現行システムを停止する方式です。現行システムと新システムを並行運用するため、新システムにトラブルが発生した際のリスクを低減できる点がメリットです。

一方、現行システムと新システムの両方へのデータ入力を行う場合、データ不整合が発生しやすく影響のシミュレーションを十分に行うと同時に、高速にデータ同期を行う仕組みの構築が必要となり、手間・コストが大きくなる場合があります。

（4）パイロット移行方式

パイロット移行方式は、一部の業務などを先行して移行・検証した後、本格的に移行する方式です。パイロット移行を行う業務や機能、拠点の移行後の状況を確認してから全体へ導入するため、会社全体としての移行リスクを抑えられる点がメリットです。

ただし、パイロット移行後の検証期間などが生じるため、会社全体のシステム移行が完了するまでに長期間を要する点がデメリットとなります。

（1）現行システムを調査する

はじめに、移行対象となる現行システムの調査を行います。調査する主な内容としては、以下が挙げられます。

【主な調査内容】

現行システムを調査する際は、必ず現行システムの運用に詳しい担当者もメンバーに加え、現行システムの仕様や運用状況などを網羅的に洗い出すことが重要です。

特に、現状抱えている問題に関しては、些細な事項に関しても懸念点も含めて全て洗い出す必要があります。これを怠ると、移行後に問題が発生する確率が跳ね上がるでしょう。
設計書や仕様書に記載されていない事項に関しても、可能な限りヒアリングしてください。

また、場合によっては、現行環境を調査するためのツールを作って情報収集を行います。
現行システムが稼働している状況を保存するために、調査前にシステム全体のバックアップをとっておきましょう。

（2）移行するデータを整理する

次に、現行システムの調査結果を踏まえて、移行するデータを整理します。現行システムに存在するデータは必ずしも全てを移行する必要はなく、新システムの運用に必要なデータに絞ることがポイントです。たとえば、「5年以上前の不要なデータは削除する」など、社内で一定のルールを設けてデータの整理をしていきましょう。

必要なデータに絞ることで、移行の手間やコストを抑えることにつながります。

ただし、現行システムのデータやシステム設定ファイルのバックアップやログは、基本的には全て外部ディスクに一定期間残すようにしましょう。

（3）移行計画書を作成する

続いて、移行計画書を作成します。移行計画書では、主に以下に挙げる項目について整理し、関係者間で合意形成を図りましょう。

（4）移行リハーサルを行う

移行計画書の作成後は、実際の移行作業を行う前に、移行リハーサルを実施します。移行リハーサルでは、本番の移行作業時の影響を抑えるために、本番に近い環境ほどリスクが低減できます。可能な限り本番相当の環境で事前に移行作業の確認・検証を行いましょう。

移行リハーサルを行う際は、なるべく本番と同じ時間帯や体制、作業手順で臨み、トラブルが発生した場合はしっかりと事象や原因を書き留めておくことが重要です。移行リハーサルで何らかのトラブルが発生する事態をあらかじめ想定し、移行リハーサルを複数回行えるよう予備のスケジュールを組んでおくこともポイントとなります。

また、問題が発生した際の、切り戻し作業についてもリハーサルで確認しておきましょう。

（5）移行作業を実施する

移行リハーサルの確認・検証ができたら、本番の移行作業を実施していきます。
まず、作業完了報告や不明点の確認、問題発生時の連絡体制について実施前に確認し、移行作業に入ります。
しっかりと移行リハーサルができていれば、本番の移行作業も基本的には手順通りに進めていけば問題ありません。

ただし、本番稼働しているサーバーとの接続などは移行リハーサルでは確認できないこともあるので、移行リハーサルとの差分となる箇所は特に注意が必要です。
移行作業でのミスを防ぐため、作業は複数名で行い、作業ログを記録しましょう。
また、移行作業の途中でも、失敗のリスクを低減するため、可能な限り確認を行ってください。

（6）新システムのテストをする

移行作業を終えたら、新システムのテストを行います。たとえば、新システムを使用して1日の業務運用サイクルの確認を行い、問題なく業務運用ができるかなどを確認します。

正常時の機能だけではなく、負荷がかかった場合の動き、リソース状況、問題発生時の切り替えなどに関しても確認が必要です。
また、新システムへ移行したデータの種類や形式に不備がないかを確認することもポイントです。
特にデータが完全な形で移行できていない場合、そのまま稼働させると大きな問題が発生するため、完全に移行できているかどうか、独自にスクリプトを作成するなどして確認できるよう準備しておくことが重要です。

（7）現場担当者を教育する

最後に、現場担当者の教育です。教育に関しては、リソースに余裕があるなら、移行計画の立案と並行して行っても問題ありません。
教育では主に新システムの利用方法や現行システムと異なる箇所、トラブル時の問い合わせ先などを伝えます。

新システムのOSやハードウェアに対して、全体的に知識が不足している場合は、あらかじめシステム移行前に仕様書などを読む、検証環境でのシミュレーションを行うなど中長期の教育を計画しておきましょう。

現場担当者への教育を効率的に進めるためには、新システムの利用マニュアルを整備することがポイントです。現場担当者の目線でわかりやすいマニュアルを作成し、新システムの活用を促進していきましょう。

（1）データの移行漏れや不一致が生じる恐れがある

システム移行において注意すべき点のひとつは、データの移行漏れや不一致が生じる恐れがあることです。
移行計画を基に問題なく作業を進めているつもりでも、移行を実施したタイミングで移行すべきデータの漏れや不一致が発覚するケースもあります。

移行データの漏れや不一致が生じる主な原因としては、移行計画を策定する際に業務現場の有識者の意見を十分に吸い上げられていないことなどが考えられます。

そのため、移行計画の段階から業務現場の有識者を交えて移行データの要件定義をしっかりと行い、移行データを網羅的に洗い出すことが重要です。

（2）新旧のシステムで扱えるデータが異なる場合がある

現行システムと新システムの間でデータの形式などが異なる可能性がある点も注意すべきポイントです。新システムでは現行システムとは別のデータベースシステムなどを導入している場合もあり、これまでとは扱うデータ構造や形式が異なるケースも珍しくありません。

新旧のシステムで扱えるデータが異なる場合、データのマッピング処理などを行う必要があり、多くの作業工数がかかってしまうこともあるでしょう。移行計画の段階で新旧のシステムのデータ構造の違いなども確認し、必要な場合はデータのマッピング処理などにかかる作業工数を事前に見積もっておくことが大切です。

（3）トラブル発生時に業務がストップする恐れがある

移行時にトラブルが発生し、業務がストップする恐れがある点もリスク・注意点として挙げられます。
移行中に不測のトラブルが発生し、スケジュール通りに移行を完了させることができないと、新システムでの業務運用に支障が生じることになります。特に、一斉移行方式の場合は、社内の基幹業務をはじめ会社全体への業務影響が出てしまうリスクがあります。

あらかじめトラブル発生によって考えられる業務影響を洗い出し、システムが一時的にストップした場合の臨時的な業務運用方法などを策定しておくことが求められます。

（4）処理能力の違いによるトラブル発生の恐れがある

多くの場合、新システムへ移行することで、全体の処理能力は向上するでしょう。
しかし、それによって未経験のトラブルが発生することがあります。

たとえば、ネットワーク関係の性能が向上することによって短時間で受信するデータ量が多くなれば、その影響でメモリ不足が発生する場合があります。

そのようなトラブルを防ぐために、あらかじめ検証の段階において実環境を想定した負荷テストを行います。
また、移行直後は各リソースの状況を監視し、使用率が上昇し続ける場合は直ちに原因をつきとめ対応する必要があります。場合によっては、障害発生を防ぐためにリクエスト数などを制限する必要が発生する可能性もあるため、あらかじめシナリオに組み込んでおきましょう。

（1）バックアップを必ず取っておく

システム移行の失敗を防ぐためには、バックアップを取っておくことが不可欠です。バックアップを取っていない場合、万が一移行作業中にデータを消失してしまうと復旧させることができず、業務に甚大な影響を与えてしまう可能性もあります。

あらかじめバックアップ用のシステム環境を準備し、移行作業を開始する前に販売データや会計データ、生産データなど各種データのバックアップを取っておくことがポイントです。
また、業務データ以外のデータも必要に応じてバックアップを行います。
データベースのデータのみならず、各ノードのファイルシステムをそのままイメージバックアップしておくことが理想です。

稼働中にバックアップを取る場合は、ディスクへのアクセスが頻繁に発生し、パフォーマンスが落ちる可能性があるので十分に注意しましょう。

バックアップ先に関しては、予想外の問題にも対応できるように十分な容量を用意しておきましょう。
また、テープドライブなどの場合、想定外にバックアップの時間がかかる可能性もあるので、あらかじめ検証した上で十分な時間を確保することも重要です。

（2）余裕を持たせた移行計画を立てる

どんなに念入りに計画を立て、検証を行ったとしても、システム移行には不測の事態が付きものです。

よって、予定以上の期間を要するという前提で余裕を持たせた移行計画を立てることもポイントとなります。
もし、移行リハーサルで何らかの不備が発覚した場合、2回目以降の移行リハーサルを実施するための日程確保などが必要です。

移行計画を策定する段階から、各作業工程での手戻りなどを想定した余裕のあるスケジュールを組むようにしましょう。

不測の事態が発生した場合は、冷静に対処しましょう。誰かを責めるのではなく、冷静に原因を分析することを優先することが、最終的に安全に移行を成功させるための重要なポイントです。

（3）現行システムの仕様を入念にチェックする

現行システムの仕様を入念にチェックすることも大事なポイントです。現行システムの仕様を十分に確認しない状態で移行計画を策定すると、後からデータの考慮漏れなどの問題が発覚することになり、移行スケジュールの遅延や移行後の業務トラブルなどにつながります。
現行システムの設計書や仕様書は、必ずしも最新の状況が反映されているとは限りません。
それらのドキュメントがどのようにメンテナンスされていたのか確認してください。

現行システムの調査や移行データの整理を行う際は、現行システムの仕様や業務運用に詳しい担当者にも必ず参加してもらいましょう。

（4）コンティンジェンシープランを立てておく

システム移行で失敗しないためには、コンティンジェンシープランを立てておくこともポイントです。コンティンジェンシープランとは、想定外の事態が発生した場合に、事業や業務への影響を最小化するために定めた対応策や行動手順などを指します。

システム移行において特に避けるべきことは、移行トラブルによって事業や業務に甚大な影響を及ぼしてしまうことです。コンティンジェンシープランを立てておくことで、万が一システム移行において問題が発生した場合でも適切な対応・行動を迅速に取ることができ、事業や業務への影響を低減することができるでしょう。