Guidewire 如何在不删库的情况下修改现有 typecode？
能否使用 DataModelUpgrade 直接修改原记录？
目前无法确认 DataModelUpgrade plugin 是否支持原地修改 typecode，也无法确认修改后升级和下游使用能否正常进行。题述操作将 10 改为 100、再改为 200 时都生成了新 ID，说明在当前环境和修改方式下，系统没有将其作为同一条记录的值更新。
如果必须保留原记录和原 ID，需要先确认所用的 Guidewire 产品、版本，以及 DataModelUpgrade plugin 是否提供受支持的重命名或迁移机制。现有材料缺少这些信息，因此无法给出可直接执行的插件配置、API 或 SQL。即使能够在数据库中修改，也不代表平台支持这种做法。
为保留现有数据，可以评估创建新 typecode、按业务需要迁移引用，再将旧 typecode 标记为 retired。是否迁移历史数据需要单独确定，清理旧代码也不应预设必须删库。
先区分 code、记录 ID 和显示名称
题述中的 10、100、200 是 typecode 的值，10007、10008 是新增记录的 ID。排查时需要分别确认：
- 业务记录通过什么字段引用这些 typecode。
- 规则、查询、报表和外部接口是否直接使用 code 字符串。
- 修改需求涉及代码标识，还是仅涉及界面上的显示名称。
如果只是希望用户看到不同的名称，可以先检查当前产品是否允许单独调整显示名称或本地化配置。如果需要将代码标识从 10 改成 200，则要继续检查数据和集成依赖。
即使某种操作能够保留记录 ID，下游仍可能受到影响。例如，按 code 字符串判断的规则或外部系统可能需要同步修改。
如何确认是否支持原地修改
先补齐以下信息，再核对对应版本的升级文档，或向 Guidewire 支持渠道确认：
- Guidewire 产品及完整版本。
- DataModelUpgrade plugin 的版本或具体实现来源。
- typelist 的定义、扩展方式，以及此次修改的配置差异。
- 旧 typecode 的引用范围，包括业务数据、规则和外部接口。
需要确认是否存在受支持的 typecode 重命名操作、是否保留内部 ID、如何处理已有引用，以及后续升级是否会再次创建记录。普通的业务数据更新能力，不能直接证明插件允许修改 typecode 的标识。
无法确认原地修改时，怎样保留现有数据
可以在隔离测试环境中评估以下流程，具体操作应使用当前版本支持的机制。
- 确定目标代码和映射关系，明确哪些旧值需要对应到新值，以及这种对应是否适用于历史记录。
- 创建目标 typecode，检查其业务含义、显示信息和使用条件是否符合需求。
- 按范围迁移业务引用。可以只迁移仍在处理中的记录，也可以保留历史记录使用旧值，具体取决于审计、报表和业务要求。
- 停用旧 typecode。检查 retired 状态在当前产品中的实际行为，确认旧记录仍能按预期读取，并验证新建业务是否还能选择旧值。
- 同步依赖方，更新相关规则、接口映射、导入导出及报表逻辑。
如果最终目标是统一使用 200，可以参考下面的映射关系。它只是迁移关系示例，不能作为 Guidewire 配置或可执行脚本使用：
旧 code → 目标 code
10 → 200
100 → 200
这个映射只适用于 10 和 100 都需要归并到 200 的情况。如果它们代表不同的业务含义，就需要分别处理。
验证和清理时要注意什么
将旧值标记为 retired 和将现有业务记录迁移到新值是两个独立步骤，完成其中一步不会自动完成另一步。
验证应覆盖已有记录的读取、修改和保存，新业务的创建，以及相关规则、报表和接口调用。如果迁移设计要求重复执行，也应检查再次运行时是否会重复创建数据或产生错误引用。
生产环境中是否允许删除旧 typecode，应根据当前版本的支持范围和实际引用情况决定。删除并重建较低环境的数据库可以清除该环境的数据，但不能替代对生产迁移方案的验证。没有明确支持依据时，应保留旧记录，并通过受支持的停用及迁移流程完成业务调整。
备注：内容仅供参考。