2. 现状评估与目标蓝图
迁移项目最容易失败的地方，不是技术执行，而是在没看清现状之前就开始搬数据。现状评估与目标蓝图这一步，本质上是回答三个问题：我们现在到底有什么？迁移后应该长成什么样？怎么算迁移成功？这三个问题不回答清楚，后面的数据迁移、权限映射、集成改造都会变成反复返工。
一、盘点什么：五类资产与它们的真实边界
Atlassian 环境的盘点不能只数“有多少个 Jira 项目”，而要按资产类型分层清点，因为每一类资产的迁移难度和风险完全不同。
- 实例层：Server / Data Center / Cloud 的版本号、节点数、数据库类型（PostgreSQL/MySQL/SQL Server）、附件存储方式（本地/NFS/S3）、当前用户数（License 席位）。例如一个 Jira Software 9.4 DC 双节点集群，数据库 PostgreSQL 13，附件走 NFS，这决定了后续迁移工具的选择。
- 用户与组：本地目录还是对接 LDAP/AD？组数量、嵌套组深度、外部目录同步频率。用户盘点的关键是找出“僵尸账号”和“跨实例重复账号”，它们会直接影响 License 成本和权限映射。
- 项目与空间：Jira 项目（按业务线、团队、类型分类）、Confluence 空间、Bitbucket 仓库。要记录每个项目的 Issue 数量、工作流数量、自定义字段数量、看板数量。
- 应用与插件：Marketplace 应用、自研插件、脚本监听器（ScriptRunner、JMWE 等）。插件是迁移的最大变量，必须逐个确认是否有 Cloud 版本、是否被平台原生功能替代。
- 集成与外部依赖：SSO（SAML/OIDC）、CI/CD（Jenkins、GitLab）、监控告警、Webhook、REST API 调用方、邮件服务器、备份任务。
盘点的产出不是一张清单，而是一份带风险标记的资产台账。建议为每个资产记录：名称、类型、负责人、使用频率、迁移优先级、阻塞项。使用频率这一列尤其重要——它决定了哪些项目值得迁移，哪些应该归档而不是搬运。
二、怎么盘：从自动采集到人工确认
手工填表效率低且容易遗漏，实际项目中通常采用“自动采集 + 人工确认”的组合方式。
Jira 和 Confluence 都提供 REST API，可以批量导出项目、空间、用户、组、插件信息。例如获取所有项目的关键字段：
GET /rest/api/2/project?expand=description,lead,issueTypes
GET /rest/api/2/field
GET /rest/api/2/workflow
GET /rest/plugins/1.0/ （DC 环境插件列表）Confluence 侧可调用 /rest/api/space 和 /rest/api/user。把这些结果导入表格后，再按业务线组织负责人做一轮确认，重点确认三件事：项目是否还在用、插件是否还有业务依赖、集成调用方是否已知。
三、目标架构：不是“搬到 Cloud”，而是重新设计
很多团队把迁移目标写成“把 Server 上的东西搬到 Cloud”，这是危险的。正确的目标蓝图应该描述迁移后的组织方式，通常涉及几个关键决策：
- 实例拓扑：单 Cloud 站点还是多站点？是否按业务线拆分？
- 用户与权限模型：是否借迁移机会收敛组结构？是否引入 Atlassian Access 做 SSO 和用户生命周期管理？
- 项目归并策略：多个相似项目是否合并？历史项目是否只读归档？
- 插件替代方案：哪些插件用 Cloud 原生功能替代，哪些换 Marketplace 应用，哪些直接砍掉。
- 集成改造：Webhook 地址、API 认证方式（从 PAT 改为 API Token 或 OAuth）、CI/CD 触发链路。
目标架构应该画成一张图，让所有干系人看到“迁移后长什么样”。下面这张图展示了一个典型的目标架构：以 Cloud 站点为核心，左侧是用户与身份层，右侧是集成与外部系统，中间是项目与空间的组织方式。
四、成功标准：可量化、可验证、可签字
“迁移成功”不能是一句感觉。目标蓝图必须配套一组可验证的成功标准，通常分为四类：
| 维度 | 指标示例 | 验证方式 |
|---|---|---|
| 数据完整性 | Issue 数量、附件数量、评论数量迁移后与源端一致率 ≥ 99.5% | 迁移工具报告 + 抽样比对 |
| 用户可用性 | SSO 登录成功率 ≥ 99%，用户首次登录引导完成率 ≥ 90% | Access 日志 + 用户反馈 |
| 集成可用性 | 关键 Webhook、CI/CD 触发、告警链路全部恢复 | 端到端联调测试 |
| 业务连续性 | 迁移窗口内业务中断 ≤ 4 小时，回滚方案可在 1 小时内执行 | 演练 + 切换记录 |
这些标准要在项目启动阶段就与业务方、IT 运维、安全团队共同确认，并明确谁签字验收。否则迁移完成后，业务方说“感觉不对”，项目就无法收尾。
五、从盘点结果到迁移决策
盘点完成后，每个资产都应该有一个明确的处置决策，通常分为四类：
- 直接迁移：活跃项目、有明确业务价值、插件有 Cloud 替代方案。
- 归并迁移：多个相似项目合并为一个，减少后续维护成本。
- 只读归档：历史项目保留查询能力，但不参与日常协作，可考虑导出为静态存档或保留在只读实例。
- 废弃：无人使用、无业务依赖、数据无保留价值，直接不迁移。
这个决策过程需要业务负责人参与，不能由 IT 单方面决定。建议用一张“资产处置表”记录每个项目的决策、理由和负责人，作为后续迁移排期的输入。
现状评估与目标蓝图的最终产出，是一份迁移范围说明书：包含资产台账、目标架构图、成功标准、处置决策和风险清单。这份文档是后续所有迁移工作的基准，也是变更控制的依据。没有它，迁移就会变成一场没有地图的远征。