Tuya OEM App 迁移到自研 SDK App 时，最危险的判断不是“SDK 能不能接上”，而是“用户会不会在升级后发现设备丢了、家庭结构乱了、自动化失效了”。如果迁移只按 App 开发项目来排期，风险通常会落到上线当天：老用户无法登录、新 App 看不到设备、面板能力不一致，客服团队也不知道该让用户重配还是回滚。
更稳妥的做法，是把迁移拆成两条线：一条是 SDK App 的功能交付，另一条是存量用户和设备关系的连续性治理。只有当账号、家庭、设备、面板、场景和售后路径都被验证过，迁移才接近“用户无感”。否则，新的 App 做得再好，也会被一次大规模重配消耗掉品牌信任。
1. 先判断：这是不是一个迁移项目，而不是一个新 App 项目
Tuya Smart App SDK 能提供配网、家庭管理、设备管理、群组、场景自动化等能力；它适合用来构建自有品牌 App，但它不会自动替你解决所有存量用户迁移问题。对已经上线 OEM App 的团队来说，SDK 接入只是基础能力，真正的项目主线是“如何让旧 App 里的用户、家庭和设备关系在新 App 中继续可用”。
如果目标只是发布一个新品牌 App，并允许新用户重新注册、重新配网，那么项目难度主要在 UI、SDK、面板、云项目和审核发布。可是如果目标是承接已有 OEM App 用户，就必须先回答三个问题：
| 问题 | 如果没有答案，会发生什么 |
|---|---|
| 旧账号如何映射到新 App 账号 | 用户登录后看不到自己的家庭和设备 |
| 设备关系如何继续被新 App 管理 | 客服会被迫引导用户逐台重配 |
| 旧面板、自动化和售后流程如何过渡 | 新 App 上线后出现功能回退和大量工单 |
结论很直接：只要存量用户数量已经足以形成客服压力，OEM 到 SDK 的迁移就应该按“生产切换项目”管理，而不是按“App 重做项目”管理。
2. 迁移对象不是一个 App，而是一组关系
很多迁移失败，是因为团队只检查了登录、配网和设备控制，却没有把 Tuya 生态中的关系拆清楚。一个用户在 OEM App 里看到设备，背后至少涉及账号、家庭、设备绑定、DP 模型、面板、场景、推送和云项目权限。新 SDK App 要承接的不是图标和页面，而是这些关系的可用性。
建议把迁移对象拆成五层：
- 账号层：手机号、邮箱、国家区、第三方登录、验证码、注销和隐私授权。
- 家庭层：家庭、房间、成员权限、共享设备和管理员关系。
- 设备层：设备绑定、网关子设备、固件状态、DP code、在线状态和日志。
- 体验层：面板、场景、自动化、消息推送和常用入口。
- 运维层：客服查询、问题定位、灰度名单、回滚策略和公告触达。
这五层里，任何一层没有验证，都会把“用户无感迁移”变成“用户自己排障”。尤其是网关子设备、家庭共享和自动化场景，它们在测试账号里往往看起来正常，但在真实存量账号里更容易暴露历史配置、地区、权限和面板兼容问题。
flowchart LR
A("旧 OEM App 用户"):::blue --> B("账号与家庭关系核对"):::cyan
B --> C("设备与 DP 连续性验证"):::orange
C --> D("SDK App 灰度登录"):::violet
D --> E("面板 / 场景 / 推送回归"):::green
E --> F("正式切换与客服兜底"):::slate
F --> G("旧 App 降级入口或下线"):::slate
classDef blue fill:#EAF4FF,stroke:#3B82F6,color:#16324F,stroke-width:2px;
classDef cyan fill:#E9FBF8,stroke:#14B8A6,color:#134E4A,stroke-width:2px;
classDef orange fill:#FFF3E8,stroke:#F08A24,color:#7C3F00,stroke-width:2px;
classDef violet fill:#F4EDFF,stroke:#8B5CF6,color:#4C1D95,stroke-width:2px;
classDef green fill:#ECFDF3,stroke:#22C55E,color:#14532D,stroke-width:2px;
classDef slate fill:#F8FAFC,stroke:#64748B,color:#1F2937,stroke-width:2px;
这张流程图的重点不是步骤数量，而是顺序。先验证关系，再开放新 App 登录；先灰度老用户，再扩大新版本覆盖；先准备客服兜底，再推动旧 App 下线。
3. 用户无感迁移的核心，是账号映射和设备连续性
用户并不关心你从 OEM App 换成了 SDK App。用户只关心三件事：能不能登录、设备还在不在、常用控制是否正常。因此迁移方案要先围绕这三件事建立验收口径。
账号映射要避免把“同一个手机号能注册”误判为“同一个用户已经迁移”。如果旧 App 和新 App 的账号体系、国家区、验证码策略或第三方登录方式存在差异，同一位用户可能在新 App 中变成一个新身份。结果是账号登录成功，但家庭和设备都不可见。
设备连续性也不能只看单设备控制。Tuya 设备在真实项目里可能涉及家庭归属、共享成员、网关子设备、自动化场景和云项目关联。新 SDK App 如果只验证“能配网一台新设备”，就没有覆盖迁移主风险。更可靠的验收方式，是抽取真实设备组合做灰度验证：直连 Wi-Fi 设备、BLE 设备、Zigbee 网关子设备、共享设备、老固件设备和高频售后设备都要进入样本。
| 验收对象 | 最低验证项 | 不通过时的处理 |
|---|---|---|
| 老用户登录 | 同手机号 / 邮箱 / 国家区能进入同一用户关系 | 暂停灰度，先修账号映射 |
| 家庭与房间 | 家庭、房间、成员和共享设备可见 | 不引导用户重建家庭，先定位关系同步 |
| 设备列表 | 直连设备、网关子设备、离线设备都能展示 | 分设备类型定位，不用单一客服话术 |
| 面板控制 | 核心 DP、定时、倒计时、模式切换正常 | 保留旧面板入口或延后该品类切换 |
| 自动化与消息 | 常用场景、推送和告警仍能触发 | 降低灰度比例，补事件与权限回归 |
表格之后的判断是：迁移验收不应以“新 App 功能完整”为准，而应以“旧用户的关键路径没有退化”为准。
4. 灰度发布要按风险分组，不要只按 App Store 批量比例
很多团队习惯把 App 灰度理解成 5%、20%、50%、100% 的版本分发比例。对 Tuya OEM 到 SDK 迁移来说，这个维度不够。真正该分组的是用户风险和设备复杂度。
建议按下面顺序推进：
- 内部测试账号：验证 SDK 初始化、云项目、登录、配网、设备控制和推送。
- 员工真实设备：验证家庭、共享、网关子设备、老固件和弱网。
- 低风险客户：设备数量少、品类单一、售后可直接触达。
- 高价值客户：提前告知，安排客服和技术支持窗口。
- 全量用户：保留旧 App 回退说明和问题收集入口。
如果团队只按商店比例灰度，系统会优先暴露“随机用户问题”，而不是“可解释的迁移问题”。按风险分组灰度的好处，是每一轮失败都能被归类：账号问题、设备类型问题、面板问题、推送问题，还是客服流程问题。
5. 面板兼容和 DP 模型要提前冻结
SDK App 迁移时，最容易被低估的是面板和 DP 模型。App 端看起来只是换了入口，但用户实际操作的是设备功能：开关、模式、温度、风速、告警、倒计时、能耗统计和固件升级。如果 DP code、面板配置、设备品类和业务文案在迁移期间同时变化，任何异常都很难定位。
因此迁移窗口内应该冻结三类东西：
- 核心 DP 模型不要随迁移一起改。
- 面板样式和功能入口不要一次性重构。
- 固件升级不要和 App 切换绑定成同一个强制动作。
这不是说迁移后不能优化面板，而是不要把“换 App”“改 DP”“换面板”“推固件”叠在同一个时间点。叠加变更会让用户投诉无法归因，也会让团队失去回滚路径。
如果必须同步改面板，至少要把品类分层：低风险设备先走新版面板，高风险设备保留旧面板或稳定版 BizBundle 路径。对 B2B 项目，建议给客户提供品类级切换清单，而不是只通知“新 App 已上线”。
6. 回滚策略不是回到旧代码，而是恢复用户可用性
迁移项目里的回滚，不能只理解成“把 App 版本退回去”。当用户已经安装新 App、登录过新账号、触发过设备同步或修改过家庭结构时，简单退版本不一定能恢复状态。更现实的回滚目标，是在出现严重问题时让用户继续控制设备、继续收到关键告警，并能被客服定位。
回滚预案至少包含四件事：
- 入口回滚：旧 App 是否仍可登录，是否保留下载和说明。
- 功能回滚：哪些设备品类可以继续用旧面板或旧控制路径。
- 账号回滚：新旧账号关系出现分裂时，客服如何确认真实用户。
- 运营回滚：公告、客服话术、工单标签和技术升级路径是否准备好。
当迁移影响的是家庭设备控制，回滚的成功标准不是版本号，而是用户能否继续完成关键操作。比如门锁、安防、冷链控制、商用照明这类设备，控制不可用的业务风险高于 App 新旧体验不一致。
7. 什么时候不该追求完全无感
不是所有 OEM 到 SDK 迁移都值得追求完全无感。完全无感通常意味着更高的账号梳理、设备验证、客服预案和灰度成本。如果存量用户很少，或者旧 App 中的数据关系质量很差，强行追求无感可能比一次明确的用户重登和设备重新确认更贵。
下面几类场景不适合承诺完全无感：
- 旧 App 里存在大量无法确认归属的历史账号。
- 设备品类跨度很大，但团队没有足够测试样本。
- 旧面板深度定制过，新 SDK App 不能按时复刻核心能力。
- 目标市场涉及强隐私合规，但旧账号授权链路缺少记录。
- 客服团队还没有查询工具和工单分类，无法承接迁移异常。
更稳妥的话术是“分阶段迁移，尽量减少用户重配”，而不是一开始就承诺“全量无感”。承诺越绝对，发布当天越容易被边缘账号、特殊设备和历史配置击穿。
8. 建议的迁移交付清单
如果要把 Tuya OEM App 迁移做成可交付项目，建议至少准备下面这组清单：
| 交付物 | 用途 |
|---|---|
| 用户与设备样本表 | 覆盖国家区、账号类型、设备品类、网关子设备和老固件 |
| SDK App 功能回归表 | 验证登录、配网、家庭、设备控制、场景、推送和固件升级 |
| 面板兼容矩阵 | 说明每个品类使用旧面板、新面板还是延后切换 |
| 灰度分组计划 | 按用户风险和设备复杂度分批，不只按商店比例 |
| 回滚与客服手册 | 规定如何识别账号分裂、设备缺失和面板异常 |
| 发布后监控看板 | 跟踪登录失败、设备不可见、控制失败、工单量和应用崩溃 |
这份清单的价值在于把迁移从“开发完成”推进到“可以上线”。对企业客户来说，是否选择 SDK App，最终看的不是代码自由度，而是你能不能在不打断用户使用的前提下获得品牌、数据、体验和业务系统集成的控制权。
结论
Tuya OEM App 迁移到 SDK App 的核心不是重写一个移动端，而是把存量用户、设备关系和控制体验平稳转移到新的品牌控制面。SDK App 给团队更多 UI、业务集成和长期演进空间，但这些收益只有在账号映射、设备连续性、面板兼容、灰度发布和回滚预案都成立时才会兑现。
如果你的项目还处在早期，用户量小、设备少，可以把迁移做得轻一点。但只要已经有真实用户和售后压力，就应该把它当成生产切换来做。先证明用户不用重配、设备不会丢、关键操作不会退化，再谈新 App 的体验升级。
