3. 迁移策略选型

在 Atlassian 企业平台迁移中，策略选型决定了后续工作量、停机窗口、数据风险和回退难度。常见的四条路线是：就地升级、重建迁移、混合过渡与分阶段切换。它们并非互斥，而是针对不同现状、约束和目标形成的组合。选型的关键不是追求“最先进”，而是让策略与组织的版本差距、定制复杂度、合规要求和可接受停机时间相匹配。

四条路线的本质差异

就地升级是在现有实例上逐级升级，保留原有项目、用户、权限和工作流。它适合版本差距小、定制少、插件兼容性明确的场景。例如从 Jira Data Center 9.4 升到 9.12，通常只需按官方升级路径逐跳执行，停机窗口可控制在数小时内。风险集中在插件不兼容、数据库版本不支持和升级后索引重建失败。

重建迁移是在新实例中重新搭建配置，再通过导入或 API 迁移业务数据。它适合版本差距大、历史配置混乱、需要借机治理数据模型的场景。优点是能清理废弃项目、统一工作流和权限方案；代价是迁移周期长，且用户、附件、评论历史等需要逐项验证。

混合过渡是旧实例继续运行，新实例并行承载部分团队或新项目，通过应用链接、双向同步或网关逐步收敛。它适合不能一次性停机的大型组织，但会引入双份许可、数据一致性和同步延迟问题。

分阶段切换是按项目、部门或地域分批迁移，每批完成后旧实例对应部分下线。它介于重建与混合之间，强调可控的批次边界和回退点，适合项目之间依赖较弱、可独立验收的企业。

适用条件与风险对照

就地升级的硬性前提是：当前版本仍在 Atlassian 支持矩阵内，数据库、JDK、操作系统满足目标版本要求，且所有关键插件已有兼容版本。若存在自研插件或已停止维护的插件，升级后可能出现功能缺失，需要提前做兼容性扫描。升级前必须完成数据库备份、附件目录备份和 dbconfig.xml 留存，并在预生产环境完整演练一次。

重建迁移的适用条件是：版本跨度超过两个大版本、历史项目大量废弃、权限方案混乱到无法维护，或企业希望借迁移统一工作流。它的核心风险是数据映射不完整。例如旧实例中自定义字段“客户等级”在重建后若未建立对应字段，历史问题中的值会丢失。因此需要先做字段清单比对，再决定哪些字段保留、合并或废弃。

混合过渡适合并购整合、多地域合规隔离或无法获得统一停机窗口的场景。典型做法是旧 Jira 与新 Jira Cloud 通过应用链接建立项目级连接，或使用第三方同步工具保持问题状态一致。风险在于同步冲突：同一问题在两端被同时编辑时，后写入的一方可能覆盖前者。必须定义“单一写入端”规则，例如旧实例只读、新实例可写，或按项目划分写入权限。

分阶段切换适合项目间依赖弱、可按部门独立验收的企业。每批迁移前冻结该批项目配置，迁移后执行用户验收测试，通过后再下线旧实例对应部分。风险是批次间共享的看板、过滤器或仪表盘可能引用未迁移项目，导致切换后显示异常。因此每批都要检查跨项目引用。

决策方法与实操示例

建议用加权评分法做量化决策。以下是一个可填写的示例表，权重和评分可根据企业实际调整。评分采用 1～5 分，5 分表示该策略在该维度表现最好。

按示例权重计算，就地升级与分阶段切换得分接近，说明该组织版本差距不大但停机容忍度低，可优先考虑分阶段切换，或在非核心项目上先做就地升级验证。若企业定制治理诉求强，则应提高“定制治理收益”权重，重建迁移的得分会明显上升。

最终选型应形成一份书面决策记录，写明所选策略、排除其他策略的理由、关键假设、回退触发条件和责任人。迁移策略不是一次性选择，在预生产演练后若发现插件阻塞或数据映射失败，应允许回到决策表重新评分。把策略选型当作可验证的工程决策，而不是一次性拍板，才能在企业级迁移中真正控制风险。