クラウドリフトとクラウドシフトの違いとは？メリット・デメリットや選び方、移行手順を解説

オンプレミス環境からクラウドへ移行する方法には、「クラウドリフト」と「クラウドシフト」があります。

クラウドリフトとクラウドシフトには違いがありますが、必ずしも二者択一ではありません。段階的にクラウド移行を進める「リフトアンドシフト」という方法もあります。

本記事では、クラウドリフトとクラウドシフトの違いやメリット・デメリット、自社に適した方法の選び方、移行の進め方について解説します。

→クラウド型人事労務システム「One人事」資料を無料ダウンロード

お役立ち資料

One人事「サービス紹介」資料｜人事領域で30年の実績

無料ダウンロード

目次

クラウドリフトとクラウドシフトの違い

クラウドリフトとクラウドシフトは、いずれも既存システムをクラウド環境へ移行するための方法です。

主な違いは、移行にあわせて既存システムをどこまで変更するかにあります。

クラウドリフトとは

クラウドリフトとは、既存システムの構成やアプリケーションを大きく変更せず、稼働環境をオンプレミスからクラウドへ移す方法です。

たとえば、社内やデータセンターに設置していたサーバー上のOS、ミドルウェア、アプリケーションを、クラウド上の仮想サーバーへ移行します。

現在の仕組みを活用しやすいため、システムを再設計する場合と比べて、移行期間や初期費用を抑えやすいことが特徴です。

ただし、「そのまま移す」といっても、作業が不要になるわけではありません。移行先の設計やネットワーク設定、データ移行、動作確認、セキュリティ設定などは必要です。

クラウドシフトとは

クラウドシフトとは、クラウドの機能を活用できるように、システム構成やアプリケーション、運用方法を見直して移行する方法です。

たとえば、自社で管理していたデータベースをクラウド事業者のマネージドサービスへ切り替えたり、需要に応じてサーバーの処理能力を調整できる構成へ変更したりします。

クラウドシフトは、必ずしもシステム全体を一から作り直すことを意味しません。影響範囲や優先順位を踏まえ、一部の機能から段階的に改修する場合もあります。

クラウドリフトとクラウドシフトの比較

なお、クラウドリフトとクラウドシフトの定義や範囲は、企業やベンダーによって多少異なることがあります。提案を受ける際は、どの部分を移行し、どの部分を変更するのかを確認が必要です。

クラウドファーストとの違い

クラウドファーストとは、新しいシステムやサービスを検討する際に、「まずはクラウドの利用を優先して考える」という方針のことです。何かを新しく始めるときに、オンプレミス(自社サーバー)ではなく、クラウドを第一候補として検討する姿勢を指します。

クラウドリフトやクラウドシフトが「既存のシステムをどのように移行していくか」という進め方・段階をあらわす言葉であるのに対し、クラウドファーストは「そもそもクラウドを使うかどうかを検討する際の考え方」を指す言葉です。

クラウドネイティブとの違い

クラウドネイティブとは、最初からクラウド上での利用を前提にシステムをつくる考え方です。企画・設計の段階からクラウドをうまく使うことを想定してつくります。

オンプレミス環境と比べて、必要なときに規模を柔軟に拡大・縮小できたり、変更や改善を素早く反映できたりするのが特徴です。

既存システムについてはクラウドリフトやクラウドシフトといった移行プロセスを経て、新たに構築するシステムについてはクラウドファーストの方針のもとで検討を進め、最終的に企業全体としてクラウドを最大限に活かした「クラウドネイティブ」な状態を目指していくことになります。

すべてのシステムをクラウドネイティブにする必要はなく、システムの重要度やコストに応じて、どの段階まで進めるかを判断するのが一般的です。

お役立ち資料

One人事「サービス紹介」資料｜人事領域で30年の実績

無料ダウンロード

クラウドリフトのメリット・デメリット

