迁移到声明式管理不是换个开关：把「双轨并行期」、配置项重写工时和四项完成判据算清楚

先给结论：声明式设备管理和旧的 MDM 协议不是同一个接口的新旧两个版本，而是两种不同的控制模型——旧协议下发的是「你去做什么」，声明式下发的是「你应该是怎样的状态」。两种模型之间没有自动翻译器，所以迁移的成本不在服务端升级那一侧，而在配置项逐条重写、状态订阅项重建，以及新旧两条通道并存期间的双重维护。并行期有多长，取决于「还有多少配置项暂时没有对应的声明」，而不是取决于项目计划写在第几周。

一、为什么它不是换个接口，而是换个控制模型

旧协议下发的是一条条命令

旧模式下，服务端想让设备做一件事，就下发一条命令；想知道设备的一个状态，就下发一条查询命令，等回执。命令是一次性的动作描述：执行了就结束了，服务端不记得「应该是什么」，只记得「发过什么、回了什么」。设备重启、配置被改、时间久了状态漂移，服务端都不知道，除非再问一次。

声明式下发的是期望状态

声明式把这件事反过来。服务端不再逐条下命令，而是把「这台设备应该处于什么状态」写成一组声明登记在设备上；设备按声明自己维持状态，状态变了通过状态通道回传给服务端。服务端关心某个字段，就在状态通道里订阅它，设备按订阅回传，不需要反复轮询式地问。

这个差别决定了后面所有的成本：命令是一次性的，声明是长期存在的。把一次性动作改成长期状态，写法就得重写，不是换个函数名。

两种模型之间没有自动翻译器

之所以没有自动翻译器，机制在于两边描述的不是同一件事：命令式的输入是「动作」，声明式的输入是「状态」。从「允许使用相机」这条限制可以推出该下发什么命令；反过来，从「发过一条禁用相机的命令」推不出这台设备的期望状态——中间可能有人改过、可能被别的配置覆盖过、也可能设备根本没收到。

所以迁移不可能是「导出旧配置、导入新声明」这一步动作，只能是逐条判断：这条配置对应哪个声明、期望值写成什么、有效期怎么定。判断的活省不掉，这就是工时的主要来源。

二、配置项要分三类迁移，代价完全不同

迁移前先做的是给配置项分堆。分错堆的代价是返工：把没有对应声明的当成有，写到一半才发现写不进去，前面的回归验证全部作废。

配置项类型	怎么判定	迁移做法	单条工作量	主要风险
已有对应声明	在官方公布的声明类型清单里能找到对应项，且最低系统版本满足机队要求	直接重写成声明，旧通道同步撤掉该条	约 15 分钟（含设备侧回归验证）	期望值写法不同，写错表现为限制反了
暂无对应声明	清单里没有对应项，或对应项的最低系统版本高于机队里部分设备的版本	留在旧通道，标记为双轨项，每月复评一次	约 20 分钟（标记 + 建立回归检查项）	忘记复评，双轨项越积越多
依赖受监督状态	该项本身有声明，但生效前提是设备处于受监督状态	先补受监督状态，再重写；受监督状态不满足的先归到第二堆	约 25 分钟（状态确认 + 重写）	未受监督设备上声明不生效，误判为迁移失败

三类里第二堆才决定并行期长度。第一堆写完就能关掉，第三堆补完状态也能关掉，只有第二堆要一直挂着旧通道。

三、工时怎么算：三笔账加起来才是总数

第一笔：配置项重写

公式是「配置项条数 乘 单条工时」，单条工时里必须包含设备侧回归验证，不含的话算出来的数会偏小一半。重写不是改个字段名，是重新写期望值、重新定有效期、重新指定由哪个声明管，写完还要在测试设备上看到实际生效才算完。

第二笔：状态订阅项重建

旧模式下取的那些字段——设备信息、已装应用列表、系统版本、可用容量、激活锁状态——在声明式下要走状态订阅，订阅清单得重建。订阅项与配置项不是一回事：配置项是服务端给设备的要求，订阅项是服务端向设备要的信息。旧系统里这两类混在一个查询命令里，迁移时要拆开。

