🏗️ 如何将遗留应用程序迁移到AWS — “直接上传会失败”

5 月 12, 2026

—

cslab

in IT Security

将一个有10年历史的遗留系统迁移到云端，这不是搬家，而是一场外科手术。

🎯 本文涵盖内容

将遗留应用程序迁移到AWS的6种策略 (6 R’s)
最常见的选择 — Lift & Shift 与 Replatform 比较
数据库迁移专用工具 (AWS DMS, SCT) 实战概述
迁移顺序和常见的失败模式

📌 引言 / 背景

您在公司是否曾听过这样的话？

这个系统，没人知道是谁做的。也没有文档。但我们必须把它迁移到云端。

遗留（legacy）应用程序指的是老旧、不再进行开发或仅勉强维护的系统。这包括运行在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 (第一阶段) → Replatform (第二阶段) 的方法更为现实。

🚚 第一阶段: 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)，无需修改代码

缺点: 结构性问题 (操作系统依赖性、许可证问题) 会随之迁移

💡 对于Windows Server的BYOL(Bring Your Own License)问题，务必提前确认AWS的许可证政策。

⚙️ 第二阶段: Replatform — 仅更改数据库就成功了一半

遗留系统最大的痛点是数据库。Oracle、MS SQL、Sybase… 许可证费用非常高昂。

将其转换为Amazon RDS或Aurora，可以大大降低成本和运营负担。

🗄️ 两种专用数据库迁移工具

1) AWS DMS (Database Migration Service)

这是迁移实际数据的工具。

将数据从源数据库复制到目标数据库
支持异构数据库迁移 (例如: 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支持的源数据库:

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上的“包含许可证”费用和BYOL（自带许可证）费用不同。如果不知道这一点就进行迁移，成本可能会暴涨。

2. 忽视网络延迟 😵 在本地部署时代，数据库和应用程序位于同一个IDC内，但现在它们必须通过互联网（或VPN/Direct Connect）进行通信。特别是遗留应用程序经常发出数百次数据库查询，因此延迟差异可能是致命的。

3. 忽略SCT报告 ⛔ 如果忽略SCT标记为“需要手动转换”的项目，只运行DMS — 数据可能已迁移，但存储过程可能无法正常工作。

4. 切换前缺乏充分验证 即使在CDC同步期间，也必须有一个阶段将实际应用程序连接到目标数据库进行测试（并行运行）。在切换当天首次测试就太晚了。

5. IAM权限设置不足 DMS复制实例必须能够访问源数据库和目标数据库。请提前仔细检查VPC安全组、子网和IAM角色设置。

✅ 总结 / 结束语

将遗留系统迁移到AWS并非一蹴而就。分阶段的方法是关键。


阶段	策略	工具
第一阶段	Rehost (Lift & Shift)	AWS MGN
第二阶段	Replatform (数据库转换)	AWS SCT + DMS
第三阶段	Refactor (可选)	Lambda, ECS, Aurora Serverless 等

要继续前进:

✅ 实践AWS Application Migration Service (MGN) 官方文档
✅ 下载AWS SCT并尝试转换示例Oracle模式
✅ AWS DMS Workshop (AWS官方免费动手实践)

将遗留系统迁移到AWS可能令人望而生畏 — 但如果了解正确的工具和顺序，可以比想象中更有条理地完成。🚀