🏗️ レガシーアプリケーションをAWSに移行する方法 — 「ただ移行するだけでは失敗する」

5月 12, 2026

—

cslab

in IT Security

10年物のレガシーをクラウドに移行するのは引っ越しではなく、外科手術だ。

🎯 この記事で扱うこと

レガシーアプリをAWSに移行する6つの戦略 (6 R’s)
最も一般的な選択肢 — Lift & Shift vs Replatform の比較
DB移行専用ツール (AWS DMS, SCT) の実践概要
移行手順とよくある失敗パターン

📌 はじめに / 背景

会社でこんな言葉を聞いたことはありませんか？

このシステム、作った人もいない。ドキュメントもない。でもクラウドに移行しないといけない。

レガシーアプリケーションとは、古くなったり、もはや開発が行われていなかったり、かろうじてメンテナンスされているシステムを指します。Windows Server 2008上で動作する.NET Framework 3.5アプリ、Oracle 11gに依存するERP、さらにはIBMメインフレームまで含まれます。

これをAWSに移行する必要がある理由は単純です。

☁️ オンプレミスサーバーの保守費用・ライセンス更新のプレッシャー
📉 セキュリティパッチ終了 (EoL) の脅威
🚀 スケーリングが必要なビジネス要件

しかし問題は — レガシーは単にコピー＆ペーストのように移行できないということです。

🔍 AWS移行の6つの戦略 — “6 R’s”

AWSとGartnerが確立したクラウド移行戦略フレームワークです。


戦略	別名	説明
Rehost	Lift & Shift	そのままEC2に移行。変更は最小限
Replatform	Lift, Tinker & Shift	核は維持しつつ一部を最適化 (例: RDSへの変換)
Refactor	Re-architect	アーキテクチャ自体をクラウドネイティブに再設計
Repurchase	Drop & Shop	SaaSソリューションに置き換え (例: Salesforce)
Retire	—	もはや不要なシステムを廃止
Retain	—	当面は現状維持

レガシーであれば、ほとんどの場合、Rehost (1段階) → Replatform (2段階) の順でアプローチするのが現実的です。

🚚 1段階: Rehost — とにかくEC2に移行する

最も迅速でリスクの低い方法です。サーバーを丸ごとコピーしてEC2インスタンスに移行する方式です。

🛠️ 主要ツール: AWS Application Migration Service (MGN)

以前はCloudEndure Migrationという名称でしたが、現在はAWS MGNに統合されました。

動作方式:

ソースサーバーにMGNエージェントをインストール
サーバーディスクをAWSに継続的に複製 (リアルタイム同期)
準備ができたらカットオーバー(Cutover) — トラフィックを切り替え
EC2インスタンスでの起動を確認

# MGNエージェントのインストール例 (Linux)
sudo ./aws-replication-installer-init.py 
  --region ap-northeast-2 
  --aws-access-key-id <ACCESS_KEY> 
  --aws-secret-access-key <SECRET_KEY>

長所: 運用停止時間(Downtime)の最小化、コード修正不要

短所: 構造的な問題 (OS依存性、ライセンス問題) はそのまま引き継がれる

💡 Windows ServerのBYOL(Bring Your Own License)問題については、事前にAWSライセンスポリシーの確認が必須です。

⚙️ 2段階: Replatform — DBを変更するだけで半分は成功

レガシーの最大の苦痛はDBです。Oracle、MS SQL、Sybase… ライセンス費用が莫大です。

これをAmazon RDSまたはAuroraに変換するだけで、コストと運用負担を大幅に削減できます。

🗄️ DB移行専用ツール2種類

1) AWS DMS (Database Migration Service)

実際のデータを移行するツールです。

ソースDB → ターゲットDBへデータを複製
異種DB間の移行をサポート (Oracle → Aurora PostgreSQLなど)
CDC (Change Data Capture) をサポート — 運用中でもリアルタイム同期が可能

소스: Oracle 11g (온프레미스)
    ↓  [DMS Replication Instance]
타겟: Amazon Aurora PostgreSQL (AWS)

実際にはこのように使用します:

# DMSレプリケーションインスタンスの作成 (AWS CLI)
aws dms create-replication-instance 
  --replication-instance-identifier my-legacy-migration 
  --replication-instance-class dms.t3.medium 
  --allocated-storage 50 
  --region ap-northeast-2

