オンプレからAWSへ、移行プロジェクトの全体フロー — SIerのための工程別ガイド

移行の相談で最も多いのは、技術的な難問ではなく「で、何から手をつければ？」という素朴な問いです。個別のサーバやバッチの判断は難しくない。難しいのは、それらを正しい順番に並べること。この記事は、オンプレからAWSへの移行プロジェクトを6つのフェーズに分解し、各工程でSIerが下すべき判断と、その判断を助ける実務記事を1枚の地図にまとめたものです。移行シリーズ全体の目次としても使ってください。

01まず全体像 — 移行は6フェーズで進む

小さなシステムでも大規模基幹でも、移行の工程は本質的に同じ6段です。順番を飛ばした移行——たとえば棚卸しの前に設計を始める、検証せずに本番設計を固める——が、後半のトラブルの大半を生みます。

重要なのは、これは「サーバ1台の移行」ではなく「プロジェクトの進め方」だということ。数百のサーバ・バッチ・連携が対象でも、フェーズごとに判断を積み上げれば、地図なしの混乱にはなりません。

02Phase 1：アセスメント — ここの精度がすべてを決める

最初のフェーズは、現状を「数字と一覧」にする作業です。ここで手を抜くと、後工程すべてが推測の上に建ちます。逆に、良い棚卸し表が1枚あれば、方式決定も設計も驚くほどスムーズに進みます。

• サーバの棚卸しと実測 — カタログスペックではなく実測ピークで見る（物理サーバをEC2に翻訳する）
• ストレージの実測 — 回転数・RAID構成をIOPSに翻訳し、実I/Oを2週間測る（SAS 7,200rpmはgp3何個分か）
• バッチ・ジョブの全容把握 — 起動条件・先行後続・実行時間の一覧化（バッチ移行4パターン）
• 「一覧に載らない資産」の出土 — 部門のExcel・Accessバッチ（野良ETLの移行戦略）

03Phase 2：移行方式の決定 — 対象ごとに「運ぶ/作り替える」

棚卸しができたら、対象ごとに移行方式を決めます。全部を同じ方式に揃えようとしないこと。サーバ・DB・バッチ・連携で、それぞれ最適な答えが違います。

• 移行の大方針 — 停止許容時間・切り戻し条件を先に決める（方式より先に決める5つのこと）
• サーバ — OSごと運ぶリホスト（MGNによるリホスト移行）、メインフレームはホスト移行の2つの道から
• ジョブ管理 — JP1続投かネイティブ書き換えか（ジョブ管理の3択）
• ファイル連携 — HULFT続投かS3化か（ファイル連携移行3パターン）
• DB・ETL — 同一エンジン移行かエンジン変更か（ストアド中心バッチ／ETLツールからGlueへ）。Oracleは分岐と権限の罠／古い版の手番と文字コードを必読

04Phase 3：検証環境・PoC — 触ってから決める

方式の当たりがついたら、いきなり本番設計に入らず、小さくて正しい検証環境で確かめます。オンプレの経験則はAWSでは半分しか通用しないので、転送速度・体感・運用手順は実地で握るのが確実です。

• 検証環境の作り方 — アカウント分離・初期設定・命名規則を最初から正しく（小さく正しいAWS環境）
• 土台のセキュリティ — 検証環境でも省かない10項目（アカウント初期設定10選）
• 検証で確かめるのは3つ：実データの転送速度、代表アプリの体感、運用の通し稽古

05Phase 4：設計 — 実測値をリソースに翻訳する

検証で得た肌感覚の上に、本番設計を組みます。ここはアセスメントの実測値を、具体的なAWSリソースに翻訳する工程です。カタログ値での見切り発車が最も危険な段階でもあります。

• ストレージ設計 — RAIDは組まない（EBSの冗長性）／gp3・io2の選定（EBSボリューム選定）
• インスタンス設計 — 世代・ファミリー・Graviton（EC2インスタンスタイプ）
• ファイルサーバ — FSx/EFS/S3の振り分け（ファイルサーバ移行4択）
• ネットワーク — 回線（VPNかDirect Connectか）／通信コスト（NAT・エンドポイント設計）
• バックアップ — テープからの翻訳（AWS Backup・Glacier）
• バッチの実装 — シェル続投の作法（EC2で正しく動かす）／ジョブネット化（Step Functions）

06Phase 5：移行実施 — 停止時間との勝負

設計ができたら、リハーサルを重ねてカットオーバーです。ここは技術より段取りと判断の勝負。テスト起動を何度もやり、切り戻し条件を握り、当日を迎えます。

• Windows特有の落とし穴 — ドメイン・ライセンス・時刻・共有経路（Windows移行7つの落とし穴）
• バッチの性能検証 — 本番同等データで1周まわして時間を確定（夜間バッチは速くなるか）
• リハーサルとテスト起動は「1回だけ」にしない。手を抜いた分は当日の夜に返ってきます

07Phase 6：移行後の最適化・運用 — ここからが本番

カットオーバーは終わりではなく始まりです。リホストで運んだ環境はオンプレの設計をまとった仮住まいで、放置すればオンプレより高いクラウドになります。半年以内に最適化を回し、運用を軌道に乗せる。

• 「遅くなった」の切り分け — 移行直後に必ず来る（性能問題の切り分け手順）
• バッチ運用の設計 — 監視・通知仕分け・リラン（監視とリラン設計）
• 監視の標準化 — 無事故運用の基本アラーム（監視10選）
• アカウントが増えるなら統制へ — 最適化の到達点（マルチアカウント統制）

—この地図の使い方

全フェーズを完璧にやる必要はありません。多くの現場では、まずPhase 1のアセスメント表を作り、Phase 3の小さな検証環境を立てるところから始めるのが正解です。そこで得た手応えが、残りのフェーズの精度を一気に上げます。

私たちEMWは、この6フェーズを通しで伴走することも、詰まっている1フェーズだけを支援することもできます。「どこにいて、次にどこへ進むべきか」が分からなくなったら、この地図を持ってご相談ください。