失敗しないシステム移行!これだけは知っておくべきポイントと手順

ひとことでシステム移行といっても様々なケースがあります。私たちの身近な例では、OSのバージョンアップに伴い、互換性のあるアプリケーションを導入するケースもありますし、最近では、長年使用している古いオンプレミス環境からクラウドサービスなどのような新たな環境に移行させる企業も増えてきています。また大規模な例では、銀行の合併によりATMや各種サービスを統合するため、新システムに移行した事例もあり、大規模なシステム障害が発生し、長時間ATMが使えなくなったりするなどのトラブルに見舞われたことはみなさんの記憶にも新しいでしょう。

ベースとなるシステムがあるのだから、新規に開発するより楽だろうと考えるのは早計で、移行に伴う大変さや苦労が数多くあるのです。システム移行がうまくいかないと、予定を超える時間と予算、人的リソースを要するだけでなく、新システムや新サービスが稼働せず、企業にとって大きな経営上の損失を招くことにもなりかねません。

ここでは、システム移行に失敗しないために知っておくべき基本的なポイントとして「システム移行の方式」や「具体的な手順」をご紹介するほか、「バックアップソフトを活用したシステム移行のメリットと事例」についてもご説明します。

1.システム移行とは

システム移行とは、既存システムやソフトウェア、データなどを別の環境に移転することや、新しい環境に移行することを意味します。

この章では、システム移行はどんな時に必要なのか、どういうパターンがあるのか、についてご説明します。

1-1. システム移行が必要な状況とは

システム移行が必要になるのは、主にハードウェアやOSがサポート切れになる時です。

・ハードウェアのサポート切れ
ハードウェアは物理的に経年劣化するため、サポート切れのタイミングでリプレースが必要です。サポート切れを機に最新のハードウェアに移行する場合、利用中のOSが稼働できなくなることがあります。古いOSにも対応できるサーバーマシンを新たに用意して現行のシステムをそのまま移行するか、OSをバージョンアップした上で新システムに移行する必要があります。

 ・OSのサポート切れ
OSのサポート切れについても同様です。たとえば、Windows Server 2008/2008 R2の延長サポートが2020年1月14日に終了しました。これにより、OSが原因となるシステム障害やトラブルが発生しても、ベンダーからのサポートが受けられなくなりました。またセキュリティ更新プログラムも配布されなくなり、セキュリティホールを狙ったサーバーへの不正侵入も防ぎきれなくなるため、新しいサーバーOSへの移行が必要とされています。

 このほか、企業合併で新システムに統合する際や、既存技術の老朽化によりパフォーマンス劣化やコスト増が問題となる場合、さらには新技術の採用やデジタルトランスフォーメーション(DX)への取り組みなども、システム移行のきっかけとなる場合があります。

1-2. システム移行のパターン

システム移行には主に以下のようなパターンが想定できます。

  1. オンプレミスからオンプレミスへの移行
    ・物理サーバーから物理サーバーへ
    ・物理サーバーから仮想マシンへ
  2. オンプレミスからクラウドへの移行
    ・物理サーバーからクラウドへ
    ・仮想マシンからクラウドへ

 さらに、「そのまま同じ構成で新環境に移行する」「既存システムの一部のみを新環境に移行する」「システムを新規開発し、既存システムから必要なデータを移行する」など、企業によって多種多様な移行パターンがあります。
*「オンプレミス」とは、サーバーなどのITリソースを自社内やデータセンター内に設置し、ユーザー自身が管理運用する方式のことです。

2.システム移行の方式3種類:
それぞれの適しているケースと、メリット・デメリットを紹介

システム移行の方式は、大きく分けて以下の3種類で、それぞれに向き不向きやメリット・デメリットがあります。それぞれの特徴を理解し、システム規模や複雑さ、重要度等を考慮して移行方式を決定しましょう。

  1. 一括移行
  2. 段階的移行
  3. 並行運用

    <システム移行方式のイメージ>

    <移行方式の比較>

2-1. 一括移行