クラウドリフトは、既存システムへの変更を抑えながら、オンプレミス環境が抱える課題へ対応したい場合に適しています。一方で、クラウドリフトは移行しやすい反面、既存システムの課題が移行後も残りやすい方法です。

メリット1．短期間で移行しやすい

クラウドリフトでは、アプリケーションの再設計や大規模な改修を行わないため、クラウドシフトと比べて短期間で移行しやすくなります。

ハードウェアの保守期限やデータセンターの契約終了が迫っている場合など、移行期限が決まっている企業にとって現実的な方法です。

メリット2．初期費用を抑えやすい

クラウドリフトは既存システムを活用するため、再開発や再設計にかかる費用を抑えられます。

ただし、クラウドへ移行すれば必ず総コストが下がるわけではありません。移行後の利用料や通信費まで含めて判断する必要があります。

メリット3．既存の運用知識を活用できる

クラウドリフトはシステム構成が大きく変わらないため、これまで運用してきた担当者の知識や経験を活かせます。

移行と同時に多くの新技術を習得する必要がないため、現場の負担を抑えながらクラウド化を進めやすくなります。

メリット4．ハードウェアの調達や保守を減らせる

クラウドリフトで移行すると、自社で物理サーバーを購入し、設置や交換を行う必要がなくなります。

老朽化した機器の更新や障害対応にかかる負担を減らせるメリットがあります。

メリット5．BCP対策を見直しやすい

クラウド事業者のデータセンターを利用することで、自社設備より整った防災体制の恩恵を受けやすくなるほか、将来的に複数拠点を使った構成へ拡張する土台にもなります。

ただし、クラウドへ移しただけで事業継続性が確保されるわけではありません。データの複製先や復旧手順などは、別途設計・改修が必要です。

デメリット1．既存システムの問題を引き継ぐ

クラウドリフトは、システム構成を大きく変えないため、複雑な設計や古いプログラム、属人化した運用なども引き継がれる可能性があります。

移行自体は完了しても、機能追加やセキュリティ対応に時間がかかる状態が変わらないのは課題の一つです。

デメリット2．クラウドの利用料が想定より高くなることがある

オンプレミス環境と同じサーバー構成やスペックをそのままクラウド上に再現すると、必要以上のリソースを確保してしまうことがあります。

利用していないサーバーやストレージが残れば、継続的に料金が発生します。オンプレミスとクラウド間のデータ転送量が多い場合は、通信費にも注意が必要です。

デメリット3．運用負担が変わらない場合がある

クラウドリフトでは、従来の運用作業が残ることがあります。

物理機器の管理は減っても、「クラウドへ移したのに運用負担があまり変わらない」という状態になりかねません。

デメリット4．クラウドの機能を活かしにくい

既存システムの仕組みをほとんど変えずに移行すると、利用状況に応じて処理能力を調整する機能や、バックアップ・障害対応をクラウド事業者に任せるサービスを使いにくくなります。

クラウドリフトは短期的な移行を優先するなら合理的な一方、運用負担やコストを減らすには、移行後に追加の改修が必要になる可能性があります。

クラウドシフトのメリット・デメリット

クラウドシフトは、稼働環境を変更するだけでなく、既存システムが抱える課題も見直したい場合に適しています。一方で、予算、人材、運用体制まで含めた準備が課題となります。

メリット1．インフラ運用の負担を減らせる

データの管理やシステムの監視、バックアップなどに、クラウド事業者が管理するサービスを利用すれば、更新作業を減らせます。

担当者は、システムの維持だけでなく、機能の改善やセキュリティ対策に時間を使いやすくなります。ただし、サービスの設定や権限、利用料金の管理は引き続き必要です。

メリット2．システムの拡張性を高めやすい

クラウドシフトで利用状況に応じてリソースを増減できる構成にすれば、アクセス数やデータ量の変化へ対応しやすくなります。

事業の拡大や新機能の追加に合わせて、必要な部分を変更しやすいシステムを目指せます。

メリット3．運用の自動化を進めやすい

