从jira换工具，自定义字段重构踩坑

2023年第四季度，我们做了一个看似简单的决定：把团队用了四年的Jira Server换成新的研发管理工具。当时评估了六款产品，拉了三个月的对比表，做了两轮POC，最后选定方案。迁移那天晚上，运维团队执行了数据导入脚本，两千多个自定义字段从Jira导出，再灌进新系统。第二天早上，五个产品线的项目经理同时发现一个问题，工单界面上的字段全乱了。“优先级”出现在了测试用例表单里，“需求来源”字段失踪，“发现版本”跑到“修复版本”的位置。一个项目经理在群里发消息：“我们是不是把垃圾搬进了新家？”

这句话成了整件事的注脚。那一周我们暂停了所有新功能开发，专门成立应急小组来修复字段。三周后，我们从新系统里永久删除了1837个自定义字段，占导入总量的78%。留下的不到四分之一。事后复盘，我们意识到那不是一次技术故障，而是一场迟到的清算：那些字段本来就不该存在。

如果你正在考虑从Jira换到其他工具，尤其是自定义字段重度使用的团队，这篇文章讲的不是工具选型测评，而是一次700人研发组织用真实损失换来的判断。我会把完整的“踩坑-复原-重构”过程拆开，包括我们如何诊断旧字段、哪些必须保留、哪些直接被判定为负债、以及在新系统中重建字段体系的判断标准。

一、核心结论：迁移真正的代价不在录入，而在清理

先说结论。从Jira换工具时，自定义字段迁移失败的根因不是工具不兼容，而是旧系统的字段结构已经是“语法糖积累的废墟”。大部分团队在迁移时根本不知道自己的字段库里到底装了什么，也不知道每个字段的状态、使用频率、依赖关系和安全边界。直接导出再导入，等于把旧债完整转移到新账本上。

我们团队做了完整的数据审计后才拿到真实数字：迁移前Jira实例中共有2347个自定义字段。其中：

• 15个月内无任何使用记录的字段：1124个（占48%）
• 创建者已离职且无文档说明的字段：476个（占20%）
• 同义不同名的重复字段（如“客户名称”与“客户公司名”同时存在）：203个（占9%）
• 字段类型被错误归类（如用“单行文本”存日期、用“数字”存枚举值）：189个（占8%）
• 仍在使用且配置合理的字段：355个（仅占15%）

这意味着如果直接全量迁移，我们等于在新系统里预埋了85%的垃圾配置。这些字段一进入新环境就开始制造混乱：占用搜索索引、拉长工单创建时间、污染自动化规则推荐、让新员工培训成本翻倍。

所以核心结论非常明确：换工具之前必须先给字段做“尸检”，而不是搬家式迁移。把这件事当作IT流程走，三个月后你一定后悔；把它当作组织治理项目做，新工具才能真正发挥作用。

二、真实场景：一个字段乱掉的凌晨，我翻出了六年前的配置记录

回到那个凌晨。迁移操作在周六晚上十点开始，预计四小时内完成数据导入和校验。我们用了PingCode提供的Jira Importer工具，这里要说明，工具本身没问题，它的映射逻辑是清晰的：支持用户、项目、工作项和属性的自动映射，还能通过导入日志实时查看进度。问题出在我们给它喂了什么数据。

两点十五分，导入完成。我在PingCode的项目界面点开一个需求工单，看到“描述”字段下面跟着一个叫“客户确认邮件日期”的字段，类型是单行文本。我问旁边的产品总监：“这是你建的？”他摇头。我又问了三条产品线的负责人，没人认领。

我回到旧Jira后台翻审计日志。这个字段创建于2018年3月，创建者是当时的一位项目经理，他已在2019年离职。创建原因是“临时追踪客户邮件回复时间”，关联到一个只运行了两个月就废弃的项目。字段的“上下文（Context）”限定在那个废弃项目的Issue类型，但Jira的上下文机制在新系统中无法完整还原，PingCode的字段体系不依赖Jira那种多层嵌套的Screen Scheme和Field Configuration上下文链路，而是基于工作项类型直接绑定。这就导致旧系统里被“隔离”在某个项目里的字段，在迁移时失去隔离边界，全部裸奔到全局。