ある時点で現行システムを休止し,新システムへ一斉に切り替える方式です。週末や連休などを利用して新旧システムの機材やソフトウェアの入れ替え、データの移行などを全面的に進め、旧システムから完全に置き換わった新システムで業務を開始します。

● こんな場合におススメ:長時間のシステム停止が可能で、コストを抑えたい場合に適した方法です。

● メリット:一度に全て移行するため、コストが抑えられるだけでなく、時間と手間も少なくて済みます。また、現行システムはそのまま残るので、失敗した場合にすぐに元のシステムで業務を再開できます。

● デメリット:一度に全てを移行するため、移行作業のためにシステムの停止時間が十分に必要です。システムの規模やデータの容量によっては移行に長時間を要します。また、移行後にトラブルが発生するリスクが高く、旧システムへ戻さざるを得ない場合のコストも大きくなります。

2-2. 段階的移行

現行システムから部分的に新システムに移行していく方法です。業務や機能、拠点などで分割し、その単位ごとに現行システムを休止し、順次新システムに切り替えます。機能単位で移行する場合、現行システムで稼働する機能と、新システムで稼働する機能が混在するため,移行過程では両システムの連携が必須となります。

● こんな場合におススメ:長期間システムを停止させることができない場合や、移行するデータの量や種類が多く一括での移行が難しい場合、大規模システムの移行で一括移行方式のリスクを避けたい場合などに適しています。システム移行のリスクとコストのバランスを取りたい企業に選ばれる方式と言えます。

● メリット:一括移行よりも切り替えの単位が小さいため、数時間から1日程度の短いシステム停止を繰り返せば移行でき、コストとエラーが発生するリスクを抑えることができます。

 ● デメリット:現在使用しているシステムから新しいシステムへ、複数回に分けて部分的に切り替えるため、一括移行に比べると移行のコストが比較的高くなるほか、手間と時間もかかります。機能単位で移行する場合、専用のインタフェースを開発して相互にデータを参照・更新したりEAI(Enterprise Application Integration)ソフトを使いデータを同期させたりすることになるため、データ移行ツールの設計と実装に手間がかかります。また失敗した場合の回復が難しいというリスクがあります。

2-3. 並行運用

新システムをスタートさせたあとも、しばらく現行システムと新システムを同時並行で稼働させながら,新システムに問題がないとわかった時点で現行システムを停止する方式です。業務担当者がデータの二重入力を行う場合もありますが、通常は両システム間でデータを同期させるEAIソフトなどが必要になります。

● こんな場合におススメ:システムを止められない場合は並行移行方式が適しています。移行作業を確実に行い、本番稼働を成功させるためには、現行システムと新システムを同時に運用する並行稼働期間として数ヶ月の期間を取るのが理想的と言われており、リソースに余裕があってリスクを最小限に抑えたい場合におススメの方法です。

メリット:並行運用により、新システムで問題が発生しても旧システムは稼働し続けるため、業務への影響を最小限に抑えることができます。一括移行や段階的移行と比較して、最もリスクの少ない移行方法と言えるでしょう。

 ● デメリット:両システムを運用するため、データの二重入力や、両システム間でデータを同期させるソフトウェアの利用が必要になります。ソフトウェアや二重運用のコストが高く、入力やチェック作業の手間も増えることから、特に業務担当者や運用担当者に負荷がかかります。また、失敗した場合の回復が難しいというリスクもあります。

3.システム移行の具体的な手順

システム移行には主に以下の5つの手順があります。

  1. 移行元システムとデータの調査
  2. 「移行計画書」の作成
  3. 移行手順の確認(移行リハーサル)
  4. 移行作業の実施
  5. 運用担当者への移管・業務担当者への教育

この章では、システム移行をスムーズに行うための具体的な手順をご紹介します。

3-1. 移行元システムとデータの調査

システムを移行する際には、まず現在使っている移行元システムの仕様をしっかりと調べておくことが重要です。

● 現行システムから新システムにどのぐらいの量のデータを移すのか
● データを移すのにどのぐらいの工数や時間がかかるか