DMSがサポートするソースDB:

Oracle, MS SQL Server, MySQL, PostgreSQL, MongoDB, SAP ASE, IBM Db2 など

2) AWS SCT (Schema Conversion Tool)

スキーマ(構造)を変換するツールです。DMSがデータを移行するのに対し、SCTはテーブル構造、インデックス、ストアドプロシージャ、トリガーなどを変換します。

Oracle PL/SQL → PostgreSQL PL/pgSQL 変換
変換不可能な項目はレポートで表示 (手動修正が必要な項目を特定)
GUIベースのツール (無料ダウンロード)

[SCT 워크플로우]
1. 소스 DB 연결 → 스키마 분석
2. 변환 리포트 생성 (호환성 평가)
3. 자동 변환 실행
4. 수동 수정 필요 항목 확인 및 처리
5. 타겟 DB에 변환된 스키마 적용

💡 DMS vs SCT まとめ

– SCT = 構造(スキーマ)変換

– DMS = データ複製および移行

– 通常、両方を併用します

💻 実践的な移行フローの例

Oracle 11g → Aurora PostgreSQL 変換シナリオ:

[1단계] AWS SCT 설치 및 스키마 분석
  → 변환 가능 항목 자동 변환
  → 수동 수정 목록 확인

[2단계] Aurora PostgreSQL 인스턴스 생성
  → RDS 콘솔 또는 Terraform으로 프로비저닝

[3단계] DMS 복제 인스턴스 생성
  → 소스/타겟 엔드포인트 설정

[4단계] 전체 로드(Full Load) 실행
  → 기존 데이터 전체 복제

[5단계] CDC 활성화
  → 실시간 변경사항 동기화 (운영 중 마이그레이션)

[6단계] 애플리케이션 DB 접속 정보 변경
  → 컷오버 및 모니터링

# 簡単なDMSエンドポイント作成例 (boto3)
import boto3

dms = boto3.client('dms', region_name='ap-northeast-2')

# ソースエンドポイント (Oracle)
response = dms.create_endpoint(
    EndpointIdentifier='source-oracle',
    EndpointType='source',
    EngineName='oracle',
    Username='migration_user',
    Password='your_password',
    ServerName='192.168.1.100',
    Port=1521,
    DatabaseName='ORCL'
)
print(response['Endpoint']['EndpointArn'])

⚠️ 注意事項 / よくある失敗

1. ライセンスの罠 🪤 Windows Server、Oracle DBなどは、AWSでのライセンス込み(License Included)料金とBYOL料金が異なります。これを知らずに移行すると費用が爆発します。

2. ネットワークレイテンシの見落とし 😵 オンプレミス時代には同じIDC内にあったDBとアプリが、今度はインターネット(またはVPN/Direct Connect)を経由する必要があります。特にレガシーアプリはDBクエリを何百回も発行する場合が多く、レイテンシの違いが致命的になることがあります。

3. SCTレポートの無視 ⛔ SCTが「手動変換が必要」と表示した項目を無視してDMSだけを実行すると — データは移行されたものの、プロシージャが動作しない状況が発生します。

4. カットオーバー前の十分な検証不足 CDCで同期中でも、実際のアプリをターゲットDBに接続してテスト(並行運用)する期間が必ず必要です。カットオーバー当日に初めてテストするのは遅すぎます。

5. IAM権限設定の不備 DMSレプリケーションインスタンスがソースDBとターゲットDBの両方にアクセスできる必要があります。VPCセキュリティグループ、サブネット、IAMロールの設定を事前に綿密に確認してください。

✅ まとめ / 終わりに

レガシーをAWSに移行するのは一朝一夕にはいきません。段階的なアプローチが鍵です。


段階	戦略	ツール
1段階	Rehost (Lift & Shift)	AWS MGN
2段階	Replatform (DB変換)	AWS SCT + DMS
3段階	Refactor (選択)	Lambda, ECS, Aurora Serverless など

次のステップに進むには:

✅ AWS Application Migration Service (MGN) 公式ドキュメントの実習
✅ AWS SCTをダウンロードしてサンプルOracleスキーマで変換を体験
✅ AWS DMS Workshop (AWS公式無料ハンズオン)

レガシーをAWSに移行するのは恐ろしいことですが — 適切なツールと手順を知って始めれば、思ったよりも体系的に行うことができます。🚀