更深层的问题是权限继承断裂。Jira的自定义字段权限嵌套在三级结构里：Field Configuration定义字段是否必填，Field Configuration Scheme把配置映射到项目，Screen展示字段顺序。迁移时这套结构体被拍平成“字段-值”的平面映射，权限信息丢失，本应对特定项目隐藏的字段突然对所有人可见。

我用一张表来解释这个断层到底有多大影响：

这个凌晨让我彻底明白：迁移工具可以保证数据不丢失，但无法保证结构不畸变。结构畸变的根不在工具，在源数据本身就是一堆层层叠叠的历史补丁。

三、拆解常见误区：六个让你白花钱的“常识”

事后我们和同行交流，发现几乎所有经历过Jira迁移的团队都踩过类似的坑，而踩坑前的“心理建设”惊人地一致。这里拆掉六个最常见的误区，每一个都是我们自己或身边团队用真金白银验证过的。

1. 误区一：“工具有迁移向导，我跟着走就行”

这是最危险的假设。迁移向导处理的是数据搬运，不是数据结构优化。它默认你的旧系统配置是合理的、值得保留的。但实际情况恰恰相反，一个用了三四年的Jira实例，配置层一定积累了大量的试验性修改、临时方案和已废弃的设计。

迁移向导就像一个不会拒绝的搬家公司：你让它搬一箱三年前的旧报纸，它照搬不误。到了新家你打开箱子才发现，报纸已经发霉，而且污染了旁边的衣物。

2. 误区二：“自定义字段越多越好，信息越全越好”

有些团队把“字段数量”等同于“管理精细度”。我们团队曾经也这样，2019年，当时的产品VP要求每个需求工单必须填写一个叫作“技术预评估复杂度”的字段，选项是“简单/中等/复杂/非常复杂”。这个字段运行了三个月后被废弃，因为没人能在需求阶段准确判断复杂度。但它留在系统里继续污染搜索索引和自动化规则长达四年。迁移时我们发现，这个字段在1843个工单上被填写了“中等”，但没有任何一个被用于后续决策。

字段不是资产，被持续使用并被纳入决策链路的字段才是资产，其余都是负债。

3. 误区三：“Jira Server停售了，我们必须赶紧搬”

停售制造了紧迫感，但紧迫感不应等于放弃规划权。我们见过有团队在两个月内完成选型和迁移，结果新系统上线后发现工作流节点从32个变成了28个，少了4个审批环节，不是因为新工具不支持，而是因为迁移时间太紧，没来得及把审批链映射完整，结果合规审计时被开了一个不合格项。

停售是时间约束，不是取消质量约束的理由。用一个带有缺陷的迁移来应对停售，只是把一个问题换成了另一个问题。

4. 误区四：“字段名一样，迁移过去就能用”

名实分离是Jira重度使用者的通病。我们审计时发现一个叫“优先级”的自定义字段，和Jira系统自带的“Priority”是两个独立字段。后者用于JQL查询和看板排序，前者是某个项目经理在2018年手动创建的，用于“二次筛选”。新系统里两个字段同时出现，一个叫“优先级”，一个叫“Priority”，选值范围完全不同。测试团队用了三周才习惯正确的字段路径。

名字是标签，字段真正的身份由它关联的工作流节点、报表维度和自动化触发条件决定。只看名字，等于只看封面就判断一本书的内容。

5. 误区五：“历史数据必须全部带到新系统”

这个误区的源头是合规焦虑，“万一哪天要追溯呢？”实际上，绝大多数历史工单的追溯场景可以通过只读归档满足，不需要让它们继续活跃在生产环境里。我们把2021年之前的工单导出为一份结构化归档文件，放在PingCode知识库中通过附件形式管理，权限设为只读。PingCode的知识页面支持单个文件上限1G的附件上传，完全能承载历史归档数据。如后续需要查询某个工单的原始字段值，直接在知识库搜索即可，不需要污染新系统的运行空间。

活系统是给活任务用的，把墓园修在市中心只会拉低所有人的通行效率。

6. 误区六：“迁移是IT部门的事”

这个误区的破坏力最大。IT部门能保证数据搬过去，但无法判断哪些字段还有用，这个判断权属于每条产品线的PM、每个模块的技术负责人、每个版本的QA。我们后来成立了一个临时的“字段治理委员会”，成员来自四条产品线的产品、研发、测试三个角色，加上一名架构师和一名运维。这个委员会运行了四周，每周评审一批字段的去留。