これらによって、全体のスケジュールが大きく左右されるからです。

また、使用しているOS、データやファイルの形式、運用やメンテナンス、トラブル対応状況などをあらかじめ把握しておくことされで、新システムへの移行をよりスムーズに進められます。たとえば新システムで最新OSを採用する場合、既存のアプリケーションやデータベースがそのOSに対応しているかを事前に調査しておく必要があります。最新OSが使用するアプリケーションなどに対応していても、バージョンアップして動作しなくなるケースもあるため、事前にバックアップを取っておくと安心です。

次のステップでは、移行するデータやファイルのフィルタリング(選別)を行います。アクセス頻度やデータサイズという観点で、「5年間、一度もアクセスされていないデータ」「動画のようにサイズの大きいデータ」の場合は、必要なければ消す、必要ならテープなどに保存することで、移行元データの整理にもつながります。システムは利用年数が経つほど、不要なデータやファイルが増えていくので、移行前にきれいにしておくとよいしょう。

3-2. 「移行計画書の作成」

次の重要なステップ移行計画書」の作成です。移行計画とは、詳細設計の前に「いつ」「誰が」「何を」をするのかを決めることです。システム移行を成功させるためには、「移行計画書」の作成が重要なポイントとなってきます。以下に移行計画書に書くべき7つのポイントをご紹介します。

<移行計画書の目次イメージ>

移行計画書に書くべき7つのポイント

  1. 移行概要
    移行の前提となる制約条件を要件として洗い出し、移行の全体的な方針や方式,業務への影響などを記述します。
  2. 移行対象
    現行システムから新システムに移行する対象物を明記します。データやネットワーク、運用や業務など対象物ごとの移行方法を具体的に記述し、「機能一覧」や「サービス全体図」などを作成することで見える化を進めるとよいでしょう。
  3. 移行方式
    「一括移行方式」「段階的移行方式」「並行移行方式」のうちどの方式を選択するのかを記述します。
  4. 移行中の影響
    移行期間中、システムや業務にどのような影響があるのか、対処のしかたを含め、具体的に記述します。
  5. 移行テスト
    移行テストには、データ移行や移行検証などに使用する移行ツールのテスト、移行作業のリハーサルが含まれています。移行テストの方法、実施範囲、実施環境などをできるだけ明確に記述します。
  6. 移行スケジュール
    移行完了までの全工程と、タスクを細分化した工程を洗い出し、スケジュールを見積もります。作業の前倒しや遅延があった場合に備え、タスクの開始条件やタスク間の依存関係も明記しておく必要があります。
  7. 移行体制
    移行先新システムの設計や開発を含む全体の体制のほか、移行専任のチームを編成し役割分担を記述しておきます。利用側、開発側それぞれの体制と移行後のシステムに関する教育体制も必要です。

 移行計画書には、システムだけでなく業務面についてもできるだけわかりやすく記述しましょう。
システム移行に伴い、業務担当者の仕事の流れが変わることがあります。また、移行の直前に一部のデータ入力を停止するなど業務に制約が出てくる場合もあります。こうした業務に対する影響を洗い出し、業務担当者に移行の流れを理解してもらえるような記述にする必要があります。

3-3. 移行手順の確認(移行リハーサル)

システム移行計画書に従って、移行実施手順の確認を行います。ここで行う作業が「移行リハーサル」です。本番の移行時に向けて、リハーサルは複数回行うのがよいでしょう。たとえば1回目に全体を通して作業を行い、何らかの課題が発見されたとしましょう。この課題が解決されたかを確認するために2回目のリハーサルが必要になるのです。移行リハーサルは最低でも2回は実施しましょう。

3-4. 移行作業の実施

システム移行計画書を完成させ、複数回の移行リハーサルを通じてその移行が問題なく実施できると判断した後に、本番のシステム移行作業をシステム移行計画書に沿って実施します。

移行作業の中心となるのが,現行システムのデータを新システムに移す作業です。
データの移行は、その量や品質によっては、複雑になることがあります。ETLなどのデータ変換ツールなどを用いる場合があります。(ETLツールは、あるシステムからデータを抽出(extract)し、利用しやすい形に変換/加工(transform)し、別のシステムへ書き出す(load)作業を行います。)

