3. 迁移就绪度评估
在正式启动 Atlassian Cloud 迁移之前，最容易被低估的环节不是数据导出，而是就绪度评估。很多团队在迁移中途才发现：某个关键应用没有 Cloud 版本、某个审批流程依赖已停用的 ScriptRunner 脚本、或者项目管理员根本不知道自己要负责用户验收。这些问题如果在迁移前用一份结构化问卷诊断出来，就能转化为可排期的整改项，而不是迁移当天的阻塞点。
就绪度评估的本质，是用一套可重复的问卷，把组织当前 Server/Data Center 环境的真实状态，映射到 Cloud 迁移所要求的目标状态上，并量化两者之间的差距。评估对象不是"系统能不能迁"，而是"组织现在是否具备迁移的条件"。因此问卷必须覆盖四个维度：技术、流程、人员、数据。这四个维度分别回答四个问题：环境能不能迁、工作方式能不能延续、人能不能承接、数据能不能安全落地。
四维问卷的设计逻辑
问卷不是泛泛的满意度调查，每个问题都应指向一个可判定的迁移风险。设计时遵循"一题一风险、答案可分级、分级可行动"的原则。建议采用 0–3 分四级评分：0 分表示完全不具备、1 分表示部分具备但需大量改造、2 分表示基本具备需少量调整、3 分表示已满足 Cloud 要求。总分用于排序，但更重要的是单项低分——任何一个 0 分项都可能是迁移的硬阻塞。
技术维度关注环境与集成的可迁移性。典型问题包括：当前 Jira/Confluence 版本是否在 Atlassian 支持的迁移路径内；使用了哪些 Marketplace 应用，其中哪些已有 Cloud 版本、哪些仅有 Data Center 版本、哪些已停止维护；是否存在自定义的 Jira 工作流后置函数、监听器、REST 端点或 Confluence 用户宏；SSO 与用户目录是本地 LDAP 还是已接入 SAML/OIDC；是否有对外暴露的 API 被其他系统调用。这些问题的答案直接决定迁移是"配置迁移"还是"重写迁移"。
流程维度关注工作方式能否在 Cloud 中延续。例如：是否存在跨项目的全局审批流、依赖 Jira 自动化规则串联的多系统流程、Confluence 中大量使用嵌套页面模板的发布流程。Cloud 的自动化能力、权限模型和部分功能边界与 Server 不同，流程问卷要识别出哪些流程需要重新设计，而不是简单搬运。
人员维度关注组织承接能力。包括：是否有明确的迁移负责人和决策链；站点管理员、项目管理员、普通用户三类角色的 Cloud 操作经验；是否有内部培训计划；关键用户能否在迁移窗口参与 UAT。人员维度得分低，往往意味着即使技术迁移成功，上线后也会因使用混乱而回退。
数据维度关注数据规模、质量与合规。需要统计：项目数、问题数、附件总量、页面数与历史版本数；是否存在大量孤立附件、重复用户、失效的权限方案；数据是否涉及个人敏感信息或行业合规要求；备份与回滚策略是否明确。数据量直接影响迁移窗口和分批策略，数据质量则影响迁移后的可用性。
问卷落地：从题目到评分
下面给出一份可直接使用的四维问卷示例。每维度 6 题，共 24 题，满分 72 分。评分标准统一为：0 = 完全不具备，1 = 部分具备需大量改造，2 = 基本具备需少量调整，3 = 已满足 Cloud 要求。示例中的分值为某虚构组织的填写结果，用于说明如何判读。
| 维度 | 关键问题 | 示例得分 | 判读 |
|---|---|---|---|
| 技术 | 当前版本是否在支持迁移路径内 | 3 | 可直接迁移 |
| Marketplace 应用是否有 Cloud 版本 | 1 | 2 个应用无 Cloud 版，需替代方案 | |
| 是否存在自定义监听器/后置函数 | 0 | 硬阻塞，需重写或移除 | |
| 流程 | 全局审批流是否依赖 Server 专属功能 | 2 | 需局部调整 |
| 自动化规则是否跨系统串联 | 1 | 需重新设计触发链 | |
| 人员 | 是否有明确迁移负责人 | 3 | 已具备 |
| 关键用户能否参与 UAT | 2 | 需协调时间窗口 | |
| 数据 | 附件总量与迁移窗口是否匹配 | 1 | 需分批迁移 |
| 是否存在敏感数据合规要求 | 2 | 需脱敏或隔离策略 |
评分完成后，不要只看总分。正确的判读顺序是：先看0 分项，它们是硬阻塞，必须优先解决；再看1 分项，它们是主要改造工作量来源；2 分项纳入迁移计划中的调整任务；3 分项可作为迁移的稳定基础。示例中技术维度出现 0 分，说明该组织不能直接进入迁移执行阶段，必须先完成自定义代码的替代方案设计。
评估报告的结构与输出
评估报告不是问卷结果的堆砌，而是一份决策文档。建议包含五个部分：
- 总览：四维得分与总分，用雷达图呈现各维度均衡度。若某维度显著低于其他维度，说明该维度是短板，需优先投入资源。
- 阻塞项清单：列出所有 0 分项，每项注明影响范围、责任人和建议解决路径。例如"自定义监听器 3 个，影响 2 个关键项目，需在迁移前用 Cloud 自动化规则替代或移除"。
- 改造项清单：列出 1 分项，估算工作量并排入迁移前整改计划。
- 迁移批次建议：根据数据量、流程复杂度和人员准备度，建议先迁移低风险项目作为试点，再逐步扩展。
- 风险与回滚：明确迁移窗口、备份策略和回滚触发条件。
常见误区与判断依据
第一个误区是"技术维度得分高就代表可以迁移"。技术只是必要条件，流程和人员维度同样可能成为阻塞。例如某组织技术得分 16/18，但人员维度只有 6/18，关键用户完全不了解 Cloud 操作，迁移后很可能出现使用混乱和回退。第二个误区是"问卷填完就结束"。问卷的价值在于驱动整改，必须把低分项转化为有责任人、有截止时间的行动项，否则评估只是形式。
判断就绪度是否达标，建议设定一个可操作的阈值：总分 ≥ 54 分（75%）且无 0 分项，可进入迁移执行阶段；总分在 40–53 分之间，需完成整改后复评；总分低于 40 分，说明组织尚未准备好，应推迟迁移并优先补齐短板。这个阈值不是绝对标准，但能帮助团队在"感觉差不多了"和"真正可以开始"之间建立明确界限。
最后需要强调，就绪度评估不是一次性动作。在整改过程中，建议每两周对低分项进行一次复评，观察分数变化。当所有 0 分项清零、1 分项显著减少时，迁移的确定性会大幅提升。评估报告也应随复评结果更新，成为迁移项目的一份动态基线文档。