migration-readiness

迁移准备情况评估

步骤 1：收集背景信息

询问用户：

你计划迁移哪种工作负载？请提供以下信息：

• 工作负载名称以及要分析的代码包/目录
• 当前环境（本地部署、其他云、主机托管）
• 业务驱动因素（成本、敏捷性、合规性、硬件即将停产等）
• 时间限制（可选）

如果已提供背景信息，或你正在代码库中工作，请直接继续。

步骤 2：应用技术栈发现

分析代码库，了解当前应用技术栈。

你必须检查：

• 编程语言和运行时（版本、与 AWS 服务的兼容性）
• 框架和库（Web 框架、ORM、消息传递）
• 数据库技术（关系型、NoSQL、搜索、缓存）
• 中间件和消息代理
• 外部服务依赖项（API、SaaS 集成）
• 配置管理（配置文件、环境变量、密钥）
• 操作系统依赖项和系统级要求
• 构建和打包系统（Maven、npm、pip、Docker）

对于每个组件，记录：

• 文件路径和行号
• 技术及版本
• 对应的 AWS 服务或迁移路径
• 迁移复杂度（简单直接迁移、需要修改、需要重写）
• 对其他组件的依赖关系

你必须将以下情况标记为阻塞项：

• 没有云端替代方案的操作系统专属依赖项
• 有许可限制的专有软件（Oracle、特定 Windows 功能）
• 硬件专属依赖项（FPGA、特定 CPU 指令、USB 加密狗）
• 应用代码中硬编码的 IP 地址或主机名
• 本地文件系统依赖项（共享网络驱动器、本地存储）

步骤 3：基础设施发现

分析现有基础设施配置。

你必须检查：

• 服务器配置（CPU、内存、存储要求）
• 网络拓扑（VLAN、防火墙、负载均衡器、DNS）
• 存储系统（SAN、NAS、本地磁盘、文件共享）
• 数据库配置（引擎、版本、大小、复制）
• 监控和告警系统
• 备份和灾难恢复配置
• 安全控制（防火墙、IDS/IPS、WAF、证书）
• 现有的 IaC（如有，例如 Terraform、Ansible、Chef、Puppet）

对于每个基础设施组件，记录：

• 当前配置
• 对应的 AWS 服务
• 迁移方法（重新托管、重新平台化、重构）
• 数据量和传输注意事项

第 4 步：依赖关系映射

映射所有内部和外部依赖项。

你必须检查：

• 服务间通信（协议、端口、模式）
• 数据库连接（连接字符串、连接池、多个使用方）
• 共享数据库或数据存储（多个服务读写）
• 外部 API 集成（第三方服务、合作伙伴 API）
• 网络依赖项（对延迟敏感的连接、VPN 隧道）
• 批处理作业依赖项（调度、执行顺序）
• 身份验证／授权依赖项（LDAP、AD、SSO）

你必须创建依赖关系图，展示：

• 所有服务及其连接
• 数据流和协议
• 外部依赖项
• 迁移波次分组（哪些组件必须一起迁移）

你必须将以下情况标记为 HIGH RISK：

• 组件之间紧密耦合，必须一起迁移（会扩大影响范围）
• 多个服务访问共享数据库（迁移顺序受限）
• 迁移期间会横跨混合环境的延迟敏感型集成
• 对无法迁移的本地系统存在硬依赖（需要混合连接）

---STOP--- 检查点：发现和依赖关系映射已完成 — 可以确定迁移策略

已映射应用程序堆栈（{X} 个组件）、基础设施配置和依赖关系。已识别 {Y} 个阻碍因素、{Z} 个高风险依赖项（共享数据库、延迟敏感型集成）以及迁移波次分组。

是否继续确定每个组件的迁移策略（7 Rs），并按支柱评估就绪情况？

在用户明确确认之前，不要继续执行后续步骤。

第 5 步：确定迁移策略（7 Rs）

根据代码证据，评估每个组件适用的策略：