システム全体を移行し、実際に運用を開始するまでには、データ移行以外にもいくつか考慮すべき点があります。たとえば、
・他のシステムやネットワークとの接続に関して,どのようなタイミングと方法で現行システムと新システムの切り替えを行うのか。・他社との接続がある場合,切り替えをどのように行うのか。
などです。

3-5. 運用担当者への移管・業務担当者への教育

システム移行の作業が終了し、トラブルなく動作することが確認できたら、システムの維持管理に必要となる運用作業を新システムでもスムーズに実施できるよう、運用担当者に引き継ぎます。また実際のユーザーとなる業務担当者に利用方法をトレーニングします。

システム移行には、『自社で行う』または『ベンダーやシステムインテグレータに依頼する』の2種類があります。社内に豊富な知識を持ったエンジニアがいる場合には自社で行うことも可能ですが、社員への負荷や個人の資質への依存が高くなるため、コストをかけてでも第三者に依頼し、安全なシステム移行を実行することを選択肢として検討しましょう。システム移行は負荷の高いプロジェクトです。専門家に頼ることも検討しましょう。どこに依頼するか、については、システム移行の規模や要件、希望する移行先などによってそれを得意とするベンダーやシステムインテグレータを選択するのがよいでしょう。

4.システム移行にレプリケーションソフトやバックアップソフトを利用するメリット

「移行ツール」を利用することでシステム移行をスムーズに行うことができます。
システム移行に使用されるツールには以下のような選択肢があります。

  • OS標準搭載の移行ツール
  • 仮想化ソフトに標準搭載の移行ツール(仮想環境間での移行の場合)
  • クラウドベンダーが提供する移行ツール(クラウド移行の場合)
  • 既存のデータ変換(ETL)ツールやデータ連携(EAI)ツール
  • 独自開発の移行ツール(既存ツールでは難しい場合)

 レプリケーションソフトやバックアップソフトもそのひとつです。

システム移行にレプリケーションソフトやバックアップソフトが有効なケース

■OSのサポート切れをきっかけにシステム移行を行う場合は、レプリケーションソフトが便利です。
新システムで利用するOSのバージョンアップが必要となり、これに対応するバージョンのアプリケーションをインストールし直した上で、レプリケーション機能を利用して、データのみを安全に移行することができます。レプリケーションとは、本番で運用中のサーバーデータを、もう 1 台のサーバーに自動的に複製する仕組みです。手間をかけることなく、最新の同じデータを2つのサーバーで同時に持つことができる、とても簡単なデータ保護の手段です。マスタ側とレプリカ側で OSのバージョンが異なる場合でも利用できます。「Arcserve Replication」がご利用いただけます。

<レプリケーションソフトを利用して遠隔地へのファイルサーバーのリプレースを実現した事例>

ソフトバンク・テクノロジー株式会社の場合
急成長を続けるソフトバンク・テクノロジーでは、いかに業務を止めることなくファイルサーバーをより大容量なものへと移行するかが懸案事項となっていました。ファイルサーバー移行に際し、いくつかの移行ツールを検討。当初はWindows Serverが持つ「DFSレプリケーション」での移行を検討していましたが、テストの結果、DFSによるレプリケーション速度は非常に遅いことが判明。また、変更の反映タイミングが不明であり、さらにはメモリを大量に消費することから使用を断念しました。次にWindows OSのコピー機能である「Robocopy」でテストしましたが、データを移行した時点(静止点)の特定が容易ではありませんでした。さらにバックアップツールの検討も行いましたが問題解決には至らなかったため、レプリケーションソフトの「Arcserve Replication」を検討。テストの結果、レプリケーションの進み具合がリアルタイムかつ視覚的に把握できるほか、静止点の確保が容易であり高速にデータが複製できること、コストパフォーマンスが高いことが評価され、採用に至りました。