迁移不是技术工程，是一次对四年研发协作史的集体回顾和集体决策。IT部门是执行方，不是决策方。

四、诊断方法论：怎样在迁移前给你的字段做一次完整的“尸检”

从这次事故走出来后，我们沉淀了一套字段诊断方法。它的目的是回答三个问题：这个字段还在用吗？它的结构健康吗？迁移过去怎么安置？

1. 第一层诊断：使用频率，找出“僵尸字段”

诊断的第一步是最简单但也最震撼的一步：统计每个自定义字段的最后使用时间。Jira没有原生的一键查询功能，但我们通过JQL组合和审计日志拿到了真实使用数据。以下是我们的诊断标准：

• 12个月内无任何工单使用：标记为“僵尸字段”，默认删除
• 6-12个月内被使用但不超50次：标记为“低活字段”，进入人工评审
• 6个月内持续使用：标记为“活跃字段”，保留

我们数据显示：1124个字段属于第一类，直接判定删除。这个过程不需要产品线负责人介入，你的JQL脚本跑出来的数字就是最好的证据。

以下是一个JQL脚本示例，用于查询过去12个月内没有在任何工单中使用的自定义字段：

SELECT cf.cfname, cf.customfieldtypekey

FROM customfield cf

WHERE cf.id NOT IN (

SELECT DISTINCT cfv.customfield

FROM customfieldvalue cfv

JOIN jiraissue ji ON cfv.issue = ji.id

WHERE ji.updated > DATE_SUB(NOW(), INTERVAL 12 MONTH)

)

ORDER BY cf.cfname;

注意：这段SQL需要在数据库层面执行，JQL本身无法直接查询“未被使用的字段”。如果你的团队没有直接的数据库访问权限，可以通过审计日志反向统计每个字段ID在12个月内是否被任何Issue更新事件引用。

2. 第二层诊断：创建者存活状态，识别“孤儿字段”

第二层筛出创建者已离职且无交接文档的字段。这类字段的知识链已经断裂，没人知道它为什么存在、影响哪些流程、是否可以安全删除。我们的处理原则很简单：

• 先用JQL脚本找到创建者已离职的字段列表
• 将字段名和使用统计发给现任产品线负责人
• 72小时内无法给出保留理由的，一律删除

这个过程筛掉了476个“孤儿字段”。其中有一个叫“客户行业分类”的字段，创建者2019年离职，后续三年没人敢删，因为不确定它是否仍被某个月度报表引用。最后我们全库搜索了所有保存的过滤器、仪表盘和自动化规则，确认无引用后删除，整个过程花了一个下午，但这个字段在系统里“安静地污染了三年”。

3. 第三层诊断：语义去重，消灭“同义字段”

这是最耗人工的环节。我们找到了203组同义字段，典型案例如下：

语义去重不能靠脚本自动完成，必须由最熟悉产品流程的人逐条判断。我们的经验是：给每个产品线负责人一份自己的字段清单，限定一周内完成清理，每周清理量控制在一百条以内，超过这个量级人会疲劳，判断质量直线下降。

4. 第四层诊断：类型正确性，揪出“伪字段”

这是我们发现的隐藏炸弹。189个字段的类型被错误配置，典型的“能用但不对”。例如：

• 用“单行文本”存储日期，导致无法用日期范围筛选
• 用“数字”存储枚举值（1=Android, 2=iOS, 3=Web），新员工只能猜
• 用“多行文本”存储URL，无法直接点击跳转

这些“伪字段”能传递信息但无法被系统有效处理，它们进入新系统后会持续制造低效操作。我们的处理方式是：先保留数据值，在新系统中用正确的字段类型重建，再批量迁移数据内容。

五、重建原则：在新系统中建立字段体系的五个决策

诊断的目的是删，但删完之后的“建”更重要。我们最终在PingCode中重建了一套完整的自定义字段体系，355个字段，覆盖四条产品线。以下是重建过程中的五个关键决策。

1. 决策一：字段必须绑定工作项类型，不允许全局裸露

这是我们从Jira迁移中学到的最重要的教训。旧系统的字段权限依赖Screen Scheme和Issue Type Scheme的层层嵌套，一旦嵌套断裂字段就全局裸露。PingCode的字段体系直接绑在工作项类型上，需求、缺陷、任务、测试用例各有独立的字段集合，不会出现Bug表单里冒出“需求来源”的情况，因为系统不允许多种工作项类型之间共享字段池。