策略	适用情况	代码指标
Rehost	快速迁移，尽量少做改动	标准操作系统、可容器化、无特定操作系统依赖项
Replatform	迁移期间进行小幅优化	自行管理的数据库 → RDS、自行管理的缓存 → ElastiCache
Refactor	需要云原生优势	应拆分的单体应用、有状态 → 无状态
Repurchase	替换为 SaaS	有 AWS/SaaS 对应方案的商业软件
Retire	不再需要	未使用的代码、已弃用的服务
Retain	尚未准备好迁移	硬依赖、合规阻碍因素
Relocate	VMware 工作负载	VMware 特定配置

你必须用代码证据说明每项建议的理由。

第 6 步：按支柱评估就绪情况

对于每个支柱，请提供：就绪情况（已就绪／有条件就绪／尚未就绪）、证据（文件:行号）、差距、所需操作。

卓越运营就绪情况

• 是否使用 IaC？（CloudFormation、Terraform、CDK、Ansible）
• 是否已建立 CI/CD 流水线？能否将其用于 AWS？
• 监控是否可移植，还是绑定于特定工具？
• 是否已记录运维流程？

安全性就绪情况

• 是否有影响区域／服务选择的合规要求？
• 如何管理密钥？（硬编码、保管库、配置文件）
• 是否存在需要寻找对应方案的网络安全依赖项？
• 身份管理是否与 AWS IAM/Identity Center 兼容？

可靠性就绪情况

• 当前可用性如何？目标是什么？
• 是否有可复制的高可用机制？
• 迁移期间可接受的停机时间是多少？
• 是否已测试备份／恢复流程？

性能效率就绪情况

• 是否存在延迟敏感型集成？
• 是否存在特定硬件依赖项？
• 当前性能基线是什么？
• 切换期间需要维持哪些 SLA？

成本优化就绪情况

• 当前 TCO 是多少？（硬件、许可、运维、设施）
• 是否涉及许可影响？（BYOL、包含许可证、重新采购）
• 是否存在现有合同或预付承诺？

可持续性就绪度

• 迁移能否降低资源占用？
• 是否有采用 Graviton／无服务器的机会？
• 托管服务能否取代自我管理的基础设施？

第 7 步：风险评估

对每项风险，使用影响程度 × 可能性进行评估：

影响程度：轻微（进度延误、少量返工）| 中等（大量返工、混合运行期延长）| 严重（迁移失败、数据丢失、长时间中断）

可能性：低（妥善规划后不太可能发生）| 中（未采取特定缓解措施时可能发生）| 高（根据当前情况很可能发生）

影响程度	可能性	风险级别
严重	高	严重
严重	中	高
严重	低	高
中等	高	高
中等	中	中
中等	低	中
轻微	高	中
轻微	中	低
轻微	低	低

---STOP--- 检查点：风险评估已完成 — 可以生成最终迁移评估

已评估迁移中的 {N} 项风险。风险分布：{X} 项严重、{Y} 项高、{Z} 项中、{W} 项低。总体就绪度：{Ready / Conditionally Ready / Not Ready}。已识别关键阻碍因素及其缓解措施。

是否要我生成完整的迁移就绪度评估，包括迁移计划和成本比较？

在用户明确确认之前，不要继续进行。

---

第 8 步：生成评估

# Migration Readiness Assessment: {Workload Name}

## Executive Summary
- **Date**: {date}
- **Packages Analyzed**: {list}
- **Recommended Strategy**: {primary strategy}
- **Overall Readiness**: {Ready / Conditionally Ready / Not Ready}
- **Estimated Effort**: {T-shirt size with justification}
- **Key Risks**: {top 3}
- **Critical Blockers**: {count and brief description}

## Application Stack Summary
| Component | Technology | Version | AWS Equivalent | Strategy | Complexity |
|-----------|-----------|---------|---------------|----------|------------|
| {name} | {tech} | {ver} | {aws service} | {7R} | {Low/Med/High} |