<ご担当者のコメント>
「移行にかかった時間を調べたところ、わずか10分程度で完了していたことがわかって驚きました。サービスの停止時間をごく短くできたのは本当に嬉しい事です。テスト時を含めて、レプリケーションの進み具合がリアルタイムかつ視覚的に把握できるのがありがたかったです。」

※事例の詳細はこちらをご参照ください。

■新旧システムでOSが同じ(新システムでOSをバージョンアップしない)場合は、バックアップソフトのイメージバックアップ機能を利用するのがおススメです。
既存のシステム環境を、OSを含め丸ごとバックアップし、新環境にリストアすることができるため、移行に要する時間を大幅に短縮することができます。イメージバックアップソフト「Arcserve UDP」がご利用いただけます。

<バックアップアプライアンスを仲介機として活用したシステム移行の事例>

国際基督教大学の場合
国際基督教大学では、「Arcserve UDP Appliance」を活用して、仮想マシンを移行。仮想化ソフトVMware vSphereには、vMotionという移行ツールが標準搭載されていますが、旧仮想環境から新仮想化環境へ仮想マシンを移行する場合、このvMotionの機能を使うと、既存の構成を変えなければならなくなります。そこで国際基督教大学は、Arcserve UDP Applianceを移行の仲介機として活用することで、仮想マシンの構成を変えることなく新仮想化環境への移行を実現しました。Arcserve UDP Applianceは、イメージバックアップソフトArcserve UDPを搭載した、ハードウェア一体型のバックアップアプライアンスです。

<ご担当者のコメント>
「既存の仮想マシンはあらかじめArcserve UDP Applianceに丸ごとバックアップしておき、作業直前に増分バックアップを取得してから一気に新仮想化環境にリストアすることで、既存の仮想化環境にほとんど影響を与えることなくスムーズな移行ができました。作業時間も、ほとんどが1時間以内に終わり、大成功だったと言えます。」

Arcserve UDP Applianceへバックアップし、バックアップ完了後自動的に新しいVMware環境へリカバリすることで物理も仮想ゲストも新しい環境へ移行することができました。移行後もArcserve UDP Applianceへバックアップを実行されていますが、重複排除機能が有効なため容量を抑えて継続的にバックアップを実行いただいています。

※事例の詳細はこちらをご参照ください。
※バックアップアプライアンス「Arcserve UDP Appliance」の詳細はこちらをご覧ください。

Arcserve UDP および Arcserve UDP Applianceには、バックアップデータをリストアすることなく仮想環境で起動させる「インスタントVM」と呼ばれる機能があるため、OSのバージョンアップによって問題が発生しないか、といった移行前の事前検証に利用することができます。

Arcserve UDP の詳細については製品紹介を参照ください。

まとめ

「移行ツール」を利用することでシステム移行をスムーズに行うことができます。

システム移行の目的は、切り替えが終わった後、利用者が新システムで快適に業務を開始することができること、です。そのためには事前準備を万端にしなくてはなりません。

もっとも重要な点は、
● 自社にもっとも適した移行方式を選択すること
●  移行元システムとデータの調査をしっかり行うこと
●  移行計画書の作成を念入りに行うこと
●  十分なリハーサルを行うこと
●  システム移行に適したツールを選択すること
です。

レプリケーションソフトを利用すると、新旧システム間でOSのバージョンが異なる場合でもデータを安全に移行することができます。また、バックアップソフトのイメージバックアップ機を利用すると、新旧システムでOSが同じ場合に旧システム環境を丸ごとバックアップして新システムにリストアできるため、移行にかかる手間と時間を大幅に削減することができます。

システム移行を失敗なく進めるための一助としてご参照ください。

★こちらの記事もご参照ください。
他人事でない?!災害大国日本で重要な遠隔地バックアップとは?メリット・費用まとめ
水害対策が企業にとって必要になっている2つの要因と、今すぐできる対策

コメント

ダウンロードして、その実力を実際にお試しください。当社の高性能で革新的な製品およびソリューションで、IT管理におけるリスクと複雑さを低減しましょう。
無償トライアルを試す