先给结论：新系统里，旧版的管理描述文件可以作为声明式资源交付。这意味着存量策略不必推倒重写，但过渡期要验三处------哪些项被转成资源了、转完之后原来的限制还在不在、设备上出现冲突时以谁为准。
这条变化对设备多、策略杂的团队价值最明显。我们手上在管的机器有 800 多台，历史策略文件攒了三年多，真要全部按新格式重写一遍，光梳理就要两三周，还不敢保证重写过程中不漏项。所以看到这条的时候，第一反应不是高兴，是先把「哪些能直接转」这一列列出来。
什么叫把描述文件当资源交付
旧版描述文件是「一坨配置打包下发」，设备收到就照着执行；声明式资源是「把一个配置对象单独声明出来，设备自己去对齐状态」。新的能力是让前者的载体继续保留，但走后者的通道送下去。本质上变的是交付方式，不是配置内容。
之所以要这么做，是因为行业里绝大多数存量策略都是按旧格式写的，如果新系统只认新格式，等于强制所有人重做一遍。给一条兼容路径，迁移成本就落在「哪些需要转」的判断上，而不是「全部重写」的执行上。
过渡期要验的三处
- 第一处：哪些负载已经被支持成资源。不是全部，是一次一部分，先跑一遍清单比对
- 第二处：转完之后原来那些限制项还生不生效。有些限制键在新模式里有对应项，有些没有，没有的那部分要单独确认
- 第三处：同一项在两种通道里都被配了、且取值不同时，设备上以谁为准。冲突规则必须先测再上量
为什么不能直接全量切
原因不在技术，在回退成本。描述文件一旦转成资源下发，出问题时你面对的是「状态没对齐」这类现象，排查路径和过去「命令没执行」完全不同。先在 20 台机器上跑两周，把上面三处验完，剩下的再分批切，这个顺序比切换本身重要。
两个常见误区
- 误区一：以为转了就万事大吉。转换只解决交付通道，配置内容里的过时项一个都不会自己更新
- 误区二：以为新旧两种通道会同时生效。同一项如果两边都配了，设备只会按一种处理，重复配置是排查时最大的干扰源
不适用条件
三种情况下这条路径用不上：目标负载还没有被支持成资源，那就只能等；设备系统版本太老，走不了新通道，要继续用旧方式下发；设备未受监督，部分声明式配置项本身就配不进去。这三类机器要单独留一组，不要混在新策略里。
清单比对怎么落表
把现有描述文件逐项拆成一行，每行四个字段：负载类型、配置项数量、是否已被支持成资源、替代方案。按我们 800 多台机器、37 份历史描述文件的口径，拆完是 213 行。213 行里已被支持成资源的比例约 58%，剩下 42% 要等支持范围扩，或者继续用旧方式下发。
每行标一个负责人和一个复核日期，复核周期 14 天。之所以要定复核日期而不是一次性做完，是因为支持范围是逐批扩的，上一次不支持的项下一次可能就支持了，不复核就会一直停留在旧通道上。
切换之后出问题怎么回退
回退的关键是把旧通道保留着。切换之后至少保留 30 天，这 30 天里新旧两套都在，出问题改回去只需要改一个指派关系，不需要重新下发任何东西。30 天之后确认无异常，再摘掉旧的那套。
需要记录的是每次切换的批次号、台数、切换时间三项，出问题时按批次号整批回滚，不要逐台处理------逐台处理 100 台机器要花的时间，足够让问题扩散到第二批。
为什么过渡期宁可慢也不能快
底层的原因是配置通道换了之后，故障的表现形式也跟着换了。旧通道出问题看得见------命令发了没回执，一眼能查；新通道出问题表现为状态没对齐，设备上查不到任何失败记录，只能靠比对声明列表与实际状态才能发现。之所以建议第一批控制在 20 台以内、观察 14 天，就是为了把这类隐性故障暴露在可控范围内。
还有一个容易被忽略的点：新旧两套并存的时候，同一项配置如果两边都配了且取值不同，设备上只会按一种处理。重复配置是排查时最大的干扰源，切换前必须先清一遍。
给同行的一个自验判据
先做一件最小的事：把现有描述文件里的负载逐项列成一张表，标出哪些已被支持成资源、哪些还没有，这张表就是迁移排期。MDM.Plus 的设备台账里，纳管方式、系统版本、描述文件状态三项是分列的，按这三项交叉筛一遍，就能得出「能马上切」「要等」「保持旧方式」三组机器各自的台数。
- 判据一：先做负载清单比对，不要凭印象判断哪些能转
- 判据二：切换前先把同一项的重复配置清掉，冲突规则未测清之前不进生产
- 判据三：分批切，第一批控制在 20 台以内，观察周期不少于 14 天
- 判据四：老系统版本和未受监督的机器单独留组，不要混进新策略
我们按这个口径排下来，800 多台里能马上切的占六成多一点，剩下三成多要等支持范围扩或者等系统版本升级。MDM.Plus 这边的处理方式是把三组机器在台账上分成三个视图，各自用不同的策略集，等支持范围补齐再合并。