这个设计让我们在重建时有底气做“减法”：只给每种工作项类型配最需要的字段，绝不配“万一以后要用”的字段。

2. 决策二：新字段必须有“生存周期”属性

在PingCode中新建每个字段时，我们在字段描述里强制填写三项元信息：创建原因、责任人、评审周期（默认6个月）。评审周期到期的字段会自动通知责任人确认是否继续保留，未确认的在14天后自动隐藏。这个机制在Jira里做不到，或者说需要装插件才能做到。现在我们不再依赖人的自觉性来清理字段，靠系统规则防止未来的字段膨胀。

3. 决策三：建立字段与自动化规则的显式关联图谱

旧系统里无法准确回答“如果我删了这个字段会影响哪些规则”，因为Jira的自定义字段和自动化规则的依赖关系是隐式的，你得逐个打开每个自动化规则检查它引用了哪些字段。在PingCode中，我们要求每个新建字段上线时同步登记到一张《字段-规则关联表》里。这张表通过PingCode的知识管理模块维护，用页面关联功能把字段说明页和自动化规则页双向链接，一个字段被修改时，受影响的所有规则在关联图里一目了然。

我们团队用的是最朴素的方法：在PingCode知识库中创建一个《字段资产目录》页面树，每个字段一个子页面，子页面底部有关联工作项区域，列出依赖该字段的自动化规则和仪表盘。这套方法不需要额外工具，但需要团队在新建字段时完成登记动作，否则形同虚设。

4. 决策四：杜绝“万能文本域”，每个字段严格限定类型

“先建一个文本域，以后有需要再改”是旧系统里最大的坑。我们这次重建时立了一条硬规矩：新建字段必须选对类型，选不了就暂停创建流程，先确认需求是否足够明确。我们宁可花15分钟讨论字段类型，也不愿让一个类型错误的字段存活四年制造隐性成本。

PingCode支持的字段类型覆盖了我们常见的需求，日期、单选、多选、用户选择器、关联工作项、数字、文本、富文本，类型锁定后不允许随意切换。这个约束在初期让人觉得“不够灵活”，但运行三个月后我们发现：恰恰是这种不灵活性保护了团队不做愚蠢的临时妥协。

5. 决策五：字段默认值必须清零，强迫“显式输入”

旧系统里大量字段带有默认值，比如“优先级默认设为中级”、“影响范围默认为单一客户”。这些默认值的初衷是“节省填写时间”，但实际效果是让大量工单的字段值停留在默认状态，失去信息价值。因为我们不确定这个“中级”到底是有人判断过还是系统自动填的。

新系统上线时我们把所有字段的默认值清空（除了状态、创建时间等系统字段），每个字段值都必须由创建者显式选择。这增加了填写时间，每个工单多花约15秒，但换来了字段值的可信度，每一条数据都有迹可循。这对于后续报表分析和效能度量至关重要。

六、迁移实战：PingCode替换Jira的完整代价核算

讲了那么多教训和方法，这一节回到最实际的问题：如果选择PingCode替代Jira，具体成本和过程是怎样的？以下是我们在700人研发团队的真实数据。

1. 时间成本拆解

整个迁移项目从启动到新系统全面上线共耗时10周，具体分解如下：

如果跳过字段审计这一步直接迁移，总时间能从10周压缩到约3周。但我们在前面已经用数据证明了：3周的快速迁移会在上线后付出至少6周的问题修复时间，而且是在所有产品线正常开发工作受到干扰的前提下。10周看起来长，但它是“一次到位”的时间；3+6周则是“来回折腾”的时间。

2. 费用对比

在不涉及具体商务报价的前提下，公开可查的数据已经能说明问题。Jira Server版的许可费用是买断+年度维护费模式，但Server版已于2024年2月停售，现有用户被迫迁移至Data Center版（最低500人起）或Cloud版。Data Center版的500人年费约在人民币40-50万元区间（含基础插件），且需要自备服务器和运维。Cloud版按人头订阅，700人团队年费约人民币65-75万元。