サーバーの設定、監視結果の通知、バックアップなど、同じ手順で行う作業の一部を自動化できる可能性があります。

ただし、対象となる作業を決め、必要な仕組みやルールを整える必要があります。

メリット4．現行システムの課題を見直せる

クラウドシフトでは、システムの仕組みを見直しながら移行する必要があるため、結果として複雑になったシステム間の連携や、使われていない機能などを整理できます。

何を残し、何を変更するかを移行前に決めることで、稼働場所をクラウドへ移すだけでなく、現在のシステムや運用が抱える課題も改善できるはずです。

デメリット1．移行期間と初期費用が増えやすい

クラウドシフトは、システムの再設計や改修、テストが必要になるため、クラウドリフトよりも期間と費用がかかります。

対象範囲が広いほど、要件の変更や設計上の判断による手戻りも発生しやすくなります。どこまで改修するのかを決めずに進めると、予算やスケジュールが膨らむ原因になります。

デメリット2．クラウドに関する知識が必要になる

クラウドシフト後は、オンプレミスとは異なるアクセス管理やセキュリティ・バックアップ体制が必要になります。

社内に対応できる人材がいない場合は、担当者を育成するか、外部の専門家に依頼しなければなりません。移行前に、誰がどこまで管理するのかを決めておく必要があります。

デメリット3．業務手順や運用体制の見直しが必要になる

クラウドシフトは、システムだけを変更すれば完了するものではありません。

設定変更の承認方法、障害対応の役割分担、リソース追加の手順、セキュリティ確認なども、クラウド環境にあわせた見直しが課題となります。

従来の運用方法をそのまま持ち込むと、自動化や柔軟なリソース変更が進まず、クラウドの利点を活かせない場合があります。

デメリット4．移行期間中の負担が増える

既存システムを稼働させながら新しい環境を構築する場合、一定期間は両方の環境を管理しなければなりません。

データの同期や動作確認、利用部門への説明、切り替え後の問い合わせ対応など、通常運用に加えて移行作業が発生します。

クラウドリフトとクラウドシフトはどちらが最適か

クラウドリフトとクラウドシフトのどちらが適しているかは、移行の目的や期限、システムの状態によって変わります。費用や移行期間だけで決めるのではなく、次の観点から判断するのがおすすめです。

1．クラウド移行の目的

クラウドへ移行する理由を整理します。

たとえば、ハードウェアの保守期限への対応が目的であれば、クラウドリフトが適している可能性があります。

一方、現行システムの運用負担や変更のしにくさを解消したい場合は、稼働環境だけを移しても課題が残ります。システムや運用を見直すクラウドシフトを検討する必要があります。

2．移行期限

データセンターの契約終了や機器の保守期限が迫っている場合、大規模な改修をともなうクラウドシフトでは間に合わないことがあります。

移行までの時間が限られている場合は、先にクラウドリフトを行い、移行後に改善する方法も選択肢です。

3．システムの利用予定期間

今後も長期間利用し、事業の変化に合わせて機能を追加する予定があるシステムは、改修に投資する価値があります。

反対に、数年以内に廃止する予定のシステムや、機能追加を予定していないシステムに対して、大規模なクラウドシフトを行う必要性は低いと考えられます。

4．社内の人員とスキル

クラウドシフトでは、新しい技術の習得や運用ルールの整備が必要です。

移行後にクラウド環境を管理できる担当者がいるか、人材育成の時間を確保できるか、外部事業者の支援を受けられるかを確認します。

5．予算とコストの考え方

クラウドリフトとクラウドシフトを比較する際は、移行時の初期費用だけでなく、移行後の利用料・管理費・追加改修費まで含めて判断することが重要です。

クラウドリフトは初期費用を抑えやすい反面、従来の運用コストが残りやすく、クラウドシフトは初期費用が増えやすい反面、運用の自動化によって中長期的な負担を抑えられる可能性があります。

すべてのシステムを同じ方法で移行しない