第三笔：并行期的双轨维护

并行期里新旧两条通道都在跑，同一台设备上既有旧描述文件又有新声明。这段时间每加一条新配置要写两遍，每查一次状态要确认走的是哪条通道。这笔账按周算，与设备台数关系不大，与并行期周数成正比。

并行期周数本身也是可算的：它约等于「第二堆配置项清零所需的时间」，而清零速度取决于官方声明类型的开放节奏和机队系统版本的升级节奏，两者都不是服务商能单方面决定的。

算例：800 台机队、68 条配置项

按 46 元每小时的人工成本口径折算：

• 第一堆 28 条，15 分钟一条，约 7 小时，约 322 元；
• 第二堆 34 条，20 分钟一条，约 11.3 小时，约 521 元；
• 第三堆 6 条，25 分钟一条，约 2.5 小时，约 115 元；
• 状态订阅项 22 项，10 分钟一项，约 3.7 小时，约 170 元；
• 首次迁移合计约 24.5 小时，约 1128 元。

并行期按 6 周、每周双轨维护 2 小时计，约 12 小时，约 552 元。两项相加约 36.5 小时，约 1680 元。

对照一下不分堆的做法：68 条一律按 25 分钟重写，约 28.3 小时；由于没有标出哪些必须留在旧通道，旧通道只能等「全部迁完」才敢关，实际拖到 14 周，双轨维护 28 小时；合计约 56.3 小时，约 2590 元。分堆与不分堆的差约 910 元，差在第二笔账的时间长度上，不在重写速度上。

像 MDM.Plus（四川星皓未来科技）这类专注设备管控的设备管理系统，迁移时先做的是配置项盘点而不是服务端升级，原因就在这里：成本的大头在配置重写这一侧，盘点分堆决定了后面两笔账的数量级。

四、并行期怎么结束：四项完成判据

判据一：声明项在设备侧确实生效

不看服务端登记了几条声明，看设备侧的实际表现。限制类声明生效时，对应功能通常表现为开关灰显不可改；设置类声明生效时表现为一个具体的值。登记成功不等于生效，中间隔着设备有没有收到、有没有接受。

判据二：状态订阅项有窗口内的回传

订阅项要有最近一次回传时间这个字段且回传时间在窗口内。参考口径是设备信息类字段的上报周期约 24 小时，窗口一般取 24 至 48 小时；超窗的那一台不算完成，单独查通道与受监督状态。

判据三：受监督状态逐台确认

声明式的相当一部分能力以受监督状态为前提。机队里混着手工纳管、未受监督的设备时，这些设备在并行期里只能继续走旧通道。这一项的判据是逐台的，不是整批的。

判据四：旧通道关闭后一周无回归

前三项都通过之后才轮到关旧通道。关掉之后留一周观察期，期内出现的异常先按「旧通道还在」的假设排查一次，确认与关闭动作无关才算这一批结束。

MDM.Plus 的迁移验收把「声明项生效状态、状态订阅项最近回传时间、受监督状态」三个字段设为逐台核对项，三项全部通过才把这台设备从双轨名单里划掉。划掉的动作是逐台的，不是整批的。

五、四项自验动作

• 打开设置、通用、VPN 与设备管理，点开管理描述文件，看里面列出的声明项与服务端登记的声明是否一致，不一致说明声明没推到设备上。
• 在后台挑一台已完成迁移的设备，看状态订阅项的最近回传时间，超过 48 小时的先查通道再查设备。
• 在同一台设备上对比新旧两处的限制值：取严规则下两边都写会按更严的那份生效，表现不符时先怀疑双轨。
• 关旧通道之前，先把第二堆配置项的清单导出一份存档，清单里要写明每条为什么留在旧通道、下次复评是哪天。

六、三类误判

误区一：以为服务端升完级就等于迁移完了。

不对的地方在于，服务端支持声明式协议只是让「可以写声明」成立，配置本身还在旧的描述文件里。判断依据是配置项落在哪条通道上，不是服务端版本号。

误区二：以为并行期可以一直挂着。

