4. 数据架构与迁移映射
Data Center 到 Cloud 的迁移，本质上不是“把数据搬过去”，而是把一套可自由扩展、可深度定制的数据模型，重新映射到一套受平台约束、以云原生方式治理的数据模型上。Jira DC 允许管理员直接操作数据库、编写自定义插件、任意修改工作流与字段配置；而 Jira Cloud 通过 REST API、Forge/Connect 应用、团队管理（Atlassian Guard/组织级策略）来约束这些能力。因此，迁移映射表的核心任务，是识别哪些对象可以“原样平移”，哪些必须“结构改写”，哪些只能“降级替代”或“放弃并重建”。
一、先建立数据模型的分层认知
Jira 的数据模型可以拆成四层，迁移难度依次递增：
- 项目层：项目类型（业务/软件/服务管理）、项目键、项目角色、项目分类。这一层在 Cloud 中基本一一对应，但项目类型决定了可用功能集，需要重新选择。
- 工作流层：状态、转换、条件、校验器、后置函数（post function）、触发器。DC 中大量使用 ScriptRunner、JMWE 等插件实现的条件与后置逻辑，在 Cloud 中必须改写为原生条件、自动化规则（Automation）或 Forge 应用。
- 字段层：自定义字段类型、字段上下文（context）、字段配置方案（field configuration scheme）、界面方案（screen scheme）。这是迁移中最容易“丢语义”的一层，因为字段类型、选项、默认值、必填规则在两端并不完全等价。
- 权限层：权限方案（permission scheme）、问题安全级别（issue security level）、项目角色、全局权限。Cloud 中权限模型更细，且与组织级策略、产品访问权限耦合，需要重新设计而非简单复制。
理解这四层的差异，才能判断映射表中每一行应该标注为“直接映射”“转换映射”还是“重建”。
二、字段映射表：从“字段清单”到“语义对照”
字段映射不能只列“DC 字段名 → Cloud 字段名”，而应记录字段类型、上下文、选项、默认值、必填规则以及迁移动作。下面是一份可直接用于迁移评估的字段映射表示例（示例数据基于常见 Jira DC 配置，实际项目需按自身字段清单替换）：
| DC 字段名 | DC 类型 | Cloud 目标类型 | 上下文/选项处理 | 迁移动作 | 风险等级 |
|---|---|---|---|---|---|
| 客户编号 | 单行文本 | 短文本 | 全局上下文，无选项 | 直接映射 | 低 |
| 业务线 | 单选列表 | 单选列表 | 选项值需逐项核对，Cloud 不支持选项分组 | 转换映射，选项重建 | 中 |
| 影响版本 | 版本选择器 | 版本选择器 | 版本需先迁移，字段上下文绑定项目 | 转换映射，依赖版本迁移 | 中 |
| 审批状态 | ScriptRunner 计算字段 | 无直接等价类型 | 需改为 Automation 规则写入文本字段 | 降级替代 | 高 |
| 关联需求 | Issue Link 类型 | 问题链接类型 | 链接类型名称需在 Cloud 中预先创建 | 转换映射 | 中 |
| 内部备注 | 多行文本（含数据库直连） | 多行文本 | 数据库直连逻辑必须移除 | 重建，逻辑改写 | 高 |
这张表的价值在于：它把“字段迁移”从一次性动作变成了可逐行判断的决策过程。风险等级为“高”的行，必须在迁移前完成替代方案设计，否则迁移后会出现字段空白、规则失效或数据不可读。
三、工作流与权限方案的映射要点
工作流映射的关键不是状态名，而是转换背后的逻辑。DC 中常见的“仅当用户属于某项目角色且字段 A 非空时才能转换”，在 Cloud 中应优先用原生条件（如“用户属于项目角色”“字段值不为空”）实现；若原生条件无法覆盖，则用 Automation 规则在转换后触发校验或通知。需要特别注意的是，DC 中通过后置函数自动更新字段的逻辑，在 Cloud 中应改为 Automation 的“编辑问题”动作，并确保规则触发条件与原有后置函数一致。
权限方案的映射则要区分“权限方案”与“问题安全级别”。Cloud 中权限方案仍然存在，但项目角色的成员来源更依赖团队管理（Atlassian Guard）和组织级用户组。迁移时应先梳理 DC 中每个权限方案对应的项目角色，再在 Cloud 中重新绑定角色成员，而不是直接复制权限方案。问题安全级别在 Cloud 中对应“问题安全方案”，需要确认安全级别名称、成员规则与 DC 一致，否则会出现“迁移后问题对所有人可见”的严重问题。
四、建立映射表的实际工作流
建议按以下顺序推进，而不是一次性导出所有配置：
- 导出 DC 配置清单：通过 Jira 管理界面或 REST API 导出项目、工作流、字段、权限方案清单，形成初始台账。
- 逐项标注映射策略：对每个对象标注“直接映射 / 转换映射 / 重建 / 放弃”，并记录依赖关系（如字段依赖版本、工作流依赖字段配置方案）。
- 优先处理高风险项：先解决插件逻辑、数据库直连、复杂后置函数等高风险项，再处理字段选项、权限成员等中低风险项。
- 在 Cloud 沙箱中验证：用少量真实项目数据在 Cloud 测试站点中执行迁移，重点验证字段值是否完整、工作流转换是否可用、权限是否越权。
- 固化映射表并版本化：将最终映射表作为迁移执行依据，每次变更记录版本，避免迁移过程中配置漂移。
映射表不是一次性文档，而是迁移期间持续维护的“配置契约”。它让迁移团队、业务方和平台治理方对“什么会被保留、什么会被改变、什么会被放弃”有统一认知，从而把迁移从不可控的数据搬运，变成可审计、可回滚的工程过程。