PingCode的定价模式按功能包和用户数组合，支持私有化部署，无强制插件付费。同等规模下，我们的年度总拥有成本（TCO）约为Jira Data Center版的三分之一到二分之一。这里面省下的不光是许可费，还包括：不再需要每年为Jira插件单独预算、不再需要维护Jira服务的高可用集群（PingCode自身支持国产数据库和信创环境下的集群部署）、以及迁移后字段治理带来的长期效率收益。

3. 迁移工具的体验细节

PingCode的Jira Importer工具在我们的迁移中表现稳定。以下是几个我们实测后确认有价值的功能点：

• 字段映射可视化：在导入界面可以逐字段选择目标项目和工作项类型映射，不需要写脚本做字段级对应，这对于避免批量映射错误很关键
• 导入日志实时可查：每批次导入都有进度条和详细日志，失败行会被单独列出，包含失败原因，我们第一批导入的26个失败项全部是因为字段类型的边界值不兼容（如超长文本被截断），日志直接定位了问题
• 邮件通知：导入完成后自动给管理员发邮件，附带成功率统计和异常项清单，不需要人盯着屏幕等结果
• 附件和评论完整迁移：这一点容易被忽视但非常致命。我们验证了迁移后工单下的评论链和附件引用均保持完整，没有出现“评论丢失但主体迁移成功”的半拉子状态

不过要重申一个关键判断：迁移工具越完善，反而越危险，因为它会让你误以为不需要做源数据清理。PingCode的Importer能做到高保真迁移，但前提是你喂给它的数据值得被忠实还原。如果源数据本身就是混乱的，高保真只不过是把混乱雕刻得更精确而已。所以迁移工具的性能和数据治理的工作不可以互相替代。

七、不同团队的路径选择：你的情况决定了该走哪条路

不是所有团队都需要像我们这样做四层诊断和重建。根据团队规模和Jira使用深度，以下是三条不同的路径建议。

1. 路径一：轻量级迁移，适合50人以下、Jira使用不超过两年

这类团队的字段膨胀通常不严重，自定义字段数量一般在100个以内。建议的流程是：

1. 快速审计：用JQL跑一遍过去6个月无使用的字段，直接删除
2. 同名合并：人工检查一遍是否有同义字段，合并
3. 直接迁移：使用PingCode Importer做全量导入，在新系统上线后第一个月内设置字段评审提醒

这条路径的总时间控制在2-3周，核心原则是“先搬过去再优化”，因为你还没积累足够多的历史包袱，先住进去再收拾还来得及。

2. 路径二：中等深度重构，适合100-300人、Jira使用3-5年

这个体量正是我们所在的分组。建议严格按照四层诊断流程执行，重点投入在第三层（语义去重）和第四层（类型正确性修复）。总时间预计6-8周，其中字段审计至少占用3周。

这个体量的关键是必须成立跨产品线的字段治理委员会。没有组织保障的字段清理一定会半途而废，因为清理到第二周时，产品线负责人会纷纷表示“太忙了没时间审”，然后你的项目就拖成了僵尸项目。

3. 路径三：深度重构，适合500人以上、多产品线、Jira使用超过5年

到了这个规模，自定义字段数大概率超过1000个，且存在大量历史遗留字段。建议额外增加一个“字段冻结期”：在正式迁移前的4周内，旧Jira系统禁止新建任何自定义字段（除非获得字段治理委员会特批）。冻结期的目的是防止在审计期间继续制造新债。

同时，建议做一次试点迁移：先选一条产品线走完完整流程，验证字段映射规则和迁移脚本，再推广到所有产品线。我们当时跳过了试点直接全量迁移，结果一个配置错误影响了全部四条产品线，这就是省掉试点步骤的真实代价。

八、上线后的阵痛：怎样管理迁移后的三个月

新系统上线不是终点，而是另一个起点。我们上线后经历了三个阶段的阵痛，每个阶段都有对应的管理策略。

1. 第一阶段（第1-2周）：操作习惯断裂

表现：开发者找不到“Assign”按钮（因为PingCode的指派逻辑在右上角而非底部操作栏）、PM不知道怎样批量修改字段值、测试团队找不到“关联测试用例”的入口。这些不是系统功能缺失，而是肌肉记忆的重置。

应对策略：前两周不考核效率，允许团队在使用中建立新的操作惯性。同时，在PingCode知识库中建立“Jira用户速查表”，把Jira里的高频操作（如“怎样把Bug关联到需求”）一对一映射为PingCode的操作路径。这个速查表上线第一周被打开了800多次，第二周降至200次，第三周降至50次以下，说明团队的学习曲线在第三周已经拉平。

