上云迁移项目计划模板

模板包含什么

上云迁移其实不是一个项目，而是一次基础环境建设，加上一段不断重复的批次循环。模板把两者分开，好让 Landing Zone 在各批次依赖它之前先完工：

• 现状梳理与评估 — 应用清单、依赖关系梳理、业务重要性分级，以及每个工作负载的 7R 处置决策——重新托管、平台改造、重构、替换采购、迁移位置、退役、保留。里程碑：应用处置方案确定。
• Landing Zone 与基础环境 — 账号与订阅结构、网络与专线连通、身份认证、安全基线、日志与成本模型。后面所有工作都依赖这一层。里程碑：Landing Zone 就绪。
• 批次规划与试点 — 按依赖关系而不是按部门把应用分批，然后用一个低风险的试点批次把迁移手册跑通。
• 迁移批次 — 每个批次重复搭建、迁移、测试、割接这一循环。动作每次都一样，变的是风险等级。
• 割接与强化支持 — 生产割接、DNS 与流量切换、回退窗口，以及每个批次之后的强化支持期。里程碑：生产割接完成。
• 下线与优化 — 关停源环境、退出机房或托管合同，然后做规格优化和预留容量承诺。投资收益测算里的账，到这一步才真正兑现。

如何调整

1. 先把机房退出或托管合同的到期日定死再倒推——这个日期通常是合同约定、没有商量余地的。
2. 应用清单完成后按应用加行，挂在承载它的那个批次下面。
3. 每增加一个批次就复制一份批次阶段；内部结构完全一样。
4. 把需要重构的应用整个移出批次计划——那是开发项目，不是迁移，混在一起会打乱批次节奏。
5. 把 Landing Zone 就绪、试点批次完成、每次生产割接和源环境下线都设为里程碑。

排期建议

• Landing Zone 没完工就不要开批次。迁进一个还在变的基础环境里，等于要迁第二遍，这是这类项目最常见的返工来源。
• 按依赖关系分批，不要按部门分批。互相调用的应用要一起迁，否则在两套环境被拆开的这段时间里，你要为它们之间的网络时延买单。
• 试点批次要认真做。它的目的是跑通手册、把意外提前暴露出来，所以挑的应用要风险低但有代表性，而不是清单上最容易的那三个。
• 并行运行的成本要提前算进去。整个迁移期间两套环境都在跑，这段重叠成本是实打实的，第一天就该写进测算里。
• 每次割接都要留回退窗口。没有书面且演练过的回退方案的割接，等于在没想清楚的情况下推开了一扇单向门。

相关模板

• ERP 实施进度计划
• 软件开发项目甘特图模板
• 数据中心建设进度计划
• 查看全部甘特图模板

本模板为中文。尚未翻译的相关页面会以英文打开。

常见问题