社内にあるすべてのシステムを、一律にクラウドリフトまたはクラウドシフトする必要はありません。

システムごとに、次のような判断が考えられます。

• 構成を変えずにクラウドリフトする
• 一部を改修してクラウドシフトする
• SaaSへ置き換える
• オンプレミスに残す
• 利用状況を確認して廃止する

システムの重要度や利用期間、他システムとの関係を踏まえて、個別に移行方針を決めます。

クラウド移行のリフトアンドシフトとは

リフトアンドシフトとは、まずクラウドリフトによって既存システムを移行し、その後、優先順位の高い部分からクラウドシフトを進める方法です。

移行期限が迫っている場合や、システム全体を一度に改修するリスクを避けたい場合に採用されます。

稼働環境を先にクラウドへ移すことで、ハードウェアやデータセンターに関する課題へ対応しつつ、実際の利用状況を確認しながら改善を進められます。

ただし、リフト完了後に予算や担当者が確保されず、その後のシフトが実施されないこともあります。この状態では、既存システムの課題や運用負担が残り、クラウド利用料だけが増えてしまいます。

リフトだけで終わらせないために

リフトアンドシフトを採用する場合は、移行後の改善を別のプロジェクトとして扱うのではなく、開始時点の計画に含めておく必要があります。

具体的には、次の項目を決めます。

• 移行後も改善を担当する責任者とチーム
• シフトする機能やシステムの範囲
• 改善する順番
• リフト費用とは別の最適化予算
• 各施策の実施期限
• 運用費用や作業時間などの評価指標
• シフトが完了したと判断する条件

とくに、移行プロジェクトの終了後も改善を担当するチームを残すことです。実行する担当者が決まっていなければ、予算や期限を設定しても先送りされやすくなります。

クラウドリフト・クラウドシフトの手順

クラウド移行では、現行システムの状態と移行目的を整理したうえで、クラウドリフトやクラウドシフトの方針を選びます。

1．現行システムを整理する

移行対象となるサーバー、アプリケーション、データ、ネットワーク、外部システムとの連携を洗い出します。

• システムの利用部門
• 利用者数
• 稼働時間
• 性能要件
• 他システムとの依存関係
• 使用しているソフトウェアとライセンス
• 保守期限
• バックアップ方法
• 障害時の復旧手順
• 現在発生している運用上の課題

利用されていないサーバーやアプリケーションをそのまま移行すると、不要なクラウド利用料が発生します。移行対象だけでなく、廃止できるものも整理します。

2．移行の目的と評価項目を決める

クラウド移行によって何を改善したいのかを決めます。

目的の例として、次のものがあります。

• ハードウェアの保守期限へ対応する
• 災害時の復旧性を高める
• 運用作業を減らす
• システムの変更を行いやすくする
• 利用状況に応じてリソースを調整する
• 新しい拠点や事業へ対応する

目的に応じて、運用費用、作業時間、障害件数、復旧時間などの評価項目も設定します。

3．システムごとに移行方法を決める

棚卸しの結果をもとに、各システムをクラウドリフトするのか、クラウドシフトするのかを判断します。

一度に結論を出すのではなく、移行期限や重要度に応じて、リフト後に段階的にシフトする方法も検討します。

リフトアンドシフトを選ぶ場合は、この段階でシフトの対象範囲・優先順位・追加予算・実施期限・完了条件もあわせて決めておきます。

4．移行後の構成と運用体制を設計する

移行先のクラウドサービスやネットワーク構成、バックアップ、監視、障害対応、権限管理などを決めます。

この段階で、クラウド環境を誰が管理するのか、ベンダーと自社の役割をどのように分けるのかも整理します。

オンプレミス時代と同じ運用をそのまま続けるのではなく、クラウド上で必要となる作業や承認手順に合わせて運用ルールを見直します。

5．費用を試算する

移行作業にかかる費用だけでなく、移行後に継続して発生する費用を試算します。

費用には、次のものがあります。

• サーバーやストレージの利用料
• データ転送費
• 監視サービスの利用料
• バックアップ費用
• セキュリティサービスの費用
• ソフトウェアライセンス
• 運用委託費
• 移行後の改修費
• 社内担当者の教育費

複数の利用量を想定し、費用がどのように変化するかを確認します。

6．小規模な環境で検証する

影響範囲が限定されたシステムや機能を使い、移行先で正しく動作するかを確認します。

検証結果を踏まえて、移行方法や構成、スケジュールを修正します。

7．優先順位を付けて移行する

すべてのシステムを一度に移行すると、問題が発生した場合の影響が大きくなります。

業務への影響が小さいシステムや、他システムへの依存が少ないものから移行し、そこで得た知見を次の移行へ活かします。

切り替え時には、問題が発生した場合に旧環境へ戻せる手順も用意します。

8．移行後も継続して見直す

クラウド移行後も、利用状況や費用、処理性能、障害、セキュリティ設定を定期的に確認します。

使われていないサーバーの停止や処理能力の見直し、データベース管理やバックアップをクラウド事業者に任せるサービスへの切り替えなどを行い、コストや運用負担の調整が必要です。

リフトアンドシフトを採用したなら、開始時に定めた計画に沿って、継続的な改修が続きます。

クラウド移行時のセキュリティ対策

クラウドへ移行すると、セキュリティ対策においても、守るべき対象や管理方法が変わります。

オンプレミス環境と同じように考えてしまうと、設定が不十分になる可能性があるため注意が必要です。

クラウド事業者との責任範囲を確認する

クラウドでは、クラウド事業者と利用企業が、それぞれ異なる範囲のセキュリティを担当します。

一般的に、クラウド事業者は物理設備やクラウドサービス自体を管理します。一方、利用企業は、アカウント、アクセス権限、データ、アプリケーション、各サービスの設定などを管理します。

利用するサービスによって責任範囲が異なるため、契約や仕様を確認する必要があります。

IDとアクセス権限を管理する

クラウド環境では、誰がどの情報や機能へアクセスできるかを管理します。

主な対策は次のとおりです。

• 必要な人に必要な権限だけを付与する
• 管理者権限の利用を制限する
• 多要素認証を設定する
• 退職者や異動者の権限をすみやかに変更する
• 共通アカウントの利用を避ける
• アクセスログを保存して確認する

権限は、組織変更や業務内容に合わせて見直しが必要です。

設定ミスを防ぐ

クラウドでは、ストレージやデータベースを誤って外部公開したり、アクセス範囲を広く設定したりすることで、情報漏えいにつながる可能性があります。

設定時の確認項目を整備し、複数人での確認や自動監視を取り入れます。

移行中のデータを保護する

データ移行時には、通信の暗号化やアクセス制限を行います。

移行用に作成した一時的なアカウントや保存領域が残らないようにし、作業終了後に削除します。

継続的に状態を確認する

クラウドサービスの機能や自社の利用状況は変化します。

アクセスログ、設定変更、脆弱性、利用アカウントなどを定期的に確認し、問題があれば修正する運用を定めます。

まとめ

クラウドリフトとクラウドシフトは、ともにクラウドの移行方法です。既存システムを大きく変えずに短時間で進めるのがリフト、クラウド機能の活用最大化を目指し運用方法を見直すのがシフトです。

クラウドリフトは既存の運用知識を活用できますが、現行システムの課題や運用負担が残る点が課題です。一方のクラウドシフトも、移行期間の体制検討や費用、人材、業務手順の見直しが必要になってきます。

移行期限が迫っている場合は、先にクラウドリフトを行い、その後にクラウドシフトを進める方法もあります。ただし、リフトだけで終わらないように、移行後まで考え計画を明確に立てることが重要です。

クラウドリフトとクラウドシフトのどちらを選ぶかは、自社が解消したい課題、システムの利用予定期間、移行期限、予算、運用体制から判断することとなります。