## Dependency Map
{PlantUML diagram showing service dependencies, data flows, and migration wave groupings}

## Readiness Scorecard
| Pillar | Readiness | Score (1-5) | Key Blocker | Action Needed |
|--------|-----------|-------------|-------------|---------------|
| Operational Excellence | {status} | {score} | {blocker} | {action} |
| Security | {status} | {score} | {blocker} | {action} |
| Reliability | {status} | {score} | {blocker} | {action} |
| Performance Efficiency | {status} | {score} | {blocker} | {action} |
| Cost Optimization | {status} | {score} | {blocker} | {action} |
| Sustainability | {status} | {score} | {blocker} | {action} |

## Critical Blockers
{For each: ID, description, evidence (file:line), impact on migration, resolution approach, effort}

## Risks and Mitigations
| Risk | Evidence | Risk Level | Migration Impact | Mitigation | AWS Service |
|------|----------|------------|-----------------|------------|-------------|
| {risk} | {file:line} | {level} | {impact} | {mitigation} | {service} |

## Pre-Migration Checklist
{Ordered by priority — what must be done before migration starts}
- [ ] {action with evidence of why it's needed}

## Migration Plan

### Phase 1: Mobilize (Weeks 1-2)
| Task | Dependencies | AWS Service | Evidence |
|------|-------------|-------------|----------|
{Landing zone, connectivity, tooling setup}

### Phase 2: Migrate (Weeks 3-6)
| Wave | Components | Strategy | Data Volume | Downtime Window |
|------|-----------|----------|-------------|-----------------|
{Component migration waves based on dependency analysis}

### Phase 3: Optimize (Weeks 7-8)
| Optimization | Component | Expected Benefit | AWS Service |
|-------------|-----------|-----------------|-------------|
{Right-sizing, managed services, serverless, Graviton}

## AWS Services for Migration
| Category | Service | Purpose | Relevant Components |
|----------|---------|---------|-------------------|
| Server | AWS MGN | Rehost EC2 | {components} |
| Database | AWS DMS | Replicate with minimal downtime | {components} |
| Data | DataSync / Snowball | Large-scale transfer | {components} |
| Schema | AWS SCT | Schema conversion | {components} |
| Network | Direct Connect / VPN | Hybrid connectivity | {components} |
| Governance | Control Tower | Multi-account | All |

## Cost Comparison
| Category | Current (monthly est.) | AWS Estimated | Delta | Notes |
|----------|----------------------|---------------|-------|-------|
| Compute | {estimate} | {estimate} | {delta} | {basis} |
| Storage | {estimate} | {estimate} | {delta} | {basis} |
| Networking | {estimate} | {estimate} | {delta} | {basis} |
| Licensing | {estimate} | {estimate} | {delta} | {basis} |
| Operations | {estimate} | {estimate} | {delta} | {basis} |

## Next Steps
{Top 5 concrete actions the team should take this week to prepare}

第 9 步：提供后续服务

交付评估后，询问：

你希望我：

• 设计 AWS 着陆区架构？
• 为特定数据库制定详细的数据迁移计划？
• 详细估算特定组件的 AWS 成本？
• 制定迁移前测试策略？
• 设计混合连接架构？
• 为目标 AWS 架构创建 IaC？

校准指南

• 已采用容器化、CI/CD 和 IaC 的工作负载已基本就绪——重点关注 AWS 特定优化和数据迁移规划
• 每个阻碍因素和风险都必须有代码证据——未经核查实际依赖项，不要标记“许可风险”
• 迁移策略建议必须以代码分析为依据（而非假设）
• 对于代码中不可见的运行时特征（例如实际数据量、网络延迟要求），“无法确定”是合理结论
• 对于共享数据库，始终标记迁移顺序限制——这是造成迁移复杂性的首要原因
• 静态分析得出的成本估算只是粗略估算——应说明其中的不确定性，并建议使用 AWS Pricing Calculator 精确估算
• 应突出说明已具备迁移就绪条件的方面（已容器化、无状态、已有 IaC）