基础设施迁移
虚拟机、存储、网络：包括 Windows 和 Linux 服务器、VMware 环境以及 NFS/SMB 存储。
- AWS MGN
- DataSync
- Storage Gateway
云计算 · 迁移
搬走整个系统，不搬走风险。
分波次迁移：AWS MAP 资助，对业务运营的干扰最小。
Phoenix 交付分波次的云迁移：基础设施、应用、数据库和专用工作负载（SAP、Windows、定制系统）。大多数项目在 AWS Migration Acceleration Program（MAP）内运行，该计划为迁移提供资金，并为我们提供经过验证的方法论来组织工作。
我们规划迁移，用试点波次验证路径，然后规模化执行，托管服务团队同步就位，切换后的第一天即可投入运营。
服务范围。
应用迁移
套装应用、定制代码、集成与消息：根据价值选择重平台化或直接迁移。
- Custom apps
- Middleware
- Integration
数据库迁移
Oracle、SQL Server、MySQL 和 PostgreSQL，同构或异构。RDS、Aurora 与自管方案按工作负载评估。
- AWS DMS
- SCT
- RDS
- Aurora
工作负载迁移
SAP on AWS（通过 RISE 或自管）、Windows 密集型系统、HPC 及需要审慎方案的专用工作负载。
- SAP on AWS
- RISE
- Windows
交付方法。
-
01
评估：迁移就绪评估（MRA）
发现、TCO 建模、波次规划、依赖映射：在承诺之前明确迁移的形态和规模。
-
02
动员：基础与试点
落地区就位、工具链搭建，试点波次端到端迁移以验证路径。
-
03
迁移：分波次执行
按业务单元、关键性或依赖关系分组波次。切换演练，然后带 rollback 方案的生产切换。
-
04
现代化：上线后的价值提升
迁移过程中识别的现代化事项会被排期并交付，而不是停留在幻灯片上。
明确的交付物。
每个项目都交付具体的成果物，而非一堆幻灯片。
- 含 TCO 模型和波次计划的迁移就绪评估
- 经业务验证的试点波次迁移
- 带 rollback 方案、按计划完成的生产波次切换
- 移交托管服务团队，承接第二天运营
- 与客户商定的迁移后现代化清单
常见问题
你们对每个工作负载使用 7R 中的哪一个？
在评估中按工作负载逐个选择。时间紧迫的直接迁移用 Rehost（lift-and-shift）；需要合理调整实例 / 操作系统 / 数据库版本的用 Replatform；适合云原生的工作负载用 Refactor / Re-architect；迁移不具备商业价值的用 Retire 和 Retain。
你们具备 MAP 资格吗？商业上意味着什么？
具备。Phoenix 是 AWS Migration Acceleration Program（MAP）合作伙伴。对于符合条件的工作负载，AWS 会与客户投入共同出资迁移抵扣，实质性地抵消项目成本。范围界定工作坊会逐个确认每个工作负载的 MAP 资格。
你们如何处理 SAP 专属迁移：HANA 和经典 ECC？
SAP-on-AWS 迁移遵循 SAP 认证参考架构。HANA 工作负载使用认证实例系列（X2iedn / R5b / U7in 及其后续型号）和匹配 IOPS 配置的 Amazon EBS。带任意数据库的经典 ECC 按 SAP OS/DB 迁移程序执行，或与 HANA 转换合并为一个项目。
切换风险如何管理？
分波次规划，设有明确的 go/no-go 关口、彩排演练，以及可回退的切换程序，源系统在确认成功前保持在线。业务连续性围绕明确的 RTO/RPO 目标规划；灾难恢复在切换前而非切换后建立。
上线之后呢，我们自己运营吗？
可选。Phoenix 可以附带运行手册和文档移交给您的团队，也可以将工作负载转入我们的云与数据托管服务（CloudOps + DataOps + MLOps），让持续运营、补丁和成本管理在 SLA 下继续。
