1. 迁移整合全景

Atlassian 企业平台迁移与整合，指的是把分散在多个 Atlassian 站点、多个版本形态（Cloud、Data Center、Server）以及多个业务域中的 Jira、Confluence、Bitbucket、Jira Service Management 等产品，按照统一的组织模型、权限模型和数据模型，迁移并收敛到目标平台上的系统性工程。它不只是“把数据搬过去”，而是同时处理身份与权限、项目与空间结构、应用与集成、历史数据与附件、自动化与插件、审计与合规六条主线，使迁移后的平台在功能、性能与治理能力上不低于迁移前，并尽可能消除历史遗留的重复与割裂。

理解这个定义时，需要区分三个容易混淆的概念：迁移（Migration）关注数据与配置从源到目标的搬运；整合（Consolidation）关注多个源站点合并为更少的目标站点，伴随去重、标准化与结构重设计；升级/转型（Transformation）关注平台形态变化，例如 Server 到 Data Center、Data Center 到 Cloud。企业实践中三者往往同时发生，因此需要一个统一的全景框架来管理依赖关系，而不是把它们当作三个独立项目。

驱动因素：为什么企业必须做这件事

驱动因素通常来自四个方向，且往往叠加出现。第一是产品生命周期：Atlassian 已明确 Server 产品停止支持，Data Center 也进入以 Cloud 为主的长期路线，继续停留在旧版本会失去安全补丁与官方支持。第二是成本与运维：自建 Data Center 需要承担服务器、数据库、高可用、备份、插件兼容与升级窗口的人力成本，站点越多，边际成本越高。第三是治理与合规：多站点导致权限模型不一致、审计日志分散、数据驻留难以证明，SOX、ISO 27001、等保等要求难以统一满足。第四是业务协同：并购、事业部独立采购、历史试点等原因造成同一家公司存在多个 Jira 与 Confluence，跨团队报表、依赖管理与知识检索效率低下。

典型场景与迁移路径

企业常见场景可以归纳为四类。场景 A：多 Server 合并上 Cloud，例如并购后 5 个 Jira Server 合并为 1 个 Jira Cloud 站点。场景 B：Data Center 内部整合，多个 DC 实例合并为一个多节点集群，暂不上云。场景 C：DC 到 Cloud 的分批迁移，按业务域分批切换，保留双向同步过渡期。场景 D：Cloud 到 Cloud 的站点合并，常见于子公司已有 Cloud 但需并入集团站点。不同场景对工具链的要求不同：上云通常依赖 Atlassian Cloud Migration Assistant（CMA）与 Jira Cloud Migration Assistant；DC 内部整合更依赖项目导入导出、数据库级合并与插件重配；Cloud 合并则更多依赖 CSV、API 与第三方迁移工具。

端到端流程框架

无论哪种场景，端到端流程都可以抽象为六个阶段，但每个阶段的深度和顺序会因场景调整。第一阶段发现与评估：盘点源站点数量、产品版本、用户数、项目/空间数、附件总量、插件清单、集成清单，输出迁移范围与优先级。第二阶段目标设计：确定目标站点数量、产品组合、组织与权限模型、项目键与空间键命名规范、字段与工作流标准。第三阶段试点迁移：选择 1 至 2 个低风险项目或空间做端到端验证，校准工具参数、附件路径、用户映射与权限映射。第四阶段批量迁移：按波次执行，每波次包含冻结窗口、数据迁移、增量同步、验证与切换。第五阶段集成与自动化重建：重建 Webhook、CI/CD 连接、应用链接、自动化规则与插件替代方案。第六阶段收尾与退役：只读保留旧站点一段时间，完成审计取证后下线，并更新运维手册与培训材料。

关键参数与判断依据（示例）

为了让流程可执行，需要把“迁移完成”转化为可度量的判断条件。以下参数为教学示例，实际项目应结合自身规模调整。用户映射一致率：目标站点中成功匹配到源用户的活跃用户数 ÷ 源站点活跃用户数，建议 ≥ 99.5%。问题迁移完整率：目标站点问题数 ÷ 源站点问题数，建议 ≥ 99.9%，差异需逐条说明。附件完整率：目标附件数 ÷ 源附件数，建议 100%，因为附件缺失通常不可恢复。权限一致率：抽样 20 个项目的权限方案与源站点比对，建议 ≥ 99%。增量同步延迟：切换前最后一次增量同步到切换时刻的时间差，建议 < 5 分钟。回滚时间目标：从决定回滚到旧站点恢复可写状态，建议 < 30 分钟。

一个可复用的迁移波次规划示例

假设某企业有 3 个 Jira Server 站点，共 420 个项目、8600 名用户、1.2 TB 附件，目标为 1 个 Jira Cloud 站点。可按以下波次规划：波次 0 为试点，选择 2 个低风险项目，验证用户映射、附件迁移与权限方案；波次 1 迁移 80 个低依赖项目，观察 1 周；波次 2 迁移 150 个中等依赖项目，同步重建应用链接；波次 3 迁移 120 个高依赖项目，包含 CI/CD 与自动化规则；波次 4 迁移剩余 68 个项目并处理历史归档。每个波次包含冻结窗口（建议 2 至 4 小时）、迁移执行、验证清单、切换与回滚决策点。冻结窗口内源站点设为只读，避免增量数据丢失。

最后需要强调，迁移整合的成功标准不是“数据搬完”，而是“业务连续、治理统一、成本可控、可审计”。因此从第一天起就应建立迁移台账，记录每个项目、空间、用户组、插件与集成的状态，并在每个阶段结束时更新。这样在收尾阶段才能清晰回答：哪些已迁移、哪些已替代、哪些已退役、哪些仍需保留只读。这个台账本身，就是企业平台治理能力的一部分。