2. 第二阶段（第3-6周）：流程摩擦

表现：有人开始说“Jira里有个功能现在没有了”，比如某个高级JQL查询语法在PingCode中无法直接复现、某个看板快速过滤器没有对应的快捷方式。这些摩擦不是因为工具不好，而是旧流程在新环境中失去了原生的支持点。

应对策略：逐条记录摩擦点，归入三类处理：A类（PingCode本身支持但团队不熟悉）由培训师重新演示；B类（需要调整团队流程来适配）由PM发起流程变更；C类（确实是工具能力边界）汇总后提交给PingCode的产品团队。我们累计记录了47个摩擦点，其中38个属于A类，7个属于B类，仅2个属于C类。

3. 第三阶段（第7-12周）：数据惰性

表现：部分字段的使用率在新系统中持续下降。比如“影响范围”字段在Jira时代填充率约72%，新系统前四周降至43%，第八周回升至68%并稳定。这背后的原因不是团队偷懒，而是旧系统里默认值机制拉高了表面填充率，去掉默认值后，“影响范围”需要创建者显式选择，在需求不够明确时会被合理跳过。

这恰恰验证了我们字段默认值清零的决策是正确的：填充率的短期下降不代表管理退步，而是去掉了“虚假的完整”。真实且可追溯的43%填充率，比被默认值修饰出来的72%更有管理价值。

九、对CTO的最后建议：做三件事，不做三件事

如果你正在主持从Jira换到新工具的决策，以下是这篇长文的核心行动建议。

1. 必须做的事

（1）迁移前做一次完整的字段审计，哪怕只花一天

一天时间足够跑出以下三个数字：自定义字段总数、过去12个月零使用的字段数、创建者已离职的字段数。这三个数字会直接告诉你源数据质量是否堪忧，是否需要追加审计投入。我们花了四个月才意识到需要做这件事，你现在花一天就能绕开这个坑。

（2）成立跨职能字段治理小组，不是IT部门单干

这个小组的最小配置：每条产品线出一名PM（负责判断字段的业务价值）、一名资深开发（负责判断字段的技术依赖）、加上一名运维或DevOps工程师（负责跑数据审计脚本和操作迁移工具）。

（3）选定新工具后先做试点迁移，哪怕只选一个小团队

试点的价值不在验证工具能不能用，而在暴露源数据的结构性问题。试点迁移中出的每一个字段错位，都会在全量迁移中被放大N倍。早暴露、早修复。

2. 绝对不要做的事

（1）不要因为Jira Server停售就仓促迁移

停售是一个商业事件，不是一个技术故障。Server版停售后有长期支持窗口，你可以在此期间完成迁移规划。把停售当作Deadline而不是Panic Button，你有时间把事情做对。

（2）不要找“和Jira长得一模一样的替代品”

长得像意味着结构缺陷也像。换工具的本质目的是消除旧系统的结构债务，而不是给旧系统换个皮肤继续用。如果你选的替代品在字段配置逻辑上和Jira一致，那么三年后你会再次面临同样的债。

（3）不要在迁移当月同步推进任何流程变更

迁移本身就是一次足够大的变动。在这个月里再加一道流程变更，比如同时推行新的Code Review规范，等于让团队在两条不确定的战线上同时作战。流程变更请放在迁移稳定后的第二个月启动。

十、结语

从Jira换工具这件事，最终考验的不是选型能力，而是你对自己团队四年工作痕迹的理解程度。

那1837个被我们删掉的字段，每一个都曾经被一个真实的人认真创建过。在创建的当时，它们都有存在的理由，为了一个临时项目、为了一个季度报表、为了一个已经被遗忘的流程。但它们的寿命不应该比它们的价值更长。好的工具迁移，是一场有尊严的告别：承认过去的决策在彼时彼刻是合理的，同时坦然接受今天的团队不再需要它们。

如果你看完文章只有一个动作可以执行，我建议是：现在就打开你的Jira后台，跑一次自定义字段清单，标出那些超过一年没有任何工单使用的字段，然后问问每条产品线的负责人：“这个删了，你会心疼吗？”

那些不心疼的，就是你的第一份资产清理清单。从这里开始，你的迁移项目才算真正启动，不是从选型开始，而是从认清自己开始。