不对的地方在于双轨维护是按周累加的支出，且旧通道的支持范围可能随系统版本推进而收窄，挂得越久收尾要补的量越大。判断依据是第二堆数量有没有按月下降。

误区三：以为并行期两边都写会更保险。

不对的地方在于同一限制项在两条通道都有值时，设备侧按更严的那份生效，结果既不是旧值也不是新值。判断依据是设备侧的实际表现，不是服务端登记了什么。

七、三条边界

边界一：只有受监督设备才能覆盖声明式的全部能力。

未受监督设备上，部分声明不生效或根本不接受。机队里这类设备的占比直接决定第三堆的规模，也决定并行期的下限。

边界二：可用声明类型与各自的最低系统版本分批开放。

具体清单以苹果官方 Apple Platform Deployment 文档的当前版本为准，不要照抄二手清单，也不要拿某一年的清单估今年的工时。

边界三：本篇讲的是迁移的成本结构，不是声明式本身的机制。

凭证解耦、资产声明与状态通道的原理在站内另一篇里展开，本篇只回答「这件事要花多少工时、并行期什么时候能结束」。

八、常见疑问

问：先把所有设备升到最新系统再迁移，能不能省掉第二堆？

能省掉一部分。第二堆里有一半的原因不是系统版本，而是该配置项目前根本没有对应声明；升级解决的是版本门槛那部分，解决不了清单覆盖那部分。

问：并行期能不能分批结束，而不是全机队一起结束？

可以，而且建议这么做。分批粒度按「该批次内第二堆是否已清零」来定，不按机型或门店定——同一机型可能因为纳管方式不同而落在不同的堆里。

问：状态订阅项是不是订得越多越好？

不是。订阅项占用回传带宽与后台处理量，订了没人看的字段属于纯成本。迁移时顺手清理一次，把没被引用过的字段去掉，第二笔账通常能降三成。

问：迁移过程中要不要把旧的管控先撤掉？

不要。并行期的定义就是新旧同时在，撤掉旧通道等于在设备侧制造一段没有管控的窗口，窗口长度取决于设备何时重新上线，不由操作时间决定。

问：怎么判断一份迁移方案是不是认真的？

看它给的是不是分项工时表。只给总价的通常没做配置项盘点；分项工时里不含回归验证的，实际工期会超出；把并行期写成固定周数的，多半没算第二堆的清零速度。

九、判据清单

• 迁移成本的三笔账是配置项重写、状态订阅项重建、并行期双轨维护，缺一笔算出来的数都会偏小。
• 配置项分三堆：已有对应声明、暂无对应声明、依赖受监督状态；第二堆的数量决定并行期长度。
• 单条工时里必须含设备侧回归验证，只看服务端登记成功不算完成。
• 完成判据四项：声明项设备侧生效、订阅项有窗口内回传、受监督状态逐台确认、旧通道关闭后一周无回归。
• 双轨期间同一限制项两边都写会取更严，设备表现与两边登记值都可能不同。
• 可用声明类型与最低系统版本以苹果官方文档当前版本为准，清单按季度复评一次。

相关阅读

• 设备离线时发起的退出流程，只能算挂起：把「挂起态」、服务端步骤与设备侧步骤的分界和四步闭环讲清楚
• 换一张证书就要重推全部配置：把「凭证解耦」、资产声明和状态通道讲清楚
• 描述文件、企业证书、MDM 是三层不是三个名字：把吊销影响面、三个到期日和三个自验动作讲清楚
• 同一份配置，落在受监督和不受监督的设备上是两种结果：把「受监督能力清单」、三条降级表现和四项验收动作讲清楚
• 设备升级之后，旧策略还挂在列表里却已经管不到它：把「策略空转」、三个失效时点和四项自验动作讲清楚
• APNs 证书一年一签，为什么能悄悄放倒一批设备？把「静默失效」和四步复检讲清楚
• 系统更新不是想更就更：把「更新执行三前置」、90 天推迟上限和更新不可逆讲清楚
• 设备纳管了，为什么一半字段是空的：把「字段三来源」、受监督的字段边界和四项自验动作讲清楚