migration-readiness
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseMigration Readiness Assessment
迁移就绪性评估
Step 1: Gather context
步骤1：收集背景信息
Ask the user:
What workload are you planning to migrate? Please share:
- Current environment (on-premises, other cloud, colocation)
- Application stack (languages, frameworks, databases, middleware)
- Dependencies (other systems it talks to, shared databases, network requirements)
- Business drivers (cost, agility, compliance, end-of-life hardware, etc.)
- Timeline constraints (optional)
If context is already provided, proceed directly.
询问用户：
你计划迁移哪个工作负载？请分享：
- 当前环境（本地数据中心、其他云服务商、托管机房）
- 应用栈（编程语言、框架、数据库、中间件）
- 依赖关系（与之交互的其他系统、共享数据库、网络要求）
- 业务驱动因素（成本、敏捷性、合规性、硬件生命周期结束等）
- 时间线约束（可选）
如果已提供背景信息，直接进入下一步。
Step 2: Determine migration strategy (7 Rs)
步骤2：确定迁移策略（7 Rs）
For the workload, evaluate which strategy fits:
| Strategy | When to use |
|---|---|
| Rehost (lift & shift) | Fast migration, minimal changes, optimize later |
| Replatform (lift & reshape) | Small optimizations during move (e.g., managed DB) |
| Refactor (re-architect) | Need cloud-native benefits, willing to invest |
| Repurchase | Replace with SaaS (e.g., CRM → Salesforce) |
| Retire | No longer needed |
| Retain | Not ready to move yet |
| Relocate | VMware workloads → VMware Cloud on AWS |
Recommend a strategy with justification based on the user's drivers and constraints.
针对该工作负载，评估适合的策略：
| 策略（Strategy） | 使用场景 |
|---|---|
| Rehost（直接迁移） | 快速迁移、改动最小、后续优化 |
| Replatform（迁移并重塑） | 迁移过程中进行小幅优化（如使用托管数据库） |
| Refactor（重构） | 需要云原生优势、愿意投入资源 |
| Repurchase | 替换为SaaS服务（如CRM → Salesforce） |
| Retire | 不再需要该工作负载 |
| Retain | 暂不准备迁移 |
| Relocate | VMware工作负载 → VMware Cloud on AWS |
根据用户的驱动因素和约束条件，推荐合适的策略并说明理由。
Step 3: Assess readiness by pillar
步骤3：按支柱评估就绪性
For each pillar, classify readiness as:
- 🟢 Ready — no blockers, can proceed
- 🟡 Conditionally Ready — gaps exist but can be addressed during migration
- 🔴 Not Ready — blockers must be resolved before migration
针对每个支柱，将就绪性分为三类：
- 🟢 就绪 — 无阻碍因素，可直接推进
- 🟡 有条件就绪 — 存在差距，但可在迁移过程中解决
- 🔴 未就绪 — 阻碍因素必须在迁移前解决
Operational Excellence
卓越运营（Operational Excellence）
- Is there IaC for the current environment? Can it be adapted?
- Are CI/CD pipelines in place?
- Is monitoring portable or cloud-specific?
- Are operational runbooks documented?
- 当前环境是否有基础设施即代码（IaC）？能否适配AWS？
- 是否已部署CI/CD流水线？
- 监控系统是可移植的还是云专属的？
- 操作手册是否已文档化？
Security
安全（Security）
- Are there compliance requirements that affect region/service choice?
- How are secrets and certificates managed today?
- Are there network security dependencies (firewalls, IDS) that need equivalents?
- Is identity federation in place or needed?
- 是否存在影响区域/服务选择的合规要求？
- 当前如何管理密钥和证书？
- 是否有需要替代方案的网络安全依赖项（防火墙、入侵检测系统）？
- 是否已部署或需要身份联合认证？
Reliability
可靠性（Reliability）
- What is the current availability? What's the target post-migration?
- Are there HA/DR mechanisms that need to be replicated?
- What's the acceptable downtime during migration?
- Are backups and recovery procedures tested?
- 当前的可用性如何？迁移后的目标可用性是什么？
- 是否有需要复制的高可用/灾难恢复机制？
- 迁移过程中可接受的停机时间是多少？
- 备份和恢复流程是否经过测试？
Performance Efficiency
性能效率（Performance Efficiency）
- Are there latency-sensitive integrations?
- Are there hardware-specific dependencies (GPUs, FPGAs, specific CPU)?
- What are the current performance baselines?
- Are there performance SLAs that must be maintained during cutover?
- 是否存在对延迟敏感的集成？
- 是否有硬件特定依赖项（GPU、FPGA、特定CPU）？
- 当前的性能基线是什么？
- 切换期间是否必须维持性能SLA？
Cost Optimization
成本优化（Cost Optimization）
- What's the current TCO?
- What's the expected AWS cost? (rough estimate)
- Are there licensing implications? (BYOL, license-included)
- Are there existing commitments (contracts, prepaid licenses)?
- 当前的总拥有成本（TCO）是多少？
- 预计AWS成本是多少？（粗略估算）
- 是否存在许可影响？（自带许可、包含许可）
- 是否有现有承诺（合同、预付费许可）？
Sustainability
可持续性（Sustainability）
- Can the migration reduce resource footprint?
- Are there opportunities to use Graviton or serverless?
- Can managed services replace self-managed infrastructure?
- 迁移能否减少资源占用？
- 是否有使用Graviton或无服务器服务的机会？
- 能否用托管服务替代自建基础设施？
Step 4: Identify risks and blockers
步骤4：识别风险与阻碍因素
Classify each risk by severity:
- 🔴 High Risk — can block migration or cause failure
- 🟡 Medium Risk — increases effort or timeline but manageable
- 🟢 Low Risk — minor impact, address during optimization
Flag:
- Hard dependencies on on-premises systems that can't move yet
- Licensing restrictions (Oracle, Windows, third-party software)
- Data residency or sovereignty requirements
- Large data volumes requiring transfer planning (Snowball, DataSync, DMS)
- Skills gaps in the team
- Compliance re-certification requirements
- Performance-sensitive integrations with on-premises systems
按严重程度对每个风险分类：
- 🔴 高风险 — 可能阻碍迁移或导致失败
- 🟡 中风险 — 增加工作量或延长时间线，但可管控
- 🟢 低风险 — 影响较小，可在优化阶段解决
重点标记：
- 对暂无法迁移的本地系统存在强依赖
- 许可限制（Oracle、Windows、第三方软件）
- 数据驻留或主权要求
- 需要传输规划的大规模数据量（Snowball、DataSync、DMS）
- 团队技能差距
- 合规重新认证要求
- 与本地系统的性能敏感型集成
Step 5: Produce the assessment
步骤5：生成评估报告
Output:
markdown
undefined输出内容：
markdown
undefinedMigration Readiness Assessment: {Workload Name}
迁移就绪性评估：{工作负载名称}
Summary
摘要
- Recommended strategy: {strategy}
- Overall readiness: {Ready / Conditionally Ready / Not Ready}
- Estimated effort: {T-shirt size with justification}
- Key risks: {top 2-3}
- Estimated timeline: {weeks/months}
- 推荐策略：{strategy}
- 整体就绪状态：{就绪 / 有条件就绪 / 未就绪}
- 预计工作量：{T恤尺码式估算及理由}
- 关键风险：{前2-3项}
- 预计时间线：{周/月}
Migration Strategy Rationale
迁移策略理由
{Why this strategy fits the workload and business drivers}
{该策略为何适配工作负载和业务驱动因素}
Readiness Scorecard
就绪性评分卡
| Pillar | Readiness | Score (1-5) | Key Gap |
|---|---|---|---|
| Operational Excellence | 🟢/🟡/🔴 | {score} | {gap} |
| Security | 🟢/🟡/🔴 | {score} | {gap} |
| Reliability | 🟢/🟡/🔴 | {score} | {gap} |
| Performance Efficiency | 🟢/🟡/🔴 | {score} | {gap} |
| Cost Optimization | 🟢/🟡/🔴 | {score} | {gap} |
| Sustainability | 🟢/🟡/🔴 | {score} | {gap} |
| 支柱 | 就绪状态 | 评分（1-5） | 关键差距 |
|---|---|---|---|
| 卓越运营 | 🟢/🟡/🔴 | {score} | {gap} |
| 安全 | 🟢/🟡/🔴 | {score} | {gap} |
| 可靠性 | 🟢/🟡/🔴 | {score} | {gap} |
| 性能效率 | 🟢/🟡/🔴 | {score} | {gap} |
| 成本优化 | 🟢/🟡/🔴 | {score} | {gap} |
| 可持续性 | 🟢/🟡/🔴 | {score} | {gap} |
Risks and Blockers
风险与阻碍因素
| Risk | Severity | Impact | Mitigation | AWS Service |
|---|---|---|---|---|
| {risk} | 🔴/🟡/🟢 | {impact} | {mitigation} | {service} |
| 风险 | 严重程度 | 影响 | 缓解措施 | AWS服务 |
|---|---|---|---|---|
| {risk} | 🔴/🟡/🟢 | {impact} | {mitigation} | {service} |
Pre-Migration Checklist
迁移前检查清单
{What must be done before migration starts, ordered by priority}
{迁移开始前必须完成的事项，按优先级排序}
Migration Plan
迁移计划
Phase 1: Assess & Mobilize (Weeks 1-2)
阶段1：评估与动员（第1-2周）
{Discovery, dependency mapping, landing zone setup}
{发现、依赖关系映射、着陆区设置}
Phase 2: Migrate (Weeks 3-6)
阶段2：迁移（第3-6周）
{Data migration, application migration, testing}
{数据迁移、应用迁移、测试}
Phase 3: Optimize (Weeks 7-8)
阶段3：优化（第7-8周）
{Right-sizing, cost optimization, performance tuning}
{合理调整资源规模、成本优化、性能调优}
AWS Services for Migration
AWS迁移服务
| Category | Service | Purpose |
|---|---|---|
| Server migration | AWS MGN | Rehost EC2 workloads |
| Database migration | AWS DMS | Replicate databases with minimal downtime |
| Data transfer | DataSync / Snowball | Large-scale data movement |
| Schema conversion | AWS SCT | Convert database schemas |
| Network | Direct Connect / VPN | Hybrid connectivity |
| Landing zone | Control Tower | Multi-account governance |
| 类别 | 服务 | 用途 |
|---|---|---|
| 服务器迁移 | AWS MGN | 重新托管EC2工作负载 |
| 数据库迁移 | AWS DMS | 以最小停机时间复制数据库 |
| 数据传输 | DataSync / Snowball | 大规模数据迁移 |
| 架构转换 | AWS SCT | 转换数据库架构 |
| 网络 | Direct Connect / VPN | 混合连接 |
| 着陆区 | Control Tower | 多账户治理 |
Cost Comparison
成本对比
| Category | Current (monthly) | Estimated AWS (monthly) | Savings |
|---|---|---|---|
| Compute | {current} | {estimated} | {delta} |
| Storage | {current} | {estimated} | {delta} |
| Networking | {current} | {estimated} | {delta} |
| Licensing | {current} | {estimated} | {delta} |
| Total | {total} | {total} | {delta} |
undefined| 类别 | 当前（月度） | 预计AWS（月度） | 节省金额 |
|---|---|---|---|
| 计算 | {current} | {estimated} | {delta} |
| 存储 | {current} | {estimated} | {delta} |
| 网络 | {current} | {estimated} | {delta} |
| 许可 | {current} | {estimated} | {delta} |
| 总计 | {total} | {total} | {delta} |
undefinedStep 6: Offer follow-up
步骤6：提供后续支持
After delivering the assessment, offer:
Would you like me to:
- Design the AWS landing zone architecture?
- Create a detailed data migration plan?
- Estimate AWS costs in more detail (instance mapping, storage tiers)?
- Build a pre-migration testing strategy?
- Identify quick wins to demonstrate value early?
交付评估报告后，询问用户：
是否需要我协助：
- 设计AWS着陆区架构？
- 创建详细的数据迁移计划？
- 更详细地估算AWS成本（实例映射、存储层级）？
- 制定迁移前测试策略？
- 识别可快速展示价值的优化点？