第3回：まずは Lift & Shift ― 現実的なクラウド移行の第一歩｜オンプレミスからクラウドへ ― 成功する移行戦略

はじめに

クラウド移行を検討する際、多くの情報システム担当者が直面するのが「理想は分かるが、現実的にどこから始めればよいのか分からない」という問題です。

アプリケーションの作り直しやクラウドネイティブ化が理想であることは理解していても、既存業務を止めることはできず、限られた人員と予算の中で移行を進めなければなりません。
こうした状況下で、多くの企業が最初の一手として選択しているのがLift & Shift（リフト＆シフト）です。

Lift & Shift とは、オンプレミスで稼働しているサーバーやシステム構成を、大きく変更せずにそのままクラウドへ移行する手法を指します。

OS、ミドルウェア、アプリケーション構成を極力維持したまま、インフラの置き場所だけをクラウドに移すため、主に IaaS（Infrastructure as a Service）が利用されます。

「クラウドなのに、結局オンプレミスと同じではないか」と感じる方もいるかもしれませんが、Lift & Shift はクラウド移行を成立させるための現実的な第一段階として重要な意味を持っています。

既存システムは長年の改修を経ており、仕様が完全に把握できていないケースも珍しくありません。いきなりアプリケーションを作り替えると、業務影響や想定外の不具合が発生するリスクが高まります。

Lift & Shift では、動作実績のある構成を維持するため、移行による業務停止や大規模トラブルのリスクを抑えやすくなります。

ハードウェア更新の期限が迫っている場合や、データセンター契約の終了が決まっている場合など、移行までの猶予が少ないケースもあります。

Lift & Shift は設計変更が最小限で済むため、比較的短期間でクラウド移行を実現できます。

クラウドネイティブな設計には、高度なスキルや経験が求められます。一方、既存の運用担当者はオンプレミス前提の知識を持っていることが多く、急激な技術転換は現場の負担になります。

Lift & Shift は、既存スキルを活かしながらクラウドに慣れるための「橋渡し」としても有効です。

Lift & Shift は一部で「失敗しやすい」「意味がない」と言われることがあります。
しかし、多くの場合、その原因は手法そのものではなく、位置づけの誤りにあります。

オンプレミスと同じ構成をそのまま移行すると、クラウドの従量課金モデルに合わず、コストが高止まりすることがあります。
これは Lift & Shift を「最終形」として放置してしまうことが原因です。

運用設計を見直さずに移行すると、監視やバックアップ、障害対応の負荷は変わりません。
クラウド移行＝自動的に運用が楽になる、わけではない点に注意が必要です。

成功するLift & Shiftには、共通した前提があります。

まずはクラウドに移し、実際の利用状況を把握した上で、必要な部分から段階的に改善していくことが重要です。

Lift & Shift によってクラウド移行が完了すると、次に検討すべきは「どこを変えるべきか」です。

すべてのシステムを作り替える必要はありません。
コストや運用負荷が高い部分、変更頻度が高い部分から、PaaSの活用や構成見直しを検討するのが現実的です。

次回は、Lift & Shift 後に見直すべき「クラウド時代の設計と運用」について解説します。
移行して終わりにしないためのポイントを、実務視点で整理します。

第2回：クラウド移行の種類 ― IaaS, PaaS, SaaSの違い｜オンプレミスからクラウドへ ― 成功する移行戦略