導入事例：「リフト＆シフト」活用法をユーザーに聞く

リフト＆シフトに関する事例の記事を紹介します。製品／サービス選定の参考にご覧ください。

「リフト＆シフト」と「リファクタリング」はどちらを選ぶべきか

　リフト＆シフトはクラウドサービスにオンプレミスアプリケーションを移行させる際に、コストと時間のかからない方法として選ばれる傾向にある。ただしレガシーアプリケーションをリフト＆シフトすると、インフラの自動スケーリングといったクラウドサービスのメリットを十分に活用できなくなる可能性がある。

リフトアンドシフトのデメリット

　アプリケーションのソースコードを移行先のインフラに合わせて全面的に書き換える「リファクタリング」と比べると、リフト＆シフトにはデメリットがある。レガシーアプリケーションやオンプレミスインフラで稼働するアプリケーションをリフト＆シフトでクラウドサービスに移行させると、移行先で適切に機能しない恐れがある。

　要件や運用方法を十分に明文化しないまま開始するリフト＆シフトは、失敗する可能性が高い。リフト＆シフトに失敗したアプリケーションは、不要なデータ通信を発生させ、データ通信の遅延やインフラコストの増大を招くことがある。こうした問題を回避するために、いったんリフト＆シフトしたアプリケーションを、クラウドネイティブの（クラウドサービスに適した）アプリケーションとしてリファクタリングし直す必要が生じる場合がある。

　データベースへのアクセスが頻繁に発生するアプリケーションは、リフト＆シフトで移行するとクラウドサービスの利用料金が想定外に高騰する可能性がある。リフト＆シフトしたアプリケーションが、そのままではクラウドサービスのID・アクセス管理システムを利用できないなど、セキュリティの脆弱（ぜいじゃく）性が生じる場合は、リフト＆シフトよりもリファクタリングの方が適している。

記事一覧

• 

  巨大DBをOCIでクラウド化　パナソニックIT会社が年間7000万円を削った移行術

  2026年05月20日 05時03分

「リフト＆シフト」とはどのようなクラウド移行手法なのか

　「リフト＆シフト」は、アプリケーションを元のインフラから別のインフラに移行させる際に、アプリケーションを再設計せずにそのまま複製する手法を指す。リフト＆シフトをするか、インフラの移行を機にアプリケーションを一から再構築するかの選択は、アプリケーションの用途や構造の複雑さに大きく左右される。（続きはページの末